From owner-mpls@UU.NET Sun Jul 1 01:09: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 BAA02113 for ; Sun, 1 Jul 2001 01:09: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 QQkvtc07618; Sun, 1 Jul 2001 05:08:57 GMT Received: by mail-control.mail.uu.net id QQkvtc01284 for mpls-outgoing; Sun, 1 Jul 2001 05:08: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 QQkvtc01162 for ; Sun, 1 Jul 2001 05:08: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 QQkvtc19395 for ; Sun, 1 Jul 2001 05:07:12 GMT Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.246.129]) id QQkvtc13407 for ; Sun, 1 Jul 2001 05:07:11 GMT content-class: urn:content-classes:message Subject: LSP in transit LSR MIBs MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Date: Sun, 1 Jul 2001 08:07:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <95734BD21894AC4B9AEF464C5A2985EA4B2C3B@bart.cwnt.com> Thread-Topic: LSP in transit LSR MIBs Thread-Index: AcEB66ykAeLSMONVSrGN9IcPzLc4vA== From: "Leonid Dubinsky" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA02113 Hi, I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out from them where transit LSR should store information about LSPs passing through it. Should it be placed in mplsTunnelTable? Anyone has any thoughts on this? Best Regards, Leonid Dubinsky. From owner-mpls@UU.NET Sun Jul 1 10:01: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 KAA11266 for ; Sun, 1 Jul 2001 10:01: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 QQkvum21961; Sun, 1 Jul 2001 14:01:29 GMT Received: by mail-control.mail.uu.net id QQkvum02028 for mpls-outgoing; Sun, 1 Jul 2001 14:00:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkvum01670 for ; Sun, 1 Jul 2001 14:00: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 QQkvul16457 for ; Sun, 1 Jul 2001 13:57:59 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 QQkvul17407 for ; Sun, 1 Jul 2001 13:57:59 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA21211 for mpls@uu.net; Sun, 1 Jul 2001 09:57: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 QQkvul28634 for ; Sun, 1 Jul 2001 13:57:31 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 QQkvul17800 for ; Sun, 1 Jul 2001 13:52:47 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkvul20283 for ; Sun, 1 Jul 2001 13:52:46 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 JAA29593; Sun, 1 Jul 2001 09:52:46 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB03327; Sun, 1 Jul 2001 09:52:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20010701095440.0273faf8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Jul 2001 09:56:26 -0400 To: "Leonid Dubinsky" , From: "Thomas D. Nadeau" Subject: Re: LSP in transit LSR MIBs In-Reply-To: <95734BD21894AC4B9AEF464C5A2985EA4B2C3B@bart.cwnt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Transit LSPs should be stored in the LSR-MIB as Insegment(s)-XC-Outsegment(s) entries. Thus, if you start at the ingress, you can follow the LSP across the network to the egress. If the transit LSP is used to carry traffic for a particular TE tunnel, then the MPLS-TE-MIB *may* contain that information at transit LSRs. This is not mandatory, but most implementations I know of are doing it since the information is available (via RRO/ERO). --Tom >I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out >from them where transit LSR should store information about LSPs passing >through it. Should it be placed in mplsTunnelTable? >Anyone has any thoughts on this? >Best Regards, > Leonid Dubinsky. From owner-mpls@UU.NET Sun Jul 1 10:14: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 KAA11431 for ; Sun, 1 Jul 2001 10:14: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 QQkvum25397; Sun, 1 Jul 2001 14:14:35 GMT Received: by mail-control.mail.uu.net id QQkvum19812 for mpls-outgoing; Sun, 1 Jul 2001 14: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 QQkvum19785 for ; Sun, 1 Jul 2001 14:13:48 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 QQkvum18793 for ; Sun, 1 Jul 2001 14:13:13 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 QQkvum06154 for ; Sun, 1 Jul 2001 14:13:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA22067 for mpls@uu.net; Sun, 1 Jul 2001 10:13:13 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkvum18935 for ; Sun, 1 Jul 2001 14:08: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 QQkvum13394 for ; Sun, 1 Jul 2001 14:07:51 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 QQkvum01709 for ; Sun, 1 Jul 2001 14:07:50 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 KAA29926; Sun, 1 Jul 2001 10:07:49 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB03360; Sun, 1 Jul 2001 10:07:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20010701101005.0277de38@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Jul 2001 10:11:27 -0400 To: bhaskara@turinnetworks.com, ccamp@ops.ietf.org, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: lmp mib In-Reply-To: <36EF020032CFD411B7B400508B55E590A21B3B@MILAN> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2930684==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_2930684==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I believe that the correct value should be INTEGER due to it being an enumeration. We will fix this in the next revision. --Tom >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 --=====================_2930684==_.ALT Content-Type: text/html; charset="us-ascii"
        I believe that the correct value should be
INTEGER due to it being an enumeration. We will
fix this in the next revision.

        --Tom



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
--=====================_2930684==_.ALT-- From owner-mpls@UU.NET Sun Jul 1 10:21: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 KAA11541 for ; Sun, 1 Jul 2001 10:21: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 QQkvun13545; Sun, 1 Jul 2001 14:21:27 GMT Received: by mail-control.mail.uu.net id QQkvun20586 for mpls-outgoing; Sun, 1 Jul 2001 14:20: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 QQkvun20572 for ; Sun, 1 Jul 2001 14:20:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkvun29938 for ; Sun, 1 Jul 2001 14:19:59 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 QQkvun12058 for ; Sun, 1 Jul 2001 14:19:59 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA22536 for mpls@uu.net; Sun, 1 Jul 2001 10:19: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 QQkvun20500 for ; Sun, 1 Jul 2001 14:19: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 QQkvun21980 for ; Sun, 1 Jul 2001 14:16:37 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 QQkvun27481 for ; Sun, 1 Jul 2001 14:16:37 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 KAA00072; Sun, 1 Jul 2001 10:16:37 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB03374; Sun, 1 Jul 2001 10:16:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20010701101158.01962130@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Jul 2001 10:20:17 -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:48 PM 6/29/2001 -0400, Irfan Lateef wrote: >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. Yes, it is. As I pointed out, the off-line operation is many more times difficult than using the GMPLS-TE-MIB to set up the tunnels. This is because you must do the entire offline calculation as the LSRs are doing. Again, the problem with trying to simulate/reproduce these calculations is that there are still many proprietary extensions to the standards for doing the CSPF calculation. Thus, if you would like to do the offline calculation, you will not only need the data about the network, but you will also need the specific algorithms used by the LSRs in question. >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. Much of the information you seek is currently available via the If, OSPF, BGP, MPLS and other MIBs. I know of 2 off-line TE tools that use these MIBs in concert with some CLI commands to retrieve all of the information they require to do a full offline TE calculation. These use CLI commands for some of the information since there are still some deficiencies in the available MIBs that I am others are looking into. If you have suggestions, please feel free to propose them. >>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. Please do. >> 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. Why not? Who is to say that your GMPLS control plane is not controlling something as dynamic as auto-routed MPLS? That is as dynamic as the IGP that adds the routes->LSPs. >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. Point taken. However, you must not overlook the possibility of using the control plane for "legacy" MPLS. --Tom >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 Sun Jul 1 10: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 KAA11721 for ; Sun, 1 Jul 2001 10:37: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 QQkvuo04274; Sun, 1 Jul 2001 14:38:03 GMT Received: by mail-control.mail.uu.net id QQkvuo22057 for mpls-outgoing; Sun, 1 Jul 2001 14:37: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 QQkvuo22049 for ; Sun, 1 Jul 2001 14:37: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 QQkvuo15791 for ; Sun, 1 Jul 2001 14:36:14 GMT Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.246.129]) id QQkvuo00938 for ; Sun, 1 Jul 2001 14:36:05 GMT Subject: RE: LSP in transit LSR MIBs Date: Sun, 1 Jul 2001 17:35:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <95734BD21894AC4B9AEF464C5A2985EA4D62A6@bart.cwnt.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: LSP in transit LSR MIBs Thread-Index: AcECNSwefElxYoSOQUC2Xfna6hrUXwABAlnQ From: "Leonid Dubinsky" To: "Thomas D. Nadeau" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11721 Hello Tom, Thanks for your response. That's clear you'll have to store cross-connects to mantain the LSP itself. Storing LSP information in the TE MIB is possibly the most logical possibility, but still there are things which should be split in transit, and the MIB does not support such splitting (e.g., it would be nice to divide RRO to "upstream" and "downstream" parts, show both "requested traffic parameters" from RSVP-TE PATH and "allocated parameters" from RSVP-TE RESV, etc.) What do you think is the most logical placement of this stuff in the LSR MIB tables? Best Regards, Leonid Dubinsky. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Sunday, July 01, 2001 4:56 PM To: Leonid Dubinsky; mpls@UU.NET Subject: Re: LSP in transit LSR MIBs Transit LSPs should be stored in the LSR-MIB as Insegment(s)-XC-Outsegment(s) entries. Thus, if you start at the ingress, you can follow the LSP across the network to the egress. If the transit LSP is used to carry traffic for a particular TE tunnel, then the MPLS-TE-MIB *may* contain that information at transit LSRs. This is not mandatory, but most implementations I know of are doing it since the information is available (via RRO/ERO). --Tom >I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out >from them where transit LSR should store information about LSPs passing >through it. Should it be placed in mplsTunnelTable? >Anyone has any thoughts on this? >Best Regards, > Leonid Dubinsky. From owner-mpls@UU.NET Sun Jul 1 11:49: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 LAA12307 for ; Sun, 1 Jul 2001 11:49: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 QQkvut29569; Sun, 1 Jul 2001 15:49:03 GMT Received: by mail-control.mail.uu.net id QQkvut18520 for mpls-outgoing; Sun, 1 Jul 2001 15:48: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 QQkvut18513 for ; Sun, 1 Jul 2001 15:48:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkvut21354 for ; Sun, 1 Jul 2001 15:47:05 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkvut05435 for ; Sun, 1 Jul 2001 15:47:04 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sun, 01 Jul 2001 21:24:15 +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 f61FkG928098 for ; Sun, 1 Jul 2001 21:16:17 +0530 Reply-To: From: "saumyad" To: Subject: Question regarding gmpls-te-mib Date: Sun, 1 Jul 2001 21:19:02 +1000 Message-Id: <000001c1021f$a211c5c0$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) 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 everyone, My question is regarding the "label set" and "suggested label object". I cannot find any mib object through which we can configure the suggested label or the label set object's. The configuration for these two objects if to be included in the Path message has to take place in the "ingress" of the tunnel to be established. Then how should we include these object's in the Path message. Thanks in Advance, Regards and Wishes, Saumya. From owner-mpls@UU.NET Sun Jul 1 22:57: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 WAA17635 for ; Sun, 1 Jul 2001 22:57:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkvwl22933; Mon, 2 Jul 2001 02:56:47 GMT Received: by mail-control.mail.uu.net id QQkvwl27587 for mpls-outgoing; Mon, 2 Jul 2001 02: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 QQkvwl27563 for ; Mon, 2 Jul 2001 02:56:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkvwl13765 for ; Mon, 2 Jul 2001 02:56:05 GMT Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkvwl18404 for ; Mon, 2 Jul 2001 02:56:03 GMT Received: from multitech.co.in ([210.78.155.149]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f622qTs25393; Mon, 2 Jul 2001 08:22:31 +0530 Message-ID: <3B3FE0B2.420989B6@multitech.co.in> Date: Mon, 02 Jul 2001 10:47:14 +0800 From: abhay X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Leonid Dubinsky CC: mpls@UU.NET Subject: Re: LSP in transit LSR MIBs X-Priority: 1 (Highest) References: <95734BD21894AC4B9AEF464C5A2985EA4B2C3B@bart.cwnt.com> Content-Type: multipart/alternative; boundary="------------003B943CD75DCCDD244C0A29" Sender: owner-mpls@UU.NET Precedence: bulk --------------003B943CD75DCCDD244C0A29 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lenoid, The TE-MIB at the head end which originates contains the configuration for the tunnel. At the transit and the tail ends it contains entries made by the signaling protocol, which may be RSVP/CR-LDP. Additionally each LSP can be identified by the XC Groups in the LSR MIB and there is a one to many XC Group relation from the tunnel entry in the TE-MIB to the LSP in the LSR MIB. Transit routers may contain entries made by the signaling protocol in the mplsTunnel Table ,if they have the ability to do so..as RSVP and CR-LDP have their own capabilities and pitfalls. But we can have an effective LSP control if we have entires in the transit routers,if you are interested in complete traffic engineering. Regards, Abhay Leonid Dubinsky wrote: > Hi, > I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out > from them where transit LSR should store information about LSPs passing > through it. Should it be placed in mplsTunnelTable? > Anyone has any thoughts on this? > Best Regards, > Leonid Dubinsky. --------------003B943CD75DCCDD244C0A29 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Lenoid,
       The TE-MIB at the head end which originates contains the configuration for the tunnel.
       At the transit and the tail ends it contains entries made by the signaling protocol,
       which may be RSVP/CR-LDP.
       Additionally each LSP can be identified by the XC Groups in the LSR MIB and there is a one
       to many XC Group relation from the tunnel entry in the TE-MIB to the LSP in the LSR MIB.
       Transit routers may contain entries made by the signaling protocol in the mplsTunnel Table
       ,if they have the ability to do so..as RSVP and CR-LDP have their own capabilities and pitfalls.
       But we can have an effective LSP control if we have entires in the transit routers,if you are interested
       in complete traffic engineering.
       Regards,
       Abhay
 
 


Leonid Dubinsky wrote:

Hi,
I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out
from them where transit LSR should store information about LSPs passing
through it. Should it be placed in mplsTunnelTable?
Anyone has any thoughts on this?
Best Regards,
    Leonid Dubinsky.
--------------003B943CD75DCCDD244C0A29-- From owner-mpls@UU.NET Mon Jul 2 07:51: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 HAA06562 for ; Mon, 2 Jul 2001 07:51: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 QQkvxv04873; Mon, 2 Jul 2001 11:51:25 GMT Received: by mail-control.mail.uu.net id QQkvxv13920 for mpls-outgoing; Mon, 2 Jul 2001 11:50: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 QQkvxv13898 for ; Mon, 2 Jul 2001 11:50:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkvxv12436 for ; Mon, 2 Jul 2001 11:49:55 GMT Received: from exchange01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged)) id QQkvxv03454 for ; Mon, 2 Jul 2001 11:49:55 GMT Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 2 Jul 2001 07:45:13 -0400 Message-ID: <008201c102ec$81ddd1e0$681810ac@movaz.com> From: "Adrian Farrel" To: Cc: References: <000001c1021f$a211c5c0$2a06140a@future.futsoft.com> Subject: Re: Question regarding gmpls-te-mib Date: Mon, 2 Jul 2001 07:45:35 -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: 02 Jul 2001 11:45:13.0803 (UTC) FILETIME=[74CA31B0:01C102EC] Sender: owner-mpls@UU.NET Precedence: bulk Hi Saumya, Interesting point. I think my assumption was that these values would be taken from a combination of - explicit labels in the ERO - momentary constraints in the switch itself. Label Set and Suggested Label (and Upstream Label) will (or might) change from hop to hop, and you would certainly not expect the values at a transit node to be controlled by the values at ingress, although they may be influenced by them. Does anyone else have a strong opinion about whether Label Set in particular needs to be configured at the source? Adrian ----- Original Message ----- From: "saumyad" To: Sent: Sunday, July 01, 2001 7:19 AM Subject: Question regarding gmpls-te-mib > > Hi everyone, > My question is regarding the "label set" and "suggested label object". > I cannot find any mib object through which we can configure the > suggested label or the label set object's. > The configuration for these two objects if to be included in the > Path message has to take place in the "ingress" of the tunnel to > be established. Then how should we include these object's in > the Path message. > > Thanks in Advance, > Regards and Wishes, > Saumya. From owner-mpls@UU.NET Mon Jul 2 09:03:54 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 JAA07515 for ; Mon, 2 Jul 2001 09:03:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkvya15141; Mon, 2 Jul 2001 13:03:54 GMT Received: by mail-control.mail.uu.net id QQkvya14693 for mpls-outgoing; Mon, 2 Jul 2001 13:03: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 QQkvya14455 for ; Mon, 2 Jul 2001 13:03:04 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 QQkvya24799 for ; Mon, 2 Jul 2001 13:02:46 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 QQkvya14321 for ; Mon, 2 Jul 2001 13:02:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA08922 for mpls@uu.net; Mon, 2 Jul 2001 09:02:45 -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 QQkvya12243 for ; Mon, 2 Jul 2001 13:02: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 QQkvxz04854 for ; Mon, 2 Jul 2001 12:59:03 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 QQkvxz11366 for ; Mon, 2 Jul 2001 12:59:03 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 IAA04777; Mon, 2 Jul 2001 08:59:02 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB06077; Mon, 2 Jul 2001 08:59:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20010702090034.02788910@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jul 2001 09:02:45 -0400 To: "Leonid Dubinsky" , From: "Thomas D. Nadeau" Subject: RE: LSP in transit LSR MIBs In-Reply-To: <95734BD21894AC4B9AEF464C5A2985EA4D62A6@bart.cwnt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:35 PM 7/1/2001 +0300, Leonid Dubinsky wrote: >Hello Tom, >Thanks for your response. >That's clear you'll have to store cross-connects to mantain the LSP >itself. >Storing LSP information in the TE MIB is possibly the most logical >possibility, but still there are things which should be split in >transit, and the MIB does not support such splitting (e.g., it would be >nice to divide RRO to "upstream" and "downstream" parts, show both >"requested traffic parameters" from RSVP-TE PATH and "allocated >parameters" from RSVP-TE RESV, etc.) >What do you think is the most logical placement of this stuff in the LSR >MIB tables? RRO/ERO separation on a per-tunnel basis is already done in the MPLS-TE-MIB. Take a look at the different HOP tables in the MPLS-TE-MIB. RRO/ERO is not used for non-TE LSPs (i.e.: they are set up using LDP), so it is not available in the LSR MIB. --Tom >Best Regards, > Leonid Dubinsky. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Sunday, July 01, 2001 4:56 PM >To: Leonid Dubinsky; mpls@UU.NET >Subject: Re: LSP in transit LSR MIBs > > > > Transit LSPs should be stored in the LSR-MIB as >Insegment(s)-XC-Outsegment(s) entries. Thus, if you >start at the ingress, you can follow the LSP >across the network to the egress. If the >transit LSP is used to carry traffic for a particular >TE tunnel, then the MPLS-TE-MIB *may* contain that >information at transit LSRs. This is not mandatory, >but most implementations I know of are doing it since >the information is available (via RRO/ERO). > > --Tom > > >I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out > >from them where transit LSR should store information about LSPs passing > >through it. Should it be placed in mplsTunnelTable? > >Anyone has any thoughts on this? > >Best Regards, > > Leonid Dubinsky. From owner-mpls@UU.NET Mon Jul 2 09:41: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 JAA10471 for ; Mon, 2 Jul 2001 09:41: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 QQkvyc07843; Mon, 2 Jul 2001 13:41:25 GMT Received: by mail-control.mail.uu.net id QQkvyc02666 for mpls-outgoing; Mon, 2 Jul 2001 13:40: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 QQkvyc02654 for ; Mon, 2 Jul 2001 13:40: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 QQkvyc00443 for ; Mon, 2 Jul 2001 13:31:29 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkvyc02848 for ; Mon, 2 Jul 2001 13:31:29 GMT Message-ID: <3B4077A0.769D5483@sandburst.com> Date: Mon, 02 Jul 2001 09:31:13 -0400 From: Eric Gray MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: lmp mib References: <4.3.2.7.2.20010701101005.0277de38@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I believe this discussion belongs on the CCAMP mailing list. "Thomas D. Nadeau" wrote: > > I believe that the correct value should be > INTEGER due to it being an enumeration. We will > fix this in the next revision. > > --Tom > > > > >> 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 > From owner-mpls@UU.NET Mon Jul 2 09:45: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 JAA12836 for ; Mon, 2 Jul 2001 09:45: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 QQkvyd13376; Mon, 2 Jul 2001 13:45:40 GMT Received: by mail-control.mail.uu.net id QQkvyd03328 for mpls-outgoing; Mon, 2 Jul 2001 13:45: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 QQkvyc03116 for ; Mon, 2 Jul 2001 13:44: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 QQkvyc19768 for ; Mon, 2 Jul 2001 13:43:20 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 QQkvyc11106 for ; Mon, 2 Jul 2001 13:43:18 GMT Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 19:16:21 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C568761C574@HUAWEIMAIL> To: mpls@UU.NET, mpls-ops@mplsrc.com Subject: Negotiation for RSVP Date: Mon, 2 Jul 2001 19:16:14 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10301.8D710710" 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_01C10301.8D710710 Content-Type: text/plain; charset="iso-8859-1" Hello all Does RSVP can support negotiation of resources (b/w etc) like CR-LDP ???? If so please let me know about it. Thanks in Adavance Ashwin ------_=_NextPart_001_01C10301.8D710710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Negotiation for RSVP

Hello all

         Does = RSVP can support negotiation of resources (b/w etc) like CR-LDP ???? If = so please
         let me = know about it.

Thanks in Adavance
Ashwin

------_=_NextPart_001_01C10301.8D710710-- From owner-mpls@UU.NET Mon Jul 2 10:27: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 KAA23226 for ; Mon, 2 Jul 2001 10:27: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 QQkvyf16100; Mon, 2 Jul 2001 14:28:01 GMT Received: by mail-control.mail.uu.net id QQkvyf27152 for mpls-outgoing; Mon, 2 Jul 2001 14:27:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkvyf27147 for ; Mon, 2 Jul 2001 14:27:24 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 QQkvyf29052 for ; Mon, 2 Jul 2001 14:26:58 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 QQkvyf24104 for ; Mon, 2 Jul 2001 14:26:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA14528 for mpls@uu.net; Mon, 2 Jul 2001 10:26: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 QQkvyf27073 for ; Mon, 2 Jul 2001 14:26: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 QQkvyf27490 for ; Mon, 2 Jul 2001 14:25:52 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 QQkvyf18839 for ; Mon, 2 Jul 2001 14:25:52 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 KAA12925; Mon, 2 Jul 2001 10:25:51 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACC00063; Mon, 2 Jul 2001 10:25:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20010702102914.027d9270@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jul 2001 10:29:34 -0400 To: Eric Gray , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: lmp mib In-Reply-To: <3B4077A0.769D5483@sandburst.com> References: <4.3.2.7.2.20010701101005.0277de38@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I just reply to the messages; don't have time to mess with the headers. --Tom >I believe this discussion belongs on the CCAMP mailing list. > > >"Thomas D. Nadeau" wrote: > > > > > I believe that the correct value should be > > INTEGER due to it being an enumeration. We will > > fix this in the next revision. > > > > --Tom > > > > > > > > > >> 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 > > From owner-mpls@UU.NET Mon Jul 2 13:36: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 NAA27778 for ; Mon, 2 Jul 2001 13:36:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkvys07230; Mon, 2 Jul 2001 17:36:42 GMT Received: by mail-control.mail.uu.net id QQkvys16580 for mpls-outgoing; Mon, 2 Jul 2001 17:36: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 QQkvys16529 for ; Mon, 2 Jul 2001 17:35: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 QQkvys06275 for ; Mon, 2 Jul 2001 17:31:00 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkvys08371 for ; Mon, 2 Jul 2001 17:30:59 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id NAA32092 for ; Mon, 2 Jul 2001 13:30:59 -0400 (EDT) Date: Mon, 2 Jul 2001 13:30:59 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: mpls@UU.NET Subject: MPLS 2001 International Conference Update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk MPLS2001 International Conference 4th Annual International Conference on MPLS October 7-9, 2001 Omni Shoreham Hotel, Washington, DC. Hosted jointly by UUNET Technologies/Worldcom and Advanced Internet Laboratory Program Schedule Tutorials : October 7, 1:00 - 6:00 Conference sessions : October 8-9, 8:30 am - 6:00 pm Exhibits : October 8-9 2nd Public Inter-Op Demo: October 10-12 We are delighted to inform you that the 4th Annual International Conference on MPLS, co-hosted by WorldCom (UUNET Technologies) and Advanced Internet Lab of GMU, is being sponsored by Agilent Technologies, Alcatel, Avici Systems, Cisco Systems, Data Connection, IXIA, Lucent Technologies, Marconi, Metera Networks, Nortel Networks, Ocular Networks, OPNET Technologies, Spirent Communications, Unisphere Networks, and Wavesmith Networks. Sponsors will be exhibiting their products and services throughout the day Monday and Tuesday. The technical program for MPLS 2001 is unique, as were the programs for previous events in this series. MPLS 2001 offers an excellent blend of various topics covering important aspects of MPLS and its application in Optical Networks. The preliminary technical program has been posted at MPLS 2001 website under technical sessions (http://www.mpls2001.com/technical.htm) and will continuously be updated. The Registration for MPLS 2001 is open and you can register by visiting http://www.mpls2001.com and clicking the "Registration" button. Due to the support provided by the conference sponsors we have managed to keep the registration cost to a nominal fee. The early registration fees are extremely attractive and we hope you can benefit from the opportunity and pre-register for MPLS2001 soon. Also, we have blocked limited number rooms at Omni Shoreham Hotel (Conference Venue and the designated hotel) at special rates and we urge you to make your reservations immediately. You may visit our website for more information and click on "Hotels and Travel" button. For additional information, hotel reservation and registration, please visit http://www.mpls2001.com. We look forward to seeing you in the "MPLS 2001 International Conference." Thanks. Regards, -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Mon Jul 2 13:54: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 NAA09257 for ; Mon, 2 Jul 2001 13:54: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 QQkvyt28495; Mon, 2 Jul 2001 17:54:53 GMT Received: by mail-control.mail.uu.net id QQkvyt18785 for mpls-outgoing; Mon, 2 Jul 2001 17:54: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 QQkvyt18686 for ; Mon, 2 Jul 2001 17:54:00 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 QQkvyt02407 for ; Mon, 2 Jul 2001 17:53:44 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 QQkvyt27111 for ; Mon, 2 Jul 2001 17:53:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA29586 for mpls@uu.net; Mon, 2 Jul 2001 13:53:43 -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 QQkvyt18606 for ; Mon, 2 Jul 2001 17:53: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 QQkvyt15547 for ; Mon, 2 Jul 2001 17:52:23 GMT Received: from netmail.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail.alcatel.com [128.251.168.50]) id QQkvyt06689 for ; Mon, 2 Jul 2001 17:52:23 GMT Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA29232 for ; Mon, 2 Jul 2001 12:52:22 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f62HqMp18789 for ; Mon, 2 Jul 2001 12:52:22 -0500 (CDT) Message-ID: <3B40B46C.A84D37D8@usa.alcatel.com> Date: Mon, 02 Jul 2001 12:50:36 -0500 From: Aziz Mohammed X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit auth 487d0498 subscribe mpls Aziz.Mohammed@usa.alcatel.com From owner-mpls@UU.NET Mon Jul 2 15:24: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 PAA08164 for ; Mon, 2 Jul 2001 15:24: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 QQkvyz18318; Mon, 2 Jul 2001 19:24:23 GMT Received: by mail-control.mail.uu.net id QQkvyz06846 for mpls-outgoing; Mon, 2 Jul 2001 19:23: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 QQkvyz06834 for ; Mon, 2 Jul 2001 19:23: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 QQkvyz22933 for ; Mon, 2 Jul 2001 19:17:51 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 QQkvyz21911 for ; Mon, 2 Jul 2001 19:17: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 f62JHux25448 for ; Mon, 2 Jul 2001 12:17:57 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA20163 for mpls@uu.net; Mon, 2 Jul 2001 15:17:47 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkvyz05807 for ; Mon, 2 Jul 2001 19:15:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkvyy05282 for ; Mon, 2 Jul 2001 19:14:09 GMT Received: from ws1-6.us4.outblaze.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: 205-158-62-53.outblaze.com [205.158.62.53]) id QQkvyy13461 for ; Mon, 2 Jul 2001 19:14:08 GMT Received: (qmail 10649 invoked by uid 1001); 2 Jul 2001 19:14:07 -0000 Message-ID: <20010702191407.10636.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from ws1-6.us4.outblaze.com for [63.197.247.13] via web-mailer on Tue, 03 Jul 2001 03:14:05 +0800 From: "Manasa M" To: mpls@UU.NET Date: Tue, 03 Jul 2001 03:14:05 +0800 Subject: TE-MIB and RSVP Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, 1)Can we have a parallel tunnels with same tunnel id but, with a different tunnel instances running and loading sharing traffic with different paths altogether from ingress to egress, not just for make before break or rerouting a part of the path. for example in the case of SONET/SDH ring, can we use it as one instance is for working path and 2nd instance is for protection path? 2) why is the restrction of tunnel id to be just 16 bit in RSVP-TE, is there any technical reason behind it? as it may be problem if we have lots of unnumbered interfaces expecially in packet router with lots of ppp/vpn links? rgds manasa -- _______________________________________________ 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 From owner-mpls@UU.NET Mon Jul 2 19:55: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 TAA26618 for ; Mon, 2 Jul 2001 19:55: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 QQkvzr13445; Mon, 2 Jul 2001 23:55:48 GMT Received: by mail-control.mail.uu.net id QQkvzr23844 for mpls-outgoing; Mon, 2 Jul 2001 23:55: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 QQkvzr23821 for ; Mon, 2 Jul 2001 23:54: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 QQkvzr23696 for ; Mon, 2 Jul 2001 23:54:36 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 QQkvzr11965 for ; Mon, 2 Jul 2001 23:54:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA19725 for mpls@uu.net; Mon, 2 Jul 2001 19:54:35 -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 QQkvzr23771 for ; Mon, 2 Jul 2001 23:54:08 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 QQkvzr21730 for ; Mon, 2 Jul 2001 23:53:02 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 QQkvzr10084 for ; Mon, 2 Jul 2001 23:53:01 GMT Received: from mira1.cisco.com (mira1.cisco.com [171.71.208.193]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f62Nr0h03986; Mon, 2 Jul 2001 16:53:00 -0700 (PDT) Received: from cisco.com (skatukam-u5.cisco.com [171.71.213.88]) by mira1.cisco.com (Mirapoint) with ESMTP id ACR00448; Mon, 2 Jul 2001 16:52:58 -0700 (PDT) Message-ID: <3B41095A.9ED2E762@cisco.com> Date: Mon, 02 Jul 2001 16:52:58 -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: Manasa M CC: mpls@UU.NET Subject: Re: TE-MIB and RSVP References: <20010702191407.10636.qmail@mail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manasa, > > 1)Can we have a parallel tunnels with same tunnel id but, with a different tunnel instances running and > loading sharing traffic with different paths altogether from ingress to egress, not just for > make before break or rerouting a part of the path. > for example in the case of SONET/SDH ring, can we use it as one instance is for working path and 2nd instance is for protection path? For Load Sharing, It does not have to be a same tunnel ID as long as Source and Destination know that there are two LSPs for Load Sharing. Anyways, Yes, You can have same Tunnel ID with different LSP ids. This is possible and it is upto Source and Destination to use these LSPs the way they want. If you do not use SE bit, then these are for all practical purposes, are two different LSPs. You could use SE bit to avoid setting up bandwidth twice on a common set of links. For example, in SONET BLSR, I do not think that you need to set up two instances of LSPs since standard BLSR mechanism takes care of protection. Ofcourse, this results in adjacent nodes time out RSVP states etc. I think you are not supposed to delete the LSP except indicate to Source or Destination of the LSP that you lost connection with your neighbor. Source or Destination can look into the health of LSP data traffic and also realize that BLSR link went down, it could keep the LSP alive until it sees the data on LSP is affected. For Standard UPSR, similar mechanism applies. For Virtual UPSR (Or 1+1 path Protection), you would set up two LSPs with same Tunnel ID, but different LSP ids. Thanks, Suresh From owner-mpls@UU.NET Mon Jul 2 21:59: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 VAA15141 for ; Mon, 2 Jul 2001 21:59: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 QQkvzz12070; Tue, 3 Jul 2001 01:59:47 GMT Received: by mail-control.mail.uu.net id QQkvzz15900 for mpls-outgoing; Tue, 3 Jul 2001 01:59:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkvzz15887 for ; Tue, 3 Jul 2001 01:59:06 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 QQkvzz02411 for ; Tue, 3 Jul 2001 01:57:54 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 QQkvzz08856 for ; Tue, 3 Jul 2001 01:57:40 GMT Received: from ipinfusion.com (IDENT:root@[10.10.0.38]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id f632TaY15546 for ; Mon, 2 Jul 2001 19:29:40 -0700 Message-ID: <3B412812.6E7CDA26@ipinfusion.com> Date: Mon, 02 Jul 2001 19:04:02 -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: Loop Detection doubts !! 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 the following doubts in RFC 3036. 1) In LMp.6 and LMP.7, what happens if the label being deleted maps to one or more upstream labels ? If those labels are not withdrawn, then the LSR in question would end up discarding all the incoming packets bearing those labels. 2) In LMp.23 (Note 9), only path vector attribute is considered. Is there a reason for not considering hop count attribute. 4) How should an LSR handle the case when a label release bearing a loop detection information arrives. Taking the same action as is done for "No Route" case doesn't seem right. 5) When a loop detection notification arrives in response to a request message, the LSR receiving this message defers this request and sends it repeatedly with the same attributes. Now, if the request attributes cause the nexthop to send a loop detction message (maybe due to path vector or hop count attributes), then what is the use of sending the same message again. thanks in advance manoj From owner-mpls@UU.NET Tue Jul 3 01:08: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 BAA12251 for ; Tue, 3 Jul 2001 01:08: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 QQkwam06735; Tue, 3 Jul 2001 05:08:41 GMT Received: by mail-control.mail.uu.net id QQkwam23028 for mpls-outgoing; Tue, 3 Jul 2001 05:08: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 QQkwam22426 for ; Tue, 3 Jul 2001 05:07:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwam27729 for ; Tue, 3 Jul 2001 05:05:41 GMT Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.246.129]) id QQkwam19782 for ; Tue, 3 Jul 2001 05:05:41 GMT content-class: urn:content-classes:message Subject: RE: Negotiation for RSVP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Jul 2001 08:05:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <95734BD21894AC4B9AEF464C5A2985EA4B2C4B@bart.cwnt.com> Thread-Topic: Negotiation for RSVP Thread-Index: AcEDDJyMHgsN8vCPS2umFMl+Q3veTQAcKvng From: "Leonid Dubinsky" To: , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA12251 Hello Ashwin, RSVP-TE inserts two resource related objects into the PATH message: TSpec and ADSpec; intermediate LSRs are to update ADSpec to reflect the amount of reservable resources available. Upon receipt of PATH in the egress, egress LSR can decide how to convert TSpec and ADSpec into Flowspec, which actually specifies the resources to be reserved. With right ADSpec modification rules and Flowspec generation you can achieve the same goals as with CR-LDP negotiation. Hope this helps. Best Regards, Leonid Dubinsky. -----Original Message----- From: Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com] Sent: Monday, July 02, 2001 5:16 PM To: mpls@UU.NET; mpls-ops@mplsrc.com Subject: Negotiation for RSVP Hello all Does RSVP can support negotiation of resources (b/w etc) like CR-LDP ???? If so please let me know about it. Thanks in Adavance Ashwin From owner-mpls@UU.NET Tue Jul 3 01:34: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 SMTP id BAA29107 for ; Tue, 3 Jul 2001 01:34: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 QQkwao10468; Tue, 3 Jul 2001 05:34:52 GMT Received: by mail-control.mail.uu.net id QQkwao26590 for mpls-outgoing; Tue, 3 Jul 2001 05:34:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwao26579 for ; Tue, 3 Jul 2001 05:34: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 QQkwao08279 for ; Tue, 3 Jul 2001 05:32:00 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 QQkwao06483 for ; Tue, 3 Jul 2001 05:31:54 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 f635VoE29028; Tue, 3 Jul 2001 07:31:50 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A7E.001E6074 ; Tue, 3 Jul 2001 07:31:47 +0200 X-Lotus-FromDomain: ALCATEL cc: mpls@UU.NET, Suresh Katukam Message-ID: Date: Tue, 3 Jul 2001 07:31:44 +0200 Subject: Re: TE-MIB and RSVP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Manasa, As Suresh indicates it is possible to share resources between the working path and the path used for protection. However, when doing this a price is paid in terms of a reduced protection: if a link / node that is used by both the working path and the protecting path fails, both paths are gone. Francis. Suresh Katukam on 03/07/2001 01:52:58 To: Manasa M cc: mpls@UU.NET(bcc: Francis ARTS/BE/ALCATEL) Subject: Re: TE-MIB and RSVP Manasa, > > 1)Can we have a parallel tunnels with same tunnel id but, with a different tunnel instances running and > loading sharing traffic with different paths altogether from ingress to egress, not just for > make before break or rerouting a part of the path. > for example in the case of SONET/SDH ring, can we use it as one instance is for working path and 2nd instance is for protection path? For Load Sharing, It does not have to be a same tunnel ID as long as Source and Destination know that there are two LSPs for Load Sharing. Anyways, Yes, You can have same Tunnel ID with different LSP ids. This is possible and it is upto Source and Destination to use these LSPs the way they want. If you do not use SE bit, then these are for all practical purposes, are two different LSPs. You could use SE bit to avoid setting up bandwidth twice on a common set of links. For example, in SONET BLSR, I do not think that you need to set up two instances of LSPs since standard BLSR mechanism takes care of protection. Ofcourse, this results in adjacent nodes time out RSVP states etc. I think you are not supposed to delete the LSP except indicate to Source or Destination of the LSP that you lost connection with your neighbor. Source or Destination can look into the health of LSP data traffic and also realize that BLSR link went down, it could keep the LSP alive until it sees the data on LSP is affected. For Standard UPSR, similar mechanism applies. For Virtual UPSR (Or 1+1 path Protection), you would set up two LSPs with same Tunnel ID, but different LSP ids. Thanks, Suresh From owner-mpls@UU.NET Tue Jul 3 04:31: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 EAA23823 for ; Tue, 3 Jul 2001 04:31:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwba12897; Tue, 3 Jul 2001 08:32:09 GMT Received: by mail-control.mail.uu.net id QQkwba14448 for mpls-outgoing; Tue, 3 Jul 2001 08:31:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwba14379 for ; Tue, 3 Jul 2001 08:31:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwaz15102 for ; Tue, 3 Jul 2001 08:29:27 GMT Received: from EXCHANGE.kerenix.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.150.1.82]) id QQkwaz14625 for ; Tue, 3 Jul 2001 08:29:25 GMT Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Jul 2001 11:32:20 +0300 Message-ID: <2B15221907365C468941FDFC02C87769CF7A@EXCHANGE.kerenix.com> From: Vadim Suraev To: "'Leonid Dubinsky'" , Ashwinp@in.huawei.com Cc: mpls@UU.NET, mpls-ops@mplsrc.com Subject: RE: Negotiation for RSVP Date: Tue, 3 Jul 2001 11:32:19 +0300 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 Leonid, > -----Original Message----- > From: Leonid Dubinsky [mailto:leonid@cwnt.com] > Sent: Tuesday, July 03, 2001 8:06 AM > To: Ashwinp@in.huawei.com; mpls@UU.NET; mpls-ops@mplsrc.com > Subject: RE: Negotiation for RSVP > > > Hello Ashwin, > RSVP-TE inserts two resource related objects into the PATH message: > TSpec and ADSpec; intermediate LSRs are to update ADSpec to > reflect the > amount of reservable resources available. > Upon receipt of PATH in the egress, egress LSR can decide how > to convert > TSpec and ADSpec into Flowspec, which actually specifies the resources > to be reserved. With right ADSpec modification rules and Flowspec > generation you can achieve the same goals as with CR-LDP negotiation. If I'm not mistaken, when CR-LDP is used to establish LSP, Ingress LER can explicitly tell that traffic parameters are negotiable and which traffic parameters are negotiable. As far as I know, in RSVP-TE the Ingress LER does not have a way to tell explicitly, whether traffic parameters negotiation is allowed or not. Best regards, Vadim. > Hope this helps. > Best Regards, > Leonid Dubinsky. > -----Original Message----- > From: Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com] > Sent: Monday, July 02, 2001 5:16 PM > To: mpls@UU.NET; mpls-ops@mplsrc.com > Subject: Negotiation for RSVP > > > > > > Hello all > Does RSVP can support negotiation of resources (b/w etc) like > CR-LDP ???? If so please > let me know about it. > Thanks in Adavance > Ashwin > From owner-mpls@UU.NET Tue Jul 3 04:49: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 EAA04961 for ; Tue, 3 Jul 2001 04:49: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 QQkwbb06420; Tue, 3 Jul 2001 08:49:37 GMT Received: by mail-control.mail.uu.net id QQkwbb17298 for mpls-outgoing; Tue, 3 Jul 2001 08:49: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 QQkwbb17241 for ; Tue, 3 Jul 2001 08:48:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwbb22212 for ; Tue, 3 Jul 2001 08:46:11 GMT Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.246.129]) id QQkwbb02117 for ; Tue, 3 Jul 2001 08:46:09 GMT content-class: urn:content-classes:message Subject: RE: LSP in transit LSR MIBs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Jul 2001 11:46:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <95734BD21894AC4B9AEF464C5A2985EA4D62A7@bart.cwnt.com> Thread-Topic: LSP in transit LSR MIBs Thread-Index: AcEC9wTLv6Rjxcj9R4SZ9Lno4Fv10AApJRbA From: "Leonid Dubinsky" To: "Thomas D. Nadeau" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04961 Tom, I'm not sure I explained it right. Consider LSR B which is transit node for an LSP, it has to RRO vectors: one describing path from ingress to B (from PATH message) and other RRO for path from egress to B. As far as I understand, mplsTunnelTable does not contain two pointers into ARHopTable to store this information. So how should these two RRO lists be stored? The same concern can be applied to TSpec as compared to Flowspec. Best Regards, Leonid Dubinsky. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Monday, July 02, 2001 4:03 PM To: Leonid Dubinsky; mpls@UU.NET Subject: RE: LSP in transit LSR MIBs At 05:35 PM 7/1/2001 +0300, Leonid Dubinsky wrote: >Hello Tom, >Thanks for your response. >That's clear you'll have to store cross-connects to mantain the LSP >itself. >Storing LSP information in the TE MIB is possibly the most logical >possibility, but still there are things which should be split in >transit, and the MIB does not support such splitting (e.g., it would be >nice to divide RRO to "upstream" and "downstream" parts, show both >"requested traffic parameters" from RSVP-TE PATH and "allocated >parameters" from RSVP-TE RESV, etc.) >What do you think is the most logical placement of this stuff in the LSR >MIB tables? RRO/ERO separation on a per-tunnel basis is already done in the MPLS-TE-MIB. Take a look at the different HOP tables in the MPLS-TE-MIB. RRO/ERO is not used for non-TE LSPs (i.e.: they are set up using LDP), so it is not available in the LSR MIB. --Tom >Best Regards, > Leonid Dubinsky. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Sunday, July 01, 2001 4:56 PM >To: Leonid Dubinsky; mpls@UU.NET >Subject: Re: LSP in transit LSR MIBs > > > > Transit LSPs should be stored in the LSR-MIB as >Insegment(s)-XC-Outsegment(s) entries. Thus, if you >start at the ingress, you can follow the LSP >across the network to the egress. If the >transit LSP is used to carry traffic for a particular >TE tunnel, then the MPLS-TE-MIB *may* contain that >information at transit LSRs. This is not mandatory, >but most implementations I know of are doing it since >the information is available (via RRO/ERO). > > --Tom > > >I've read the drafts LSR MIB and TE-MIB, but I was unable to figure out > >from them where transit LSR should store information about LSPs passing > >through it. Should it be placed in mplsTunnelTable? > >Anyone has any thoughts on this? > >Best Regards, > > Leonid Dubinsky. From owner-mpls@UU.NET Tue Jul 3 06:24:34 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 GAA03887 for ; Tue, 3 Jul 2001 06:24:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwbh21971; Tue, 3 Jul 2001 10:24:10 GMT Received: by mail-control.mail.uu.net id QQkwbh10570 for mpls-outgoing; Tue, 3 Jul 2001 10:23:38 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 QQkwbh10559 for ; Tue, 3 Jul 2001 10:23:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwbh08062 for ; Tue, 3 Jul 2001 10:23:11 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 QQkwbh20546 for ; Tue, 3 Jul 2001 10:23:09 GMT Received: (qmail 4798 invoked from network); 3 Jul 2001 10:16:23 -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; 3 Jul 2001 10:16:23 -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 PAA05620; Tue, 3 Jul 2001 15:53:37 +0530 (IST) Received: from localhost (gabhijit@localhost) by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id PAA01549; Tue, 3 Jul 2001 15:56:28 +0530 X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Tue, 3 Jul 2001 15:56:23 +0530 (IST) From: Abhijit Gadgil To: Manoj Dutta cc: Subject: Re: Loop Detection doubts !! In-Reply-To: <3B412812.6E7CDA26@ipinfusion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 2 Jul 2001, Manoj Dutta wrote: >Hi, > >I have the following doubts in RFC 3036. > >1) In LMp.6 and LMP.7, what happens if the label being deleted maps to >one or more upstream labels ? If those labels are not withdrawn, then >the LSR in question would end up discarding all the incoming packets >bearing those labels. Sending withdraw message is not required here, as we _do have_ outgoing label for all those incoming upstream labels. What basically is being tried to achieve here is to stop an attempt to create multiple bindings. The newly learned label is perhaps _better_ so use it instead of the old label. Why would u send withdraw. If u send withdraw u will also have to send another mapping perhaps unsolicitedly. If the attributes of newly received label are different than those of previously received one, that will be taken care of in subsequent processing. (LMp. 17 loop) > >2) In LMp.23 (Note 9), only path vector attribute is considered. Is >there a reason for not considering hop count attribute. It does not explicitely prevents from checking Hop Count. On the other hand hop-count should be checked. Note 9 is illustrating on what to do with path vectors. > >4) How should an LSR handle the case when a label release bearing a >loop detection information arrives. Taking the same action as is done >for "No Route" case doesn't seem right. > can u please point, where it is stated so, I am not able to find it out in the rfc. Perhaps you are refering to A.1.11., it is not stating actions pertaining to label release message, so I think the section A.1.4 should be followed. I think a note at the end of A.1.11 can be added to point out label handeling case if at all or the note at the end of A.1.11 can be appended with following sentence. If the Loop Detected Status Code comes in Label Release message, follow the algorithm for the Label Release message instead of No Route notification. (I don't think this is even necessary as it is obvious) >5) When a loop detection notification arrives in response to a request >message, the LSR receiving this message defers this request and sends >it repeatedly with the same attributes. Now, if the request attributes >cause the nexthop to send a loop detction message (maybe due to path >vector or hop count attributes), >then what is the use of sending the same message again. > hmm thats interesting. Sorry, I cannot think of any good answer. The only reason why the attributes are resent is that one does not know the exact reason for loop detection. So the attributes are sent in the hope that this time they will be correct. Implementation can take care of such things where it makes a check at outgoing Path Vector while sending the message, and stop it from delievering if it indeed finds the address of the LSR to which it is being sent.( Thanks Eric for similar explaination in some previous mail. ) >thanks in advance >manoj -abhijit -- Abhijit Gadgil Graduate Student, Dept. of Electrical Engineering, IIT, Bombay. From owner-mpls@UU.NET Tue Jul 3 09:06: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 JAA15795 for ; Tue, 3 Jul 2001 09:06:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwbs16690; Tue, 3 Jul 2001 13:05:22 GMT Received: by mail-control.mail.uu.net id QQkwbs26611 for mpls-outgoing; Tue, 3 Jul 2001 13:04: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 QQkwbs26576 for ; Tue, 3 Jul 2001 13:04:38 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 QQkwbs02141 for ; Tue, 3 Jul 2001 13:01:30 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 QQkwbs11956 for ; Tue, 3 Jul 2001 13:01:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA21807 for mpls@uu.net; Tue, 3 Jul 2001 09:01:29 -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 QQkwbs18369 for ; Tue, 3 Jul 2001 13:00: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 QQkwbs04473 for ; Tue, 3 Jul 2001 13:00:16 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkwbs10248 for ; Tue, 3 Jul 2001 13:00:16 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 JAA13734; Tue, 3 Jul 2001 09:00:13 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD10794; Tue, 3 Jul 2001 09:00:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20010703085944.01953870@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Jul 2001 09:03:53 -0400 To: "Leonid Dubinsky" , From: "Thomas D. Nadeau" Subject: RE: LSP in transit LSR MIBs In-Reply-To: <95734BD21894AC4B9AEF464C5A2985EA4D62A7@bart.cwnt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I'm not sure I explained it right. >Consider LSR B which is transit node for an LSP, it has to RRO vectors: >one describing path from ingress to B (from PATH message) and other RRO >for path from egress to B. How would these be two different RROs? The LSP should only have one RRO for the currently signaled path. I think that you are confused about how the LSPs are signaled. A single ERO is sent in the forward direction, and a single RRO is returned in the reverse direction. >As far as I understand, mplsTunnelTable does >not contain two pointers into ARHopTable to store this information. Right, the currently signaled RRO is contained in the table. In your example, which looks like the following A ... B ... C tunnelA --------> the RRO table at B for tunnelA from A-C would contain an entry in the RRO table that was A,B,C. It can form this by using the ERO in the forward direction, and the RRO in the reverse direction to construct the entire path taken by the tunnel. --Tom >So how should these two RRO lists be stored? The same concern can be >applied to TSpec as compared to Flowspec. >Best Regards, > Leonid Dubinsky. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Monday, July 02, 2001 4:03 PM >To: Leonid Dubinsky; mpls@UU.NET >Subject: RE: LSP in transit LSR MIBs > > >At 05:35 PM 7/1/2001 +0300, Leonid Dubinsky wrote: > >Hello Tom, > >Thanks for your response. > >That's clear you'll have to store cross-connects to mantain the LSP > >itself. > >Storing LSP information in the TE MIB is possibly the most logical > >possibility, but still there are things which should be split in > >transit, and the MIB does not support such splitting (e.g., it would be > >nice to divide RRO to "upstream" and "downstream" parts, show both > >"requested traffic parameters" from RSVP-TE PATH and "allocated > >parameters" from RSVP-TE RESV, etc.) > >What do you think is the most logical placement of this stuff in the >LSR > >MIB tables? > > RRO/ERO separation on a per-tunnel basis is already >done in the MPLS-TE-MIB. Take a look at the different >HOP tables in the MPLS-TE-MIB. RRO/ERO is not used for >non-TE LSPs (i.e.: they are set up using LDP), so it is >not available in the LSR MIB. > > --Tom > > > > >Best Regards, > > Leonid Dubinsky. > > > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Sunday, July 01, 2001 4:56 PM > >To: Leonid Dubinsky; mpls@UU.NET > >Subject: Re: LSP in transit LSR MIBs > > > > > > > > Transit LSPs should be stored in the LSR-MIB as > >Insegment(s)-XC-Outsegment(s) entries. Thus, if you > >start at the ingress, you can follow the LSP > >across the network to the egress. If the > >transit LSP is used to carry traffic for a particular > >TE tunnel, then the MPLS-TE-MIB *may* contain that > >information at transit LSRs. This is not mandatory, > >but most implementations I know of are doing it since > >the information is available (via RRO/ERO). > > > > --Tom > > > > >I've read the drafts LSR MIB and TE-MIB, but I was unable to figure >out > > >from them where transit LSR should store information about LSPs >passing > > >through it. Should it be placed in mplsTunnelTable? > > >Anyone has any thoughts on this? > > >Best Regards, > > > Leonid Dubinsky. From owner-mpls@UU.NET Tue Jul 3 09:44:16 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 JAA07799 for ; Tue, 3 Jul 2001 09:44:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwbu06655; Tue, 3 Jul 2001 13:44:26 GMT Received: by mail-control.mail.uu.net id QQkwbu09155 for mpls-outgoing; Tue, 3 Jul 2001 13:43:50 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 QQkwbu09137 for ; Tue, 3 Jul 2001 13:43:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkwbu01983 for ; Tue, 3 Jul 2001 13:40:46 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkwbu02885 for ; Tue, 3 Jul 2001 13:40:46 GMT Message-ID: <3B41CB5D.C1E3A4B0@sandburst.com> Date: Tue, 03 Jul 2001 09:40:45 -0400 From: Eric Gray MIME-Version: 1.0 To: Manoj Dutta Cc: mpls@UU.NET Subject: Re: Loop Detection doubts !! References: <3B412812.6E7CDA26@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, See comments in line... You wrote: > Hi, > > I have the following doubts in RFC 3036. > > 1) In LMp.6 and LMP.7, what happens if the label being deleted maps to > one or more upstream labels ? If those labels are not withdrawn, then > the LSR in question would end up discarding all the incoming packets > bearing those labels. Maybe. The procedure specification should be silent on this point because whether or not the packets are dropped may be either an implementation or a deployment choice. Consider this: if the LSR has no choice but to drop the packets, then why would the ingress to the LSP for these packets have a choice? So, there may be a trade off between wasting network resources to get packets to this LSR - only to have them dropped - and taking a bit longer to re-establish an LSP once the loop is resolved. And, if the LSR has a choice between dropping the packets or forwarding them as IP packets, then the LSP is still useful - if a bit shorter. > > > 2) In LMp.23 (Note 9), only path vector attribute is considered. Is > there a reason for not considering hop count attribute. I think Note 9 could include Hop Count. The issue seems to be that considering the Path Vector is more complicated since it is likely that the previous Path Vector was not stored. Moreover, it is likely that an LSR would not perform a check of the Path Vector - even if the earlier Path Vector was retained - because the check is somewhat harder to do than it is to simply forward the message including the Path Vector. It may simply be that the authors felt that checking the Hop Count was obvious. There is no implication in Note 9 that Path Vector is the only thing checked, and the need to check Hop Count is described elsewhere (see, for instance, the 3rd bullet on page 27, 1st paragraph on page 28 and the entirety of section 3.4.4.1 starting on page 40). > > > 4) How should an LSR handle the case when a label release bearing a > loop detection information arrives. Taking the same action as is done > for "No Route" case doesn't seem right. Not sure where you get this from. The LSR should handle a Label Release using the procedures described in Appendix section A.1.4. > > > 5) When a loop detection notification arrives in response to a request > message, the LSR receiving this message defers this request and sends > it repeatedly with the same attributes. Now, if the request attributes > cause the nexthop to send a loop detction message (maybe due to path > vector or hop count attributes), > then what is the use of sending the same message again. The analogy between "Loop Detected" and "No Route" is a good one. Both are presumed to be temporary conditions resulting from a routing transient. Where the presumption is wrong for one, it is likely wrong for the other. For this reason, the implementor should provide some indication to the network operator when some number of retries have failed. > > > thanks in advance > manoj -- Eric Gray From owner-mpls@UU.NET Tue Jul 3 09:50: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 JAA11640 for ; Tue, 3 Jul 2001 09:50: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 QQkwbv11026; Tue, 3 Jul 2001 13:50:24 GMT Received: by mail-control.mail.uu.net id QQkwbv10088 for mpls-outgoing; Tue, 3 Jul 2001 13:49: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 QQkwbv10068 for ; Tue, 3 Jul 2001 13:49:13 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 QQkwbv29892 for ; Tue, 3 Jul 2001 13:45:36 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 QQkwbv08276 for ; Tue, 3 Jul 2001 13:45:36 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25618 for ; Tue, 3 Jul 2001 09:45:34 -0400 (EDT) Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03914 for ; Tue, 3 Jul 2001 09:45:34 -0400 (EDT) Message-ID: <3B41CC81.20BB686D@marconi.com> Date: Tue, 03 Jul 2001 09:45:37 -0400 From: Jack Brennen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LSP in transit LSR MIBs References: <4.3.2.7.2.20010703085944.01953870@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Thomas D. Nadeau" wrote: > > >I'm not sure I explained it right. > >Consider LSR B which is transit node for an LSP, it has to RRO vectors: > >one describing path from ingress to B (from PATH message) and other RRO > >for path from egress to B. > > How would these be two different RROs? The LSP should only > have one RRO for the currently signaled path. I think that > you are confused about how the LSPs are signaled. A single > ERO is sent in the forward direction, and a single RRO is > returned in the reverse direction. I think that Leonid was referring to the same thing as this paragraph from 4.4.3 of the RSVP-TE draft: "Note that each node along the path will now have the complete route from source to destination. The Path RRO will have the route from the source to this node; the Resv RRO will have the route from this node to the destination. This is useful for network management." Thus a transit node has two completely independent RROs; by combining the two RROs, one complete route from ingress to egress is given. From owner-mpls@UU.NET Tue Jul 3 10:16:17 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 KAA28473 for ; Tue, 3 Jul 2001 10:16:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwbx06889; Tue, 3 Jul 2001 14:15:52 GMT Received: by mail-control.mail.uu.net id QQkwbx02104 for mpls-outgoing; Tue, 3 Jul 2001 14:15:19 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 QQkwbx01974 for ; Tue, 3 Jul 2001 14:15:04 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 QQkwbw11322 for ; Tue, 3 Jul 2001 14:13:51 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkwbw05832 for ; Tue, 3 Jul 2001 14:13:51 GMT Message-ID: <3B41D31D.CCA3A486@sandburst.com> Date: Tue, 03 Jul 2001 10:13:49 -0400 From: Eric Gray MIME-Version: 1.0 To: Bert Wijnen , Scott Bradner , Kireeti Kompella , George Swallow , Vijay Gill , Vijay Srinivasan Cc: MPLS Mailing List , Common Control and Measurement Protocols Subject: Working Group tasks and charter cleanup Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Any chance that we will see how the tasks are divided between the MPLS and CCAMP working groups - including cleanup of the group charters, moving Internet Drafts to the right places (and names?), and so on before the next IETF meeting? -- Eric Gray From owner-mpls@UU.NET Tue Jul 3 10:30: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 KAA07538 for ; Tue, 3 Jul 2001 10:30: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 QQkwbx17601; Tue, 3 Jul 2001 14:29:53 GMT Received: by mail-control.mail.uu.net id QQkwbx03878 for mpls-outgoing; Tue, 3 Jul 2001 14:29: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 QQkwbx03867 for ; Tue, 3 Jul 2001 14:29: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 QQkwbx13238 for ; Tue, 3 Jul 2001 14:25:23 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 QQkwbx10487 for ; Tue, 3 Jul 2001 14:25:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA27399 for mpls@uu.net; Tue, 3 Jul 2001 10:25:22 -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 QQkwbx03334 for ; Tue, 3 Jul 2001 14:24:54 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 QQkwbx09615 for ; Tue, 3 Jul 2001 14:23:43 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 QQkwbx16912 for ; Tue, 3 Jul 2001 14:23:43 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 KAA21221; Tue, 3 Jul 2001 10:23:43 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD11865; Tue, 3 Jul 2001 10:23:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20010703102515.026957c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Jul 2001 10:27:20 -0400 To: Jack Brennen , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: LSP in transit LSR MIBs In-Reply-To: <3B41CC81.20BB686D@marconi.com> References: <4.3.2.7.2.20010703085944.01953870@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:45 AM 7/3/2001 -0400, Jack Brennen wrote: >"Thomas D. Nadeau" wrote: > > > > >I'm not sure I explained it right. > > >Consider LSR B which is transit node for an LSP, it has to RRO vectors: > > >one describing path from ingress to B (from PATH message) and other RRO > > >for path from egress to B. > > > > How would these be two different RROs? The LSP should only > > have one RRO for the currently signaled path. I think that > > you are confused about how the LSPs are signaled. A single > > ERO is sent in the forward direction, and a single RRO is > > returned in the reverse direction. > >I think that Leonid was referring to the same thing as this >paragraph from 4.4.3 of the RSVP-TE draft: > > "Note that each node along the path will now have the complete route > from source to destination. The Path RRO will have the route from > the source to this node; the Resv RRO will have the route from this > node to the destination. This is useful for network management." > >Thus a transit node has two completely independent RROs; by combining >the two RROs, one complete route from ingress to egress is given. Sorry, that is what I meant. The Path RRO + the Resv RRO == the RRO from my last discussion. Anyway, the point was that they are viewed as one in the same thing in the MPLS TE MIB; the actual path. The computed and specified paths are also available, but at the head-end only. --Tom From owner-mpls@UU.NET Tue Jul 3 10:52: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 SMTP id KAA21325 for ; Tue, 3 Jul 2001 10:52: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 QQkwbz10840; Tue, 3 Jul 2001 14:51:40 GMT Received: by mail-control.mail.uu.net id QQkwbz06559 for mpls-outgoing; Tue, 3 Jul 2001 14:51: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 QQkwbz06549 for ; Tue, 3 Jul 2001 14:51: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 QQkwbz29011 for ; Tue, 3 Jul 2001 14:48:44 GMT Received: from ix.eng.level3.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQkwbz12717 for ; Tue, 3 Jul 2001 14:48:44 GMT Received: from level3.net (IDENT:luca@localhost [127.0.0.1]) by ix.eng.level3.com (8.11.0/8.11.0) with ESMTP id f63EmbV22567; Tue, 3 Jul 2001 08:48:37 -0600 Message-ID: <3B41DB44.8E2ADB13@level3.net> Date: Tue, 03 Jul 2001 08:48:36 -0600 From: Luca Martini Organization: Level 3 Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: it,fr-CA,fr-FR,en-US MIME-Version: 1.0 To: Torsten Mueller CC: mpls@UU.NET Subject: Re: status of draft-martini-l2circuit-trans-mpls-06.txt ? References: <80256A79.005494A0.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Torsten Mueller wrote: > > 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 no it is not a WG item yet. We are discussing where to propose it . Right now it is likely to pe proposed to the PWE3 WG, but I have not finalized this plan with the other authors. The design in this draft was complete by version 05 , and it's now implemented and interoperating between at least 3 vendors ( Extreme, Cisco, and Laurel ) as announced at Interop. Future revisions of the draft will be backward compatible mainly to correct omissions, and english text issues. Luca From owner-mpls@UU.NET Tue Jul 3 16: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 QAA18696 for ; Tue, 3 Jul 2001 16:24: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 QQkwcv05705; Tue, 3 Jul 2001 20:24:32 GMT Received: by mail-control.mail.uu.net id QQkwcv12740 for mpls-outgoing; Tue, 3 Jul 2001 20:23: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 QQkwcv12731 for ; Tue, 3 Jul 2001 20:23: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 QQkwcv14771 for ; Tue, 3 Jul 2001 20:23:11 GMT Received: from web14907.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14907.mail.yahoo.com [216.136.225.59]) id QQkwcv02077 for ; Tue, 3 Jul 2001 20:23:11 GMT Message-ID: <20010703202310.40915.qmail@web14907.mail.yahoo.com> Received: from [64.217.72.18] by web14907.mail.yahoo.com; Tue, 03 Jul 2001 13:23:10 PDT Date: Tue, 3 Jul 2001 13:23:10 -0700 (PDT) From: cowin fiori Subject: label space To: mpls-ops@mplsrc.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I have an inquiry regarding the pros and cons of per-interface versus per-platform label space. My understanding is that per-platform label space is good for applications where a label may arrive on any port. For example, networks where MPLS packets follow the normal routing path, such as LDP-based networks. In addition, networks that implement MPLS-TE with fast re-route. Whereas per-interface labels are more typically used with explicitly routed LSPs, such as TE tunnels where the paths are calculated off-line. Other examples might include some layer 2 VPN applications and static LSPs. From an operational perspective, is their an advantage of having per-platform versus per-interface label space? Is their a marketing driven reason either way?Any other insights into the pros and cons of per-interface vs per-platform label space would be greatly appreciated. regards. cf __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Jul 3 17:36: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 RAA10993 for ; Tue, 3 Jul 2001 17:36: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 QQkwda16520; Tue, 3 Jul 2001 21:35:50 GMT Received: by mail-control.mail.uu.net id QQkwda09704 for mpls-outgoing; Tue, 3 Jul 2001 21:35:07 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 QQkwda09687 for ; Tue, 3 Jul 2001 21:34:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwda10185 for ; Tue, 3 Jul 2001 21:34:26 GMT Received: from ix.eng.level3.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQkwda00136 for ; Tue, 3 Jul 2001 21:34:26 GMT Received: from level3.net (IDENT:luca@localhost [127.0.0.1]) by ix.eng.level3.com (8.11.0/8.11.0) with ESMTP id f63LXhV23489; Tue, 3 Jul 2001 15:33:43 -0600 Message-ID: <3B423A37.C3D1DF90@level3.net> Date: Tue, 03 Jul 2001 15:33:43 -0600 From: Luca Martini Organization: Level 3 Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: it,fr-CA,fr-FR,en-US MIME-Version: 1.0 To: Sasha Vainshtein CC: "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: Re: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sasha, comments below: Sasha Vainshtein wrote: > > 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 ( or somebody uses an out of band management network for ldp sessions ) > 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? pe-1 and pe-1 ? you mean PE-1 and PE-2 ? if an LDP session is closed all assiciated labels are removed from the local LDP binding database. > 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? > yes. in a similar way as BGP recalculates the IGp recursion once an IGP next hop changes interface. > 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 ) yes, to add to Giles comment , please consider a LER that does not do PHP. In the IP in MPLS tunnel you have 3 possibilities: 1) PHP label 3 ( implicit null ) advertised -> no label on in the IP packet. 2) Label 0 ( explicit null ) advertised -> label 0 is put in the ip packet. 3) no PHP label x advertised -> label x is put in the ip packet. Hence you can say that as far as the MPLS forwarding table is concerned all the 3 above modes have a IGP tunnel label. ( look in the cisco at the "untagged" vs "pop tag" mode in "sh mpls forward") > > 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.) > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > http://www.ietf.org/mailman/listinfo/pwe3 Luca -- Just say no to summer. Ski all year ! Luca Martini Senior Network Architect, Level 3 Communications - Broomfield, CO luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager page-luca@level3.net From owner-mpls@UU.NET Tue Jul 3 19:21: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 TAA13436 for ; Tue, 3 Jul 2001 19:21: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 QQkwcl00965; Tue, 3 Jul 2001 17:50:01 GMT Received: by mail-control.mail.uu.net id QQkwcl26281 for mpls-outgoing; Tue, 3 Jul 2001 17:49:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkwcl26269 for ; Tue, 3 Jul 2001 17:49: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 QQkwcl12177 for ; Tue, 3 Jul 2001 17:46:30 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkwcl09126 for ; Tue, 3 Jul 2001 17:46:30 GMT Received: from goneto.net (host213-120-21-224.host.btclick.com [213.120.21.224]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id C7F2E15F817; Tue, 3 Jul 2001 18:45:29 +0100 (BST) Message-ID: <3B41F7D5.694DF477@goneto.net> Date: Tue, 03 Jul 2001 17:50:29 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sasha Vainshtein Cc: "'luca@level3.net'" , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: Re: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sasha Vainshtein wrote: > > 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? You mean the LDP session between PE-1 and P-1 has been closed I guess? In any case my understanding is that the VC labels advertised by PE-1 to PE-2 are now released by PE-1. The logic behind this is that PE-1 can't reach PE-2 and so the bidirectional VC should be brought down. > 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? Yes. > 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. Well, you could say these are dependent. But it is a fairly loose one-way coupling. In fact it applies regardless of the label distribution used for the tunnel labels. It may just as well be RSVP as LDP, or may not even be MPLS as you mention below. > 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 ) Luca and I specifically discussed this case. His view was that in the MPLS in IP or MPLS in GRE case you do have a "tunnel label", but that tunnel label is implicit null. In any case you could really say that having a route matching the destination IP address of the tunnel is synonymous with having a tunnel label? > I would highly appreciated any information regarding your > reasons behind the new limitation. AFAIK the reasoning behind the limitation was to ensure correct knowledge of VC state, and to ensure that a VC is either bi-directionally up or bi-directionally down. If PE-1 advertises a label to PE-2 when it has no means of reaching PE-2 then PE-2 will believe that the VC is "up" and send traffic over it. HTH. Giles > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > http://www.ietf.org/mailman/listinfo/pwe3 -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Wed Jul 4 22:13: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 WAA15314 for ; Wed, 4 Jul 2001 22:13: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 QQkwhk11699; Thu, 5 Jul 2001 02:13:51 GMT Received: by mail-control.mail.uu.net id QQkwhk15866 for mpls-outgoing; Thu, 5 Jul 2001 02:13:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwhk15842 for ; Thu, 5 Jul 2001 02:12:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkwhk15123 for ; Thu, 5 Jul 2001 02:11:32 GMT Received: from alcatel.com.hk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.alcatel.com.hk [202.84.239.253]) id QQkwhk07647 for ; Thu, 5 Jul 2001 02:11:27 GMT Received: by gatekeeper.alcatel.com.hk via suspension id <119331>; Thu, 5 Jul 2001 10:10:00 +0800 Received: from neth07.net.alcatel.com.hk ([202.65.6.148]) by gatekeeper.alcatel.com.hk with ESMTP id <119231>; Thu, 5 Jul 2001 10:00:29 +0800 Received: from fanchunquan1 ([172.24.16.165] (may be forged)) by neth07.net.alcatel.com.hk (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA22493 for ; Thu, 5 Jul 2001 10:00:56 +0800 (EAT) Message-ID: <003c01c10530$dae64e20$a51018ac@rd.accs.com.cn> Reply-To: "Fan Chunquan" From: "Fan Chunquan" To: Subject: MPLS Archi & Framework doc (where to start?) Date: Thu, 5 Jul 2001 09:59:51 +0100 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 hello, I'm a new comer here, thank you for attention and help in advance. As a new comer, I find I'm lost in the list of RFC and drafts names, and need something to start with. Can anyone indicates the doc for MPLS architecture or framework & background? Thank you. Besides, may I suggest some senior members here make a reading list/guide for new comers? Thank you & best regards, Fan From owner-mpls@UU.NET Wed Jul 4 22: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 SMTP id WAA15515 for ; Wed, 4 Jul 2001 22: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 QQkwhm13413; Thu, 5 Jul 2001 02:30:21 GMT Received: by mail-control.mail.uu.net id QQkwhl17394 for mpls-outgoing; Thu, 5 Jul 2001 02:29: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 QQkwhl17383 for ; Thu, 5 Jul 2001 02:29:30 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 QQkwhl20952 for ; Thu, 5 Jul 2001 02:26:30 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 QQkwhl06647 for ; Thu, 5 Jul 2001 02:26:29 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id WAA30171; Wed, 4 Jul 2001 22:26:21 -0400 (EDT) Date: Wed, 4 Jul 2001 22:26:21 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Fan Chunquan cc: mpls@UU.NET Subject: Re: MPLS Archi & Framework doc (where to start?) In-Reply-To: <003c01c10530$dae64e20$a51018ac@rd.accs.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Fan, The best document to start with would be MPLS Architecture (RFC 3031). Here is the link for it: http://www.ietf.org/rfc/rfc3031.txt -Rajiv On Thu, 5 Jul 2001, Fan Chunquan wrote: > hello, I'm a new comer here, thank you for attention and help in advance. > > As a new comer, I find I'm lost in the list of RFC and drafts names, and > need something to start with. Can anyone indicates the doc for MPLS > architecture or framework & background? Thank you. > > Besides, may I suggest some senior members here make a reading list/guide > for new comers? > > Thank you & best regards, > > Fan > > From owner-mpls@UU.NET Thu Jul 5 00:31: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 AAA17733 for ; Thu, 5 Jul 2001 00:31: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 QQkwhu02428; Thu, 5 Jul 2001 04:32:10 GMT Received: by mail-control.mail.uu.net id QQkwhu06628 for mpls-outgoing; Thu, 5 Jul 2001 04:31:38 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 QQkwhu06620 for ; Thu, 5 Jul 2001 04:31: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 QQkwhu27428 for ; Thu, 5 Jul 2001 04:30:09 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkwhu03339 for ; Thu, 5 Jul 2001 04:30:07 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f65A8tA11251 for ; Thu, 5 Jul 2001 10:08:55 GMT Received: from venkat.wipro.com ([192.168.220.119]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GFZGSB00.BGZ; Thu, 5 Jul 2001 10:06:11 +0530 Date: Thu, 5 Jul 2001 10:17:15 +0530 (IST) From: "Venkat Dabbara" X-Sender: venkat@venkat.wipro.com Reply-To: venkat.dabb@wipro.com To: Fan Chunquan cc: mpls@UU.NET Subject: Re: MPLS Archi & Framework doc (where to start?) In-Reply-To: <003c01c10530$dae64e20$a51018ac@rd.accs.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hai , www.mplsrc.com would be an idle site to begin with ... www.ietf.org rfc 3031 for MPLS architecture.... and onwards ... Good luck ... thanks n regards venkat ------------------------------------ Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: nothing works and they don't know why. -- Unknown Wiseman On Thu, 5 Jul 2001, Fan Chunquan wrote: > hello, I'm a new comer here, thank you for attention and help in advance. > > As a new comer, I find I'm lost in the list of RFC and drafts names, and > need something to start with. Can anyone indicates the doc for MPLS > architecture or framework & background? Thank you. > > Besides, may I suggest some senior members here make a reading list/guide > for new comers? > > Thank you & best regards, > > Fan > > From owner-mpls@UU.NET Thu Jul 5 10:06: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 SMTP id KAA13444 for ; Thu, 5 Jul 2001 10:06: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 QQkwjg20702; Thu, 5 Jul 2001 14:06:58 GMT Received: by mail-control.mail.uu.net id QQkwjg28972 for mpls-outgoing; Thu, 5 Jul 2001 14:06: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 QQkwjg28712 for ; Thu, 5 Jul 2001 14:06: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 QQkwjg18572 for ; Thu, 5 Jul 2001 14:00:30 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 QQkwjg19515 for ; Thu, 5 Jul 2001 14:00:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA14702 for mpls@uu.net; Thu, 5 Jul 2001 10:00: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 QQkwjg19840 for ; Thu, 5 Jul 2001 14:00: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 QQkwjf23468 for ; Thu, 5 Jul 2001 13:56:18 GMT Received: from cvis22.marconicomms.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cvis22.marconicomms.com [195.99.244.54]) id QQkwjf25645 for ; Thu, 5 Jul 2001 13:56:18 GMT Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 5 Jul 2001 14:56:04 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id OAA12455; Thu, 5 Jul 2001 14:56:12 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A80.004C1FB6 ; Thu, 5 Jul 2001 14:51:28 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Torsten Mueller" To: mpls@UU.NET Message-ID: <80256A80.004C1DF1.00@marconicomms.com> Date: Thu, 5 Jul 2001 15:55:42 +0200 Subject: Do MPLS core devices have to implement IP? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Do MPLS core devices have to implement IP? RFC 3031 states: - MPLS forwarding can be done by switches which are capable of doing label lookup and replacement, but are either not capable of analyzing the network layer headers, or are not capable of analyzing the network layer headers at adequate speed. While this means that MPLS nodes do not have to implement IP at the forwarding plane, do these switches have to implement IP at the control plane (and the standard label distribution protocols)? Or is it also possible to distribute the labels by management procedures to be compliant to the MPLS standards? Thanks, Torsten From owner-mpls@UU.NET Thu Jul 5 10:31:41 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 KAA14488 for ; Thu, 5 Jul 2001 10:31: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 QQkwji24124; Thu, 5 Jul 2001 14:30:55 GMT Received: by mail-control.mail.uu.net id QQkwji13270 for mpls-outgoing; Thu, 5 Jul 2001 14:30: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 QQkwjh13175 for ; Thu, 5 Jul 2001 14:29: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 QQkwjh23236 for ; Thu, 5 Jul 2001 14:27:07 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 QQkwjh00858 for ; Thu, 5 Jul 2001 14:27:07 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id FAA28354; Thu, 5 Jul 2001 05:33:06 -0500 Received: from vsharmapc ([10.0.1.238]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id FAA28298; Thu, 5 Jul 2001 05:33:06 -0500 From: "Vipul Sharma" To: "'Torsten Mueller'" , Subject: RE: Do MPLS core devices have to implement IP? Date: Thu, 5 Jul 2001 10:27:08 -0400 Message-ID: <005201c1055e$932429d0$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <80256A80.004C1DF1.00@marconicomms.com> X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In the control plane the MPLS Core device has to implement IP for supporting Label Distribution using standard sig. protocol... RSVP (needs IP) and CR-LDP needs TCP. This is a hughe req. for interoperability and most people demand it of their vendors. Theoretically, one can hand craft the labels in a small network and push them using "management procedures" and NOT depend on label dist. prot. But this will be a hard sell to any of your potential customer. Vip Sharma vsharma@ieee.org vsharma@senecanetworks.com 240-314-0120 ext. 214 -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Torsten Mueller Sent: Thursday, July 05, 2001 9:56 AM To: mpls@UU.NET Subject: Do MPLS core devices have to implement IP? Do MPLS core devices have to implement IP? RFC 3031 states: - MPLS forwarding can be done by switches which are capable of doing label lookup and replacement, but are either not capable of analyzing the network layer headers, or are not capable of analyzing the network layer headers at adequate speed. While this means that MPLS nodes do not have to implement IP at the forwarding plane, do these switches have to implement IP at the control plane (and the standard label distribution protocols)? Or is it also possible to distribute the labels by management procedures to be compliant to the MPLS standards? Thanks, Torsten From owner-mpls@UU.NET Thu Jul 5 10:36:32 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 KAA14679 for ; Thu, 5 Jul 2001 10:36: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 QQkwji16368; Thu, 5 Jul 2001 14:36:45 GMT Received: by mail-control.mail.uu.net id QQkwji14341 for mpls-outgoing; Thu, 5 Jul 2001 14:36:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwji14231 for ; Thu, 5 Jul 2001 14:35: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 QQkwji12821 for ; Thu, 5 Jul 2001 14:32:04 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 QQkwji25743 for ; Thu, 5 Jul 2001 14:32:04 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 f65EWBx20919 for ; Thu, 5 Jul 2001 07:32:11 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22464 for mpls@uu.net; Thu, 5 Jul 2001 10:32:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwfu19357 for ; Wed, 4 Jul 2001 15:38:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkwfu24059 for ; Wed, 4 Jul 2001 15:38:41 GMT Received: from mail.epost.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.39.38.70]) id QQkwfu01006 for ; Wed, 4 Jul 2001 15:38:41 GMT Received: from [62.180.124.100] by mail.epost.de with HTTP; Wed, 4 Jul 2001 17:38:36 +0200 Message-ID: <3B3123980000778F@mail.epost.de> Date: Wed, 4 Jul 2001 17:38:36 +0200 From: =?ISO-8859-1?Q?muellert=40epost=2Ede?= Subject: =?ISO-8859-1?Q?MPLS=20core=20device=20=2D=20needs=20to=20implement=20IP=3F?= To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA14679 Hallo, as RFC 3031 states, MPLS forwarding can be done by devices which do not support to analyze the layer 3 header. Is it necessary for MPLS core devices to support IP at all (control plane, data plane) to be compatible to the MPLS standards? E.g. the labels could be distributed by management procedures. Thanks, Torsten ________________________________________ Der clevere Infobote - Shopping-Tipps bequem abonniert. Jetzt neu bei http://www.epost.de From owner-mpls@UU.NET Thu Jul 5 10:38: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 KAA14749 for ; Thu, 5 Jul 2001 10:38: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 QQkwji19095; Thu, 5 Jul 2001 14:38:03 GMT Received: by mail-control.mail.uu.net id QQkwji14371 for mpls-outgoing; Thu, 5 Jul 2001 14:36:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwji14234 for ; Thu, 5 Jul 2001 14:35: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 QQkwji13120 for ; Thu, 5 Jul 2001 14:32:15 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 QQkwji08768 for ; Thu, 5 Jul 2001 14:32:14 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 f65EWIh08102 for ; Thu, 5 Jul 2001 07:32:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22470 for mpls@uu.net; Thu, 5 Jul 2001 10:32:12 -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 QQkwgr14538 for ; Wed, 4 Jul 2001 21:28:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwgr20562 for ; Wed, 4 Jul 2001 21:24:52 GMT Received: from web14909.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14909.mail.yahoo.com [216.136.225.61]) id QQkwgr02741 for ; Wed, 4 Jul 2001 21:24:52 GMT Message-ID: <20010704212451.49495.qmail@web14909.mail.yahoo.com> Received: from [128.96.52.65] by web14909.mail.yahoo.com; Wed, 04 Jul 2001 14:24:51 PDT Date: Wed, 4 Jul 2001 14:24:51 -0700 (PDT) From: hong liao Subject: ERROR 13 AND ERROR 23 To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In spec rsvp 2205 section Error code and value, 1. Error code 13 will be sent out in PathErr and ResvErr msg when the msg sent out contains Unknown Class number. 2. Error code 23 will be sent out when the message received contains Unknown object Class-Num. So what is differece between this two error message sent out? Also what is the unknown object class number and unknown ctype. What is the illegal object class? Can anyone give me an example? Thanks in an advance __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Jul 5 10:48: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 KAA15164 for ; Thu, 5 Jul 2001 10:48: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 QQkwjj04175; Thu, 5 Jul 2001 14:47:55 GMT Received: by mail-control.mail.uu.net id QQkwjj16660 for mpls-outgoing; Thu, 5 Jul 2001 14:47: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 QQkwjj16649 for ; Thu, 5 Jul 2001 14:47: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 QQkwjj11987 for ; Thu, 5 Jul 2001 14:47:00 GMT Received: from abel.senecanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQkwjj05721 for ; Thu, 5 Jul 2001 14:47:00 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id FAA29832; Thu, 5 Jul 2001 05:52:58 -0500 Received: from vsharmapc ([10.0.1.238]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id FAA29776; Thu, 5 Jul 2001 05:52:57 -0500 From: "Vipul Sharma" To: "'Vipul Sharma'" , "'Torsten Mueller'" , Subject: RE: Do MPLS core devices have to implement IP? Date: Thu, 5 Jul 2001 10:46:59 -0400 Message-ID: <005301c10561$59137ae0$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <005201c1055e$932429d0$ee01000a@vsharmapc> X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Just to add a little bit more... If you look at vendors who are supporting MPLS.. Their docs. say which RFCs and IETF draft they are compliant to. So theoretically you can say your are compliant to drafts/RFC excluding those dealing with Label Distribution Prots (if your cust. are OK with it). All the interop. labs though do conduct interop. tests for RSVP, CR-LDP, LDP, BGP-4, etc.. Vip Sharma vsharma@ieee.org vsharma@senecanetworks.com 240-314-0120 ext. 214 -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vipul Sharma Sent: Thursday, July 05, 2001 10:27 AM To: 'Torsten Mueller'; mpls@UU.NET Subject: RE: Do MPLS core devices have to implement IP? In the control plane the MPLS Core device has to implement IP for supporting Label Distribution using standard sig. protocol... RSVP (needs IP) and CR-LDP needs TCP. This is a hughe req. for interoperability and most people demand it of their vendors. Theoretically, one can hand craft the labels in a small network and push them using "management procedures" and NOT depend on label dist. prot. But this will be a hard sell to any of your potential customer. Vip Sharma vsharma@ieee.org vsharma@senecanetworks.com 240-314-0120 ext. 214 -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Torsten Mueller Sent: Thursday, July 05, 2001 9:56 AM To: mpls@UU.NET Subject: Do MPLS core devices have to implement IP? Do MPLS core devices have to implement IP? RFC 3031 states: - MPLS forwarding can be done by switches which are capable of doing label lookup and replacement, but are either not capable of analyzing the network layer headers, or are not capable of analyzing the network layer headers at adequate speed. While this means that MPLS nodes do not have to implement IP at the forwarding plane, do these switches have to implement IP at the control plane (and the standard label distribution protocols)? Or is it also possible to distribute the labels by management procedures to be compliant to the MPLS standards? Thanks, Torsten From owner-mpls@UU.NET Thu Jul 5 10: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 KAA15378 for ; Thu, 5 Jul 2001 10:52: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 QQkwjj15651; Thu, 5 Jul 2001 14:52:48 GMT Received: by mail-control.mail.uu.net id QQkwjj17230 for mpls-outgoing; Thu, 5 Jul 2001 14:52: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 QQkwjj17204 for ; Thu, 5 Jul 2001 14:52: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 QQkwjj13723 for ; Thu, 5 Jul 2001 14:47:39 GMT Received: from malmo.trab.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkwjj17315 for ; Thu, 5 Jul 2001 14:47:37 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f65Ejot09760; Thu, 5 Jul 2001 16:45:50 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Jul 2001 16:47:33 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D04878399@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'muellert@epost.de'" , mpls@UU.NET Subject: RE: MPLS core device - needs to implement IP? Date: Thu, 5 Jul 2001 16:47:26 +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, Torsten Before the MPLS forwarding path or table is built up, e.g. label distribution protocol makes use of IGP and builds up LSP (MPLS forwarding table). Since IGP uses IP and LDP uses IGP. One can conlude that MPLS core router is needed to impelement IP. In addition, the signalling protocols for MPLS traffic engineering: RSVP-TE and CR-LDP use TCP/IP suites. Hope this would help. /Nhat Thanh -----Original Message----- From: muellert@epost.de [mailto:Torsten.Mueller20@epost.de] Sent: den 4 juli 2001 17:39 To: mpls@UU.NET Subject: MPLS core device - needs to implement IP? Hallo, as RFC 3031 states, MPLS forwarding can be done by devices which do not support to analyze the layer 3 header. Is it necessary for MPLS core devices to support IP at all (control plane, data plane) to be compatible to the MPLS standards? E.g. the labels could be distributed by management procedures. Thanks, Torsten ________________________________________ Der clevere Infobote - Shopping-Tipps bequem abonniert. Jetzt neu bei http://www.epost.de From owner-mpls@UU.NET Thu Jul 5 11:12:32 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 LAA16112 for ; Thu, 5 Jul 2001 11:12:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwjk10804; Thu, 5 Jul 2001 15:09:41 GMT Received: by mail-control.mail.uu.net id QQkwjk22545 for mpls-outgoing; Thu, 5 Jul 2001 15:09: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 QQkwjk22309 for ; Thu, 5 Jul 2001 15:08:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkwjk01875 for ; Thu, 5 Jul 2001 15:07:48 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 QQkwjk15434 for ; Thu, 5 Jul 2001 15:07:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA20612 for mpls@uu.net; Thu, 5 Jul 2001 11:07: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 QQkwjk21549 for ; Thu, 5 Jul 2001 15:06:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwjk25448 for ; Thu, 5 Jul 2001 15:05:37 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkwjk04495 for ; Thu, 5 Jul 2001 15:05:36 GMT Received: from AMALIS.vivacenet.com [192.168.0.104] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id AF8E818C0138; Thu, 05 Jul 2001 07:54:06 -0700 Message-Id: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> X-Sender: Andy.Malis@mail.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Jul 2001 10:54:00 -0400 To: Luca Martini , Giles Heron From: "Andrew G. Malis" Subject: Re: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt Cc: Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson In-Reply-To: <3B423A37.C3D1DF90@level3.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Luca and Giles, I would like disagree a bit with your replies to Sasha, especially with an eye to supporting tunnel redundancy for VC carriage. As we've previously discussed, VC labels are only allocated from the per-platform label space, and also, as we've previously discussed, the VC label distribution signaling via LDP extended discovery is independent of the tunnels used to carry the VCs. As Luca mentioned, it could even be carried by an out-of-band management channel - some method of IP connectivity for the LDP signaling is all that is required. Thus, if a VC label is using a particular tunnel for transport, and the tunnel should go down (for example one of the intermediate LSRs is in a rolling blackout :-) but a backup tunnel is available or is opened using the MPLS redundancy/resilience mechanism of your choice, then the VC should be stay open and just use the new tunnel, with the exact same VC labels. And if QoS isn't important for the application (say, Ethernet over MPLS) then there's no reason why a label stack with the VC label can't be transported to the destination LER via MPLS-in-IP or MPLS-in-GRE. Cheers, Andy -------- At 7/3/2001 03:33 PM -0600, Luca Martini wrote: >Sasha, > >comments below: > > >Sasha Vainshtein wrote: > > > > 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 > >( or somebody uses an out of band management network for ldp sessions ) > > > 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? >pe-1 and pe-1 ? you mean PE-1 and PE-2 ? >if an LDP session is closed all assiciated labels are removed from the >local LDP binding database. > > > > > 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? > > > >yes. in a similar way as BGP recalculates the IGp recursion once an IGP >next hop changes interface. > > > > 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 ) > >yes, to add to Giles comment , please consider a LER that does not do >PHP. >In the IP in MPLS tunnel you have 3 possibilities: >1) PHP label 3 ( implicit null ) advertised -> no label on in the IP >packet. >2) Label 0 ( explicit null ) advertised -> label 0 is put in the ip >packet. >3) no PHP label x advertised -> label x is put in the ip packet. > >Hence you can say that as far as the MPLS forwarding table is concerned >all the 3 above modes have a IGP tunnel label. >( look in the cisco at the "untagged" vs "pop tag" mode in "sh mpls >forward") > > > > > > 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.) > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > http://www.ietf.org/mailman/listinfo/pwe3 > >Luca > >-- >Just say no to summer. Ski all year ! >Luca Martini Senior Network Architect, Level 3 Communications - >Broomfield, CO >luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager >page-luca@level3.net > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >http://www.ietf.org/mailman/listinfo/pwe3 From owner-mpls@UU.NET Thu Jul 5 11:37: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 SMTP id LAA16827 for ; Thu, 5 Jul 2001 11:37: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 QQkwhv13015; Thu, 5 Jul 2001 04:55:37 GMT Received: by mail-control.mail.uu.net id QQkwhv08351 for mpls-outgoing; Thu, 5 Jul 2001 04:55: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 QQkwhv08342 for ; Thu, 5 Jul 2001 04:55:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwhv11380 for ; Thu, 5 Jul 2001 04:54:19 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 QQkwhv02844 for ; Thu, 5 Jul 2001 04:54:19 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id AAA30291; Thu, 5 Jul 2001 00:54:11 -0400 (EDT) Date: Thu, 5 Jul 2001 00:54:11 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Fan Chunquan , Venkat Dabbara cc: mpls@UU.NET Subject: Re: MPLS Archi & Framework doc (where to start?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk www.ail.gmu.edu/resources.htm is also a good source for MPLS related information. -Rajiv On Thu, 5 Jul 2001, Venkat Dabbara wrote: > hai , > > www.mplsrc.com would be an idle site to begin with ... > www.ietf.org > rfc 3031 for MPLS architecture.... > and onwards ... > Good luck ... > > thanks n regards > venkat > > ------------------------------------ > Theory is when you know something, but it doesn't work. > Practice is when something works, but you don't know why. > Programmers combine theory and practice: nothing works and they > don't know why. > -- Unknown Wiseman > > On Thu, 5 Jul 2001, Fan Chunquan wrote: > > > hello, I'm a new comer here, thank you for attention and help in advance. > > > > As a new comer, I find I'm lost in the list of RFC and drafts names, and > > need something to start with. Can anyone indicates the doc for MPLS > > architecture or framework & background? Thank you. > > > > Besides, may I suggest some senior members here make a reading list/guide > > for new comers? > > > > Thank you & best regards, > > > > Fan > > > > > > From owner-mpls@UU.NET Thu Jul 5 11:52: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 LAA17340 for ; Thu, 5 Jul 2001 11:52: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 QQkwjn24019; Thu, 5 Jul 2001 15:52:36 GMT Received: by mail-control.mail.uu.net id QQkwjn14983 for mpls-outgoing; Thu, 5 Jul 2001 15:51:52 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 QQkwjn14954 for ; Thu, 5 Jul 2001 15:51: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 QQkwjn10753 for ; Thu, 5 Jul 2001 15:49:14 GMT Received: from mailgw.ipunplugged.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQkwjn19071 for ; Thu, 5 Jul 2001 15:49:11 GMT Received: from HANSPC (c47.local.ipunplugged.com [192.168.4.246]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA31540; Thu, 5 Jul 2001 17:50:40 +0200 From: =?US-ASCII?Q?Hans_Sjostrand?= To: "Torsten Mueller" , Subject: RE: Do MPLS core devices have to implement IP? Date: Thu, 5 Jul 2001 17:47:29 +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) In-Reply-To: <80256A80.004C1DF1.00@marconicomms.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS forwarding could be done by a device unable to do much else, in fact that was a few of the first implementations was made and it's also I think how a few of the GMPLS implementations today are done. An OXC shouldn't have to terminate any wavelenght, just switch them. You use GSMP to separate the MPLS userplane (forwarding) from the MPLS control plane (signalling). Now you could MPLS (or GMPLS) enable your old (or new) switch without putting in neither IP or MPLS protocools in it. You just add a GSMP agent to the switch. You let the GSMP controller do all the protocool stuff. Check out the GSMP WG if this interests you. Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Torsten > Mueller > Sent: den 5 juli 2001 15:56 > To: mpls@UU.NET > Subject: Do MPLS core devices have to implement IP? > > > > > > Do MPLS core devices have to implement IP? > RFC 3031 states: > - MPLS forwarding can be done by switches which are capable of > doing label lookup and replacement, but are either not capable > of analyzing the network layer headers, or are not capable of > analyzing the network layer headers at adequate speed. > > While this means that MPLS nodes do not have to implement IP at the > forwarding plane, do these switches have to implement IP at the control > plane > (and the standard label distribution protocols)? > Or is it also possible to distribute the labels by management procedures > to be compliant to the MPLS standards? > > > Thanks, > Torsten > From owner-mpls@UU.NET Thu Jul 5 12:15: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 MAA18080 for ; Thu, 5 Jul 2001 12:15: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 QQkwjp03445; Thu, 5 Jul 2001 16:15:22 GMT Received: by mail-control.mail.uu.net id QQkwjo06985 for mpls-outgoing; Thu, 5 Jul 2001 16:14: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 QQkwjo06963 for ; Thu, 5 Jul 2001 16:14: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 QQkwjo05611 for ; Thu, 5 Jul 2001 16:13:30 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 QQkwjo29903 for ; Thu, 5 Jul 2001 16:13:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA25170 for mpls@uu.net; Thu, 5 Jul 2001 12:13: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 QQkwjo06271 for ; Thu, 5 Jul 2001 16:12: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 QQkwjo02677 for ; Thu, 5 Jul 2001 16:12:29 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 QQkwjo29953 for ; Thu, 5 Jul 2001 16:12:28 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 f65HCnK19552 for ; Thu, 5 Jul 2001 19:12:49 +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 f65HCiD19505; Thu, 5 Jul 2001 19:12:44 +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, 5 Jul 2001 19:13:50 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 19:11:03 +0200 Message-ID: From: Sasha Vainshtein To: "'Andrew G. Malis'" , Luca Martini , Giles Heron Cc: "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: RE: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-0 6.txt Date: Thu, 5 Jul 2001 19:11:02 +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 Andrew, Luca and Giles, Thank you for your responses, they clarified the situation for me. I would say that Luka's suggestion that PE-1 and pE-2 may use an out-of-band "backdoor" management channel for their LDP session creates a lot of difference: otherwise, following Andrew's reasoning, one could safely assume that, as long as IP connectivity between PE-1 and PE-2 exists, PE-1 has a valid "tunnel label" (at worst, using MPLS-in-IP) to reach PE-2 and vice versa. Of course, if a backdoor channel between PE-1 and PE-2 exists, this reasoning fails (because you do not want to flood the backdoor channel with traffic). The LDP Hello Adjacency timeout between PE-1 and P-1 over their in-band link would close the LDP session between them even if they can communicate at IP level via a backdoor channel (which presumably is not covered by the LDP auto-discovery mechanisms). On the other hand, I would like to understand how one should treat the same problem in the PWE3 over IP situation (which is a definitely issue for the PWE3 WG). Maybe a valid solution would be a generic requirement for some form of access control which would block PWE3 signaling over backdoor interfaces? For PWE3 over MPLS this would mean blocking LDP on all out-of-band ports. 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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] Sent: Thursday, July 05, 2001 4:54 PM To: Luca Martini; Giles Heron Cc: Sasha Vainshtein; 'pwe3@ietf.org'; 'mpls@uu.net'; Alik Shimelmits; Gonen Zilber; Israel Sasson Subject: Re: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt Luca and Giles, I would like disagree a bit with your replies to Sasha, especially with an eye to supporting tunnel redundancy for VC carriage. As we've previously discussed, VC labels are only allocated from the per-platform label space, and also, as we've previously discussed, the VC label distribution signaling via LDP extended discovery is independent of the tunnels used to carry the VCs. As Luca mentioned, it could even be carried by an out-of-band management channel - some method of IP connectivity for the LDP signaling is all that is required. Thus, if a VC label is using a particular tunnel for transport, and the tunnel should go down (for example one of the intermediate LSRs is in a rolling blackout :-) but a backup tunnel is available or is opened using the MPLS redundancy/resilience mechanism of your choice, then the VC should be stay open and just use the new tunnel, with the exact same VC labels. And if QoS isn't important for the application (say, Ethernet over MPLS) then there's no reason why a label stack with the VC label can't be transported to the destination LER via MPLS-in-IP or MPLS-in-GRE. Cheers, Andy -------- At 7/3/2001 03:33 PM -0600, Luca Martini wrote: >Sasha, > >comments below: > > >Sasha Vainshtein wrote: > > > > 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 > >( or somebody uses an out of band management network for ldp sessions ) > > > 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? >pe-1 and pe-1 ? you mean PE-1 and PE-2 ? >if an LDP session is closed all assiciated labels are removed from the >local LDP binding database. > > > > > 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? > > > >yes. in a similar way as BGP recalculates the IGp recursion once an IGP >next hop changes interface. > > > > 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 ) > >yes, to add to Giles comment , please consider a LER that does not do >PHP. >In the IP in MPLS tunnel you have 3 possibilities: >1) PHP label 3 ( implicit null ) advertised -> no label on in the IP >packet. >2) Label 0 ( explicit null ) advertised -> label 0 is put in the ip >packet. >3) no PHP label x advertised -> label x is put in the ip packet. > >Hence you can say that as far as the MPLS forwarding table is concerned >all the 3 above modes have a IGP tunnel label. >( look in the cisco at the "untagged" vs "pop tag" mode in "sh mpls >forward") > > > > > > 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.) > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > http://www.ietf.org/mailman/listinfo/pwe3 > >Luca > >-- >Just say no to summer. Ski all year ! >Luca Martini Senior Network Architect, Level 3 Communications - >Broomfield, CO >luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager >page-luca@level3.net > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >http://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org http://www.ietf.org/mailman/listinfo/pwe3 From owner-mpls@UU.NET Thu Jul 5 12:33: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 MAA18785 for ; Thu, 5 Jul 2001 12:33: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 QQkwjq03129; Thu, 5 Jul 2001 16:33:24 GMT Received: by mail-control.mail.uu.net id QQkwjq09463 for mpls-outgoing; Thu, 5 Jul 2001 16:32:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwjq09459 for ; Thu, 5 Jul 2001 16:32: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 QQkwjp03859 for ; Thu, 5 Jul 2001 16:29:10 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkwjp25275 for ; Thu, 5 Jul 2001 16:29:10 GMT Received: from goneto.net (unknown [212.161.41.120]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 98A6415F818; Thu, 5 Jul 2001 17:29:09 +0100 (BST) Message-ID: <3B449660.30BA2B4E@goneto.net> Date: Thu, 05 Jul 2001 17:31:28 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew G. Malis" Cc: Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: Re: [PWE3] A doubt regardingdraft-martini-l2circuit-trans-mpls-06.txt References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure that this disagrees with our position at all? In your example there is still a tunnel available. It just isn't the primary tunnel? Giles "Andrew G. Malis" wrote: > > Luca and Giles, > > I would like disagree a bit with your replies to Sasha, especially with an > eye to supporting tunnel redundancy for VC carriage. As we've previously > discussed, VC labels are only allocated from the per-platform label space, > and also, as we've previously discussed, the VC label distribution > signaling via LDP extended discovery is independent of the tunnels used to > carry the VCs. As Luca mentioned, it could even be carried by an > out-of-band management channel - some method of IP connectivity for the LDP > signaling is all that is required. > > Thus, if a VC label is using a particular tunnel for transport, and the > tunnel should go down (for example one of the intermediate LSRs is in a > rolling blackout :-) but a backup tunnel is available or is opened using > the MPLS redundancy/resilience mechanism of your choice, then the VC should > be stay open and just use the new tunnel, with the exact same VC > labels. And if QoS isn't important for the application (say, Ethernet over > MPLS) then there's no reason why a label stack with the VC label can't be > transported to the destination LER via MPLS-in-IP or MPLS-in-GRE. > > Cheers, > Andy > > -------- > > At 7/3/2001 03:33 PM -0600, Luca Martini wrote: > >Sasha, > > > >comments below: > > > > > >Sasha Vainshtein wrote: > > > > > > 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 > > > >( or somebody uses an out of band management network for ldp sessions ) > > > > > 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? > >pe-1 and pe-1 ? you mean PE-1 and PE-2 ? > >if an LDP session is closed all assiciated labels are removed from the > >local LDP binding database. > > > > > > > > > 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? > > > > > > >yes. in a similar way as BGP recalculates the IGp recursion once an IGP > >next hop changes interface. > > > > > > > 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 ) > > > >yes, to add to Giles comment , please consider a LER that does not do > >PHP. > >In the IP in MPLS tunnel you have 3 possibilities: > >1) PHP label 3 ( implicit null ) advertised -> no label on in the IP > >packet. > >2) Label 0 ( explicit null ) advertised -> label 0 is put in the ip > >packet. > >3) no PHP label x advertised -> label x is put in the ip packet. > > > >Hence you can say that as far as the MPLS forwarding table is concerned > >all the 3 above modes have a IGP tunnel label. > >( look in the cisco at the "untagged" vs "pop tag" mode in "sh mpls > >forward") > > > > > > > > > > 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.) > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > http://www.ietf.org/mailman/listinfo/pwe3 > > > >Luca > > > >-- > >Just say no to summer. Ski all year ! > >Luca Martini Senior Network Architect, Level 3 Communications - > >Broomfield, CO > >luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager > >page-luca@level3.net > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >http://www.ietf.org/mailman/listinfo/pwe3 -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Thu Jul 5 12:39:15 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 MAA19023 for ; Thu, 5 Jul 2001 12:39:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwjq12975; Thu, 5 Jul 2001 16:39:28 GMT Received: by mail-control.mail.uu.net id QQkwjq10071 for mpls-outgoing; Thu, 5 Jul 2001 16:38: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 QQkwjq10062 for ; Thu, 5 Jul 2001 16:38: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 QQkwjq26625 for ; Thu, 5 Jul 2001 16:37:19 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 QQkwjq07934 for ; Thu, 5 Jul 2001 16:37:19 GMT Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3GHM01LW>; Thu, 5 Jul 2001 11:37:16 -0500 Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FECE4@celox-stl-ems2.celoxnetworks.com> From: "Pour, Mort" To: mpls@UU.NET Subject: In 1:1 protection switching who informs PML of the failed labels? Date: Thu, 5 Jul 2001 11:37:15 -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 In 1:1 protection switching, who infroms the path merge LSR of the labels that are being switched to the backup path? Is it the path switching LSR that does this after it receives a list of faile labels in FIS? Thanks Mort From owner-mpls@UU.NET Thu Jul 5 12:54: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 MAA19518 for ; Thu, 5 Jul 2001 12:54: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 QQkwjr08204; Thu, 5 Jul 2001 16:55:00 GMT Received: by mail-control.mail.uu.net id QQkwjr12016 for mpls-outgoing; Thu, 5 Jul 2001 16:54: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 QQkwjr11980 for ; Thu, 5 Jul 2001 16:54: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 QQkwjr08218 for ; Thu, 5 Jul 2001 16:51:08 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 QQkwjr05124 for ; Thu, 5 Jul 2001 16:51:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA28229 for mpls@uu.net; Thu, 5 Jul 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 QQkwjr11555 for ; Thu, 5 Jul 2001 16:50: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 QQkwjr06618 for ; Thu, 5 Jul 2001 16:49:18 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkwjr01580 for ; Thu, 5 Jul 2001 16:49:17 GMT Received: from AMALIS.vivacenet.com [192.168.0.104] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A9FD3C040090; Thu, 05 Jul 2001 09:46:53 -0700 Message-Id: <5.1.0.14.2.20010705124411.046c5838@mail.vivacenetworks.com> X-Sender: Andy.Malis@mail.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Jul 2001 12:46:44 -0400 To: giles@goneto.net From: "Andrew G. Malis" Subject: Re: [PWE3] A doubt regardingdraft-martini-l2circuit-trans-mpls-06.txt Cc: "Andrew G. Malis" , Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson In-Reply-To: <3B449660.30BA2B4E@goneto.net> References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Giles, >I'm not sure that this disagrees with our position at all? > >In your example there is still a tunnel available. It just isn't the >primary tunnel? Perhaps, but not necessarily - for example, the primary tunnel could go down, triggering the generation of a backup tunnel, but for some small amount of time, there is no tunnel in existence. Or, the primary could go down, and MPLS in IP or MPLS in GRE is defined as the backup "tunnel". In either case, we don't want to withdraw the VC label. And in the latter, case, we still want to allow new VC tunnels to be created. Cheers, Andy From owner-mpls@UU.NET Thu Jul 5 12:57: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 MAA19645 for ; Thu, 5 Jul 2001 12:57: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 QQkwjr17418; Thu, 5 Jul 2001 16:57:53 GMT Received: by mail-control.mail.uu.net id QQkwjr12274 for mpls-outgoing; Thu, 5 Jul 2001 16:57:19 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 QQkwjr12256 for ; Thu, 5 Jul 2001 16:57:03 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 QQkwjr13345 for ; Thu, 5 Jul 2001 16:56:40 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkwjr07812 for ; Thu, 5 Jul 2001 16:56:39 GMT Received: from goneto.net (unknown [212.161.41.120]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 2A82B15F819; Thu, 5 Jul 2001 17:56:39 +0100 (BST) Message-ID: <3B449CD2.2A2A4CBC@goneto.net> Date: Thu, 05 Jul 2001 17:58:58 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew G. Malis" Cc: Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: Re: [PWE3] A doubtregardingdraft-martini-l2circuit-trans-mpls-06.txt References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> <5.1.0.14.2.20010705124411.046c5838@mail.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Andrew G. Malis" wrote: > > Giles, > > >I'm not sure that this disagrees with our position at all? > > > >In your example there is still a tunnel available. It just isn't the > >primary tunnel? > > Perhaps, but not necessarily - for example, the primary tunnel could go > down, triggering the generation of a backup tunnel, but for some small > amount of time, there is no tunnel in existence. Or, the primary could go > down, and MPLS in IP or MPLS in GRE is defined as the backup "tunnel". In > either case, we don't want to withdraw the VC label. And in the latter, > case, we still want to allow new VC tunnels to be created. MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you shouldn't withdraw the labels. But yes, I take your case about backup tunnels. Really this is the standard issue of layering and holddown timers isn't it? IF the backup tunnel doesn't kick in within x seconds THEN withdraw the advertised labels? Giles -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Thu Jul 5 13:26:32 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 NAA20582 for ; Thu, 5 Jul 2001 13:26:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwjt00314; Thu, 5 Jul 2001 17:26:47 GMT Received: by mail-control.mail.uu.net id QQkwjt04955 for mpls-outgoing; Thu, 5 Jul 2001 17:26: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 QQkwjt04919 for ; Thu, 5 Jul 2001 17:26:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwjt13935 for ; Thu, 5 Jul 2001 17:24:57 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 QQkwjt18685 for ; Thu, 5 Jul 2001 17:24:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA00911 for mpls@uu.net; Thu, 5 Jul 2001 13:24:56 -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 QQkwjt04418 for ; Thu, 5 Jul 2001 17:24: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 QQkwjt05921 for ; Thu, 5 Jul 2001 17:24:07 GMT Received: from viva.vivacenet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkwjt25369 for ; Thu, 5 Jul 2001 17:24:06 GMT Received: from AMALIS.vivacenet.com [192.168.0.104] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A24297800B4; Thu, 05 Jul 2001 10:22:10 -0700 Message-Id: <5.1.0.14.2.20010705131424.04891ea0@mail.vivacenetworks.com> X-Sender: Andy.Malis@mail.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Jul 2001 13:22:02 -0400 To: giles@goneto.net From: "Andrew G. Malis" Subject: Re: [PWE3] A doubtregardingdraft-martini-l2circuit-trans-mpls-06.txt Cc: "Andrew G. Malis" , Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson In-Reply-To: <3B449CD2.2A2A4CBC@goneto.net> References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> <5.1.0.14.2.20010705124411.046c5838@mail.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Giles, >MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you >shouldn't withdraw the labels. > >But yes, I take your case about backup tunnels. Really this is the >standard issue of layering and holddown timers isn't it? IF the backup >tunnel doesn't kick in within x seconds THEN withdraw the advertised >labels? It's not just that. Another problem the current language is, for example, if A is advertising VC labels to B using DU, A needs to somehow figure out if B has a tunnel (of any sort) back to A before it can advertise the label to B. I think that's impossible in the general case. Cheers, Andy From owner-mpls@UU.NET Thu Jul 5 13:33: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 NAA20874 for ; Thu, 5 Jul 2001 13:33:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwju12771; Thu, 5 Jul 2001 17:33:19 GMT Received: by mail-control.mail.uu.net id QQkwju06410 for mpls-outgoing; Thu, 5 Jul 2001 17:32: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 QQkwju06391 for ; Thu, 5 Jul 2001 17:32: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 QQkwju16192 for ; Thu, 5 Jul 2001 17:31:54 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 QQkwju28340 for ; Thu, 5 Jul 2001 17:31:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA01532 for mpls@uu.net; Thu, 5 Jul 2001 13:31: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 QQkwjt05664 for ; Thu, 5 Jul 2001 17:27: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 QQkwjt25064 for ; Thu, 5 Jul 2001 17:27:24 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkwjt01713 for ; Thu, 5 Jul 2001 17:27:23 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 NAA15603; Thu, 5 Jul 2001 13:27:18 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123]) by bucket.cisco.com (Mirapoint) with ESMTP id ACK01675; Thu, 5 Jul 2001 13:27:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010705132931.01965950@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jul 2001 13:31:07 -0400 To: "Andrew G. Malis" , Luca Martini , Giles Heron From: "Thomas D. Nadeau" Subject: Re: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt Cc: Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson In-Reply-To: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com > References: <3B423A37.C3D1DF90@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:54 AM 7/5/2001 -0400, Andrew G. Malis wrote: >Luca and Giles, > >I would like disagree a bit with your replies to Sasha, especially with an >eye to supporting tunnel redundancy for VC carriage. As we've previously >discussed, VC labels are only allocated from the per-platform label space, >and also, as we've previously discussed, the VC label distribution >signaling via LDP extended discovery is independent of the tunnels used to >carry the VCs. As Luca mentioned, it could even be carried by an >out-of-band management channel - some method of IP connectivity for the >LDP signaling is all that is required. > >Thus, if a VC label is using a particular tunnel for transport, and the >tunnel should go down (for example one of the intermediate LSRs is in a >rolling blackout :-) but a backup tunnel is available or is opened using >the MPLS redundancy/resilience mechanism of your choice, then the VC >should be stay open and just use the new tunnel, with the exact same VC >labels. And if QoS isn't important for the application (say, Ethernet >over MPLS) then there's no reason why a label stack with the VC label >can't be transported to the destination LER via MPLS-in-IP or MPLS-in-GRE. Don't forget the case where a tunnel head can re-route itself via a different path option. In this case, the same tunnel head interface can be used with a different underlying LSP. This will preserve the tunnel's characteristics while not interrupting the VC. --Tom >Cheers, >Andy > >-------- > >At 7/3/2001 03:33 PM -0600, Luca Martini wrote: >>Sasha, >> >>comments below: >> >> >>Sasha Vainshtein wrote: >> > >> > 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 >> >>( or somebody uses an out of band management network for ldp sessions ) >> >> > 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? >>pe-1 and pe-1 ? you mean PE-1 and PE-2 ? >>if an LDP session is closed all assiciated labels are removed from the >>local LDP binding database. >> >> >> >> > 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? >> > >> >>yes. in a similar way as BGP recalculates the IGp recursion once an IGP >>next hop changes interface. >> >> >> > 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 ) >> >>yes, to add to Giles comment , please consider a LER that does not do >>PHP. >>In the IP in MPLS tunnel you have 3 possibilities: >>1) PHP label 3 ( implicit null ) advertised -> no label on in the IP >>packet. >>2) Label 0 ( explicit null ) advertised -> label 0 is put in the ip >>packet. >>3) no PHP label x advertised -> label x is put in the ip packet. >> >>Hence you can say that as far as the MPLS forwarding table is concerned >>all the 3 above modes have a IGP tunnel label. >>( look in the cisco at the "untagged" vs "pop tag" mode in "sh mpls >>forward") >> >> >> > >> > 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.) >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > http://www.ietf.org/mailman/listinfo/pwe3 >> >>Luca >> >>-- >>Just say no to summer. Ski all year ! >>Luca Martini Senior Network Architect, Level 3 Communications - >>Broomfield, CO >>luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager >>page-luca@level3.net >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>http://www.ietf.org/mailman/listinfo/pwe3 From owner-mpls@UU.NET Thu Jul 5 19:56: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 TAA00489 for ; Thu, 5 Jul 2001 19:56: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 QQkwkt08523; Thu, 5 Jul 2001 23:56:27 GMT Received: by mail-control.mail.uu.net id QQkwkt14580 for mpls-outgoing; Thu, 5 Jul 2001 23:55: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 QQkwkt14540 for ; Thu, 5 Jul 2001 23:55: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 QQkwkt13016 for ; Thu, 5 Jul 2001 23:53:31 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkwkt02564 for ; Thu, 5 Jul 2001 23:53:31 GMT Received: from goneto.net (host213-120-30-153.host.btclick.com [213.120.30.153]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 24EC115F818; Fri, 6 Jul 2001 00:53:23 +0100 (BST) Message-ID: <3B44FE7E.AB280AD4@goneto.net> Date: Fri, 06 Jul 2001 00:55:42 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew G. Malis" Cc: Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: Re: [PWE3] Adoubtregardingdraft-martini-l2circuit-trans-mpls-06.txt References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> <5.1.0.14.2.20010705124411.046c5838@mail.vivacenetworks.com> <5.1.0.14.2.20010705131424.04891ea0@mail.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Andrew G. Malis" wrote: > > Giles, > > >MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you > >shouldn't withdraw the labels. > > > >But yes, I take your case about backup tunnels. Really this is the > >standard issue of layering and holddown timers isn't it? IF the backup > >tunnel doesn't kick in within x seconds THEN withdraw the advertised > >labels? > > It's not just that. Another problem the current language is, for example, > if A is advertising VC labels to B using DU, A needs to somehow figure out > if B has a tunnel (of any sort) back to A before it can advertise the label > to B. I think that's impossible in the general case. I'm ahead of you here (I think!) Luca and I had just this debate - I was trying to persuade him to take the text out on this very pretext. Somehow he persuaded me that you should still withdraw the label if you don't have a tunnel. My memory is rubbish, but I think the argument is that if A OR B doesn't have a tunnel then it will withdraw its label and the (bidirectional) circuit will go down. Also of course in the (non-general) case of RSVP-TE tunnels A and B should both know the status of tunnels in either direction? Giles -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Fri Jul 6 02:31: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 CAA20446 for ; Fri, 6 Jul 2001 02:31: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 QQkwlu04627; Fri, 6 Jul 2001 06:31:00 GMT Received: by mail-control.mail.uu.net id QQkwlu15851 for mpls-outgoing; Fri, 6 Jul 2001 06:30:28 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 QQkwlu15828 for ; Fri, 6 Jul 2001 06:30: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 QQkwlt23411 for ; Fri, 6 Jul 2001 06:27:19 GMT Received: from alcatel.com.hk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.alcatel.com.hk [202.84.239.253]) id QQkwlt06722 for ; Fri, 6 Jul 2001 06:27:17 GMT Received: by gatekeeper.alcatel.com.hk via suspension id <119120>; Fri, 6 Jul 2001 14:25:57 +0800 Received: by gatekeeper.alcatel.com.hk via suspension id <119446>; Fri, 6 Jul 2001 13:45:29 +0800 Received: from neth07.net.alcatel.com.hk ([202.65.6.148]) by gatekeeper.alcatel.com.hk with ESMTP id <119552>; Thu, 5 Jul 2001 15:09:22 +0800 Received: from fanchunquan1 ([172.24.16.165] (may be forged)) by neth07.net.alcatel.com.hk (8.8.6 (PHNE_14041)/8.8.6) with SMTP id PAA08085; Thu, 5 Jul 2001 15:09:45 +0800 (EAT) Message-ID: <002b01c1055b$fef115e0$a51018ac@rd.accs.com.cn> Reply-To: "Fan Chunquan" From: "Fan Chunquan" To: , Cc: References: Subject: Re: MPLS Archi & Framework doc (where to start?) Date: Thu, 5 Jul 2001 15:08:40 +0100 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 thank you all so much, I have checked all the links you suggested, the resources is really rich. These will help us newcomers a lot. Fan ----- Original Message ----- From: To: ; Cc: Sent: Thursday, July 05, 2001 5:54 AM Subject: Re: MPLS Archi & Framework doc (where to start?) > > www.ail.gmu.edu/resources.htm is also a good source for MPLS related > information. > > -Rajiv > > On Thu, 5 Jul 2001, Venkat Dabbara wrote: > > > hai , > > > > www.mplsrc.com would be an idle site to begin with ... > > www.ietf.org > > rfc 3031 for MPLS architecture.... > > and onwards ... > > Good luck ... > > > > thanks n regards > > venkat > > > > ------------------------------------ > > Theory is when you know something, but it doesn't work. > > Practice is when something works, but you don't know why. > > Programmers combine theory and practice: nothing works and they > > don't know why. > > -- Unknown Wiseman > > > > On Thu, 5 Jul 2001, Fan Chunquan wrote: > > > > > hello, I'm a new comer here, thank you for attention and help in advance. > > > > > > As a new comer, I find I'm lost in the list of RFC and drafts names, and > > > need something to start with. Can anyone indicates the doc for MPLS > > > architecture or framework & background? Thank you. > > > > > > Besides, may I suggest some senior members here make a reading list/guide > > > for new comers? > > > > > > Thank you & best regards, > > > > > > Fan > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Jul 6 06:01: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 GAA25145 for ; Fri, 6 Jul 2001 06:01: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 QQkwmi13544; Fri, 6 Jul 2001 10:01:53 GMT Received: by mail-control.mail.uu.net id QQkwmi09876 for mpls-outgoing; Fri, 6 Jul 2001 10:01: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 QQkwmi09837 for ; Fri, 6 Jul 2001 10:01: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 QQkwmi10446 for ; Fri, 6 Jul 2001 10:00:15 GMT Received: from smtp4.cluster.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQkwmi11178 for ; Fri, 6 Jul 2001 10:00:14 GMT Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f66A06t55663; Fri, 6 Jul 2001 12:00:07 +0200 (CEST) Message-ID: <001901c10603$9a1328e0$0201a8c0@oleane.com> Reply-To: "Michel Gosse" From: "Michel Gosse" To: "Fan Chunquan" Cc: References: <002b01c1055b$fef115e0$a51018ac@rd.accs.com.cn> Subject: Re: MPLS Archi & Framework doc (where to start?) Date: Fri, 6 Jul 2001 12:08:26 +0200 Organization: Upper Side Conferences MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Fan, You can also find informations (Drafts Archives, White Papers, Technical Focus, Interviews...) at http://www.mplsworld.com Michel Gosse michelg@upperside.fr ----- Original Message ----- From: "Fan Chunquan" To: ; Cc: Sent: Thursday, July 05, 2001 4:08 PM Subject: Re: MPLS Archi & Framework doc (where to start?) > thank you all so much, I have checked all the links you suggested, the > resources is really rich. These will help us newcomers a lot. > > Fan > ----- Original Message ----- > From: > To: ; > Cc: > Sent: Thursday, July 05, 2001 5:54 AM > Subject: Re: MPLS Archi & Framework doc (where to start?) > > > > > > www.ail.gmu.edu/resources.htm is also a good source for MPLS related > > information. > > > > -Rajiv > > > > On Thu, 5 Jul 2001, Venkat Dabbara wrote: > > > > > hai , > > > > > > www.mplsrc.com would be an idle site to begin with ... > > > www.ietf.org > > > rfc 3031 for MPLS architecture.... > > > and onwards ... > > > Good luck ... > > > > > > thanks n regards > > > venkat > > > > > > ------------------------------------ > > > Theory is when you know something, but it doesn't work. > > > Practice is when something works, but you don't know why. > > > Programmers combine theory and practice: nothing works and they > > > don't know why. > > > -- Unknown Wiseman > > > > > > On Thu, 5 Jul 2001, Fan Chunquan wrote: > > > > > > > hello, I'm a new comer here, thank you for attention and help in > advance. > > > > > > > > As a new comer, I find I'm lost in the list of RFC and drafts names, > and > > > > need something to start with. Can anyone indicates the doc for MPLS > > > > architecture or framework & background? Thank you. > > > > > > > > Besides, may I suggest some senior members here make a reading > list/guide > > > > for new comers? > > > > > > > > Thank you & best regards, > > > > > > > > Fan > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Jul 6 06:55: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 GAA26418 for ; Fri, 6 Jul 2001 06:55: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 QQkwml27449; Fri, 6 Jul 2001 10:55:04 GMT Received: by mail-control.mail.uu.net id QQkwml29324 for mpls-outgoing; Fri, 6 Jul 2001 10:54: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 QQkwml29316 for ; Fri, 6 Jul 2001 10:54:18 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 QQkwml08877 for ; Fri, 6 Jul 2001 10:52:14 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 QQkwml09916 for ; Fri, 6 Jul 2001 10:52:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA16423 for mpls@uu.net; Fri, 6 Jul 2001 06:52:14 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwml29186 for ; Fri, 6 Jul 2001 10:51: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 QQkwml11415 for ; Fri, 6 Jul 2001 10:51:30 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkwml24670 for ; Fri, 6 Jul 2001 10:51:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25924; Fri, 6 Jul 2001 06:50:44 -0400 (EDT) Message-Id: <200107061050.GAA25924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt Date: Fri, 06 Jul 2001 06:50:43 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel Filename : draft-iwata-mpls-crankback-01.txt Pages : 30 Date : 05-Jul-01 This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-crankback-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705113912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jul 6 10:05: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 KAA03171 for ; Fri, 6 Jul 2001 10:05: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 QQkwmy16767; Fri, 6 Jul 2001 14:04:35 GMT Received: by mail-control.mail.uu.net id QQkwmy21237 for mpls-outgoing; Fri, 6 Jul 2001 14:04: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 QQkwmy21140 for ; Fri, 6 Jul 2001 14:03:57 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 QQkwmy12182 for ; Fri, 6 Jul 2001 14:03:45 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 QQkwmy15492 for ; Fri, 6 Jul 2001 14:03:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA25560 for mpls@uu.net; Fri, 6 Jul 2001 10:03:44 -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 QQkwmy20104 for ; Fri, 6 Jul 2001 14:03: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 QQkwmy05180 for ; Fri, 6 Jul 2001 14:02:23 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkwmy13501 for ; Fri, 6 Jul 2001 14:02:23 GMT Received: from AMALIS.vivacenet.com [192.168.0.104] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A4739589002A; Fri, 06 Jul 2001 07:00:19 -0700 Message-Id: <5.1.0.14.2.20010706095548.046db9b8@mail.vivacenetworks.com> X-Sender: Andy.Malis@mail.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 10:00:13 -0400 To: giles@goneto.net From: "Andrew G. Malis" Subject: Re: [PWE3] Adoubtregardingdraft-martini-l2circuit-trans-mpls-06.txt Cc: "Andrew G. Malis" , Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson In-Reply-To: <3B44FE7E.AB280AD4@goneto.net> References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> <5.1.0.14.2.20010705124411.046c5838@mail.vivacenetworks.com> <5.1.0.14.2.20010705131424.04891ea0@mail.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Giles, > > >MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you > > >shouldn't withdraw the labels. > > > > > >But yes, I take your case about backup tunnels. Really this is the > > >standard issue of layering and holddown timers isn't it? IF the backup > > >tunnel doesn't kick in within x seconds THEN withdraw the advertised > > >labels? > > > > It's not just that. Another problem the current language is, for example, > > if A is advertising VC labels to B using DU, A needs to somehow figure out > > if B has a tunnel (of any sort) back to A before it can advertise the label > > to B. I think that's impossible in the general case. > >I'm ahead of you here (I think!) > >Luca and I had just this debate - I was trying to persuade him to take >the text out on this very pretext. Somehow he persuaded me that you >should still withdraw the label if you don't have a tunnel. My memory >is rubbish, but I think the argument is that if A OR B doesn't have a >tunnel then it will withdraw its label and the (bidirectional) circuit >will go down. Also of course in the (non-general) case of RSVP-TE >tunnels A and B should both know the status of tunnels in either >direction? > >Giles I think it's impossible to make this check in the general case. Here are some reasons: 1. The IP addresses used in RSVP and LDP signaling may be different. Imagine an LSR using a distributed architecture over a number of line cards. The RSVP tunnels are anchored in the line cards of their associated interfaces, and use a unique IP address for each line card in the RSVP sender object. However, the LDP signaling for VC labels is anchored in a central processor card, and uses its own IP address. If you're using OSPF or ISIS within an area, then presumably you can look at the RSVP and LDP IP addresses and confirm in the link state database that the RSVP and LDP addresses are from the same router ID. However, that is not possible across areas, between ASes, or when using non-link-state routing protocols. 2. Even if an incoming TE tunnel's sender address matches that used for the LDP signaling, the receiving LSR has no way of knowing whether or not the sending LSR will choose to use that particular TE tunnel to carry the VCs; it may be restricted to IP traffic engineering. So the sentence really has to go, since I think it's not implementable. Cheers, Andy From owner-mpls@UU.NET Fri Jul 6 10:26: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 KAA04057 for ; Fri, 6 Jul 2001 10:26: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 QQkwmz06145; Fri, 6 Jul 2001 14:26:04 GMT Received: by mail-control.mail.uu.net id QQkwmz07259 for mpls-outgoing; Fri, 6 Jul 2001 14:25: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 QQkwmz07249 for ; Fri, 6 Jul 2001 14:25: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 QQkwmz12367 for ; Fri, 6 Jul 2001 14:23:18 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkwmz20750 for ; Fri, 6 Jul 2001 14:23:18 GMT Received: from tomp.smb.utfors.se ([127.0.0.1]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GG22R900.768; Fri, 6 Jul 2001 16:25:57 +0200 From: Loa Andersson To: "Torsten Mueller" Cc: mpls@UU.NET Message-ID: <40b503e0dd.3e0dd40b50@tomp.smb.utfors.se> Date: Fri, 06 Jul 2001 16:25:57 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Do MPLS core devices have to implement IP? X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Torsten, I think that the key words of this question is "compliant to MPLS standards". There are a set of RFCs around and a cople of pretty mature IDs. I can't see that you are compliant to any of those without implmenting a control plane based on IP and a Label Distribution Protocol. Ypou might argue that you do label based forwarding, especially if you use shim-header, but I can't see that this is of more than academic interest. Academic exercises might be fun though :-) /Loa ----- Original Message ----- From: "Torsten Mueller" Date: Thursday, July 5, 2001 3:55 pm Subject: Do MPLS core devices have to implement IP? > > > > Do MPLS core devices have to implement IP? > RFC 3031 states: > - MPLS forwarding can be done by switches which are capable of > doing label lookup and replacement, but are either not > capable of analyzing the network layer headers, or are not > capable of > analyzing the network layer headers at adequate speed. > > While this means that MPLS nodes do not have to implement IP at the > forwarding plane, do these switches have to implement IP at the > controlplane > (and the standard label distribution protocols)? > Or is it also possible to distribute the labels by management > proceduresto be compliant to the MPLS standards? > > > Thanks, > Torsten > > > From owner-mpls@UU.NET Fri Jul 6 10:57: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 KAA06274 for ; Fri, 6 Jul 2001 10:57: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 QQkwnb06765; Fri, 6 Jul 2001 14:55:08 GMT Received: by mail-control.mail.uu.net id QQkwnb11037 for mpls-outgoing; Fri, 6 Jul 2001 14:54:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwnb10990 for ; Fri, 6 Jul 2001 14:54: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 QQkwnb01176 for ; Fri, 6 Jul 2001 14:53:19 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 QQkwnb12343 for ; Fri, 6 Jul 2001 14:53:19 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA29086 for mpls@uu.net; Fri, 6 Jul 2001 10:53: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 QQkwnb10870 for ; Fri, 6 Jul 2001 14:52:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwnb26989 for ; Fri, 6 Jul 2001 14:50:42 GMT From: Internet-Drafts@ietf.org Received: from NEXUS.replicants.org.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) id QQkwnb07910 for ; Fri, 6 Jul 2001 14:50:39 GMT Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:52 +0100 X-From_: ietf-123-owner@loki.ietf.org Fri Jul 06 14:30:56 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Fri, 06 Jul 2001 14:30:56 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15IVh9-0006pn-00; Fri, 06 Jul 2001 14:30:55 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA24670 for ietf-123-outbound.10@ietf.org; Fri, 6 Jul 2001 08:45:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23698 for ; Fri, 6 Jul 2001 06:50:50 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25924; Fri, 6 Jul 2001 06:50:44 -0400 (EDT) Message-Id: <200107061050.GAA25924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ccamp@ops.ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt Date: Fri, 06 Jul 2001 06:50:43 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:52.0520 (UTC) FILETIME=[9CAF9E80:01C1062B] Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel Filename : draft-iwata-mpls-crankback-01.txt Pages : 30 Date : 05-Jul-01 This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-crankback-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-" --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Sat Jul 7 01:40: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 BAA02237 for ; Sat, 7 Jul 2001 01:40: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 QQkwpi24216; Sat, 7 Jul 2001 05:40:53 GMT Received: by mail-control.mail.uu.net id QQkwpi11636 for mpls-outgoing; Sat, 7 Jul 2001 05:40: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 QQkwpi11628 for ; Sat, 7 Jul 2001 05:40:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwpi17020 for ; Sat, 7 Jul 2001 05:37:38 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 QQkwpi17654 for ; Sat, 7 Jul 2001 05:37:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA10953 for mpls@uu.net; Sat, 7 Jul 2001 01:37: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 QQkwpi11441 for ; Sat, 7 Jul 2001 05:37: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 QQkwpi01272 for ; Sat, 7 Jul 2001 05:34:11 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkwpi26220 for ; Sat, 7 Jul 2001 05:34:11 GMT Received: from juniper.net ([172.16.167.236]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f675Y9H98544; Fri, 6 Jul 2001 22:34:09 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B46A074.B18FE3EC@juniper.net> Date: Fri, 06 Jul 2001 22:39:00 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls-list , mpls-ops CC: Nischal Sheth , Dave Cooper Subject: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Content-Type: multipart/mixed; boundary="------------DB435AB424FDBFFA07C03ECC" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------DB435AB424FDBFFA07C03ECC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is a draft on checking MPLS data plane. It would be a useful tool for network operators. Please let us know if it makes sense. Thanks! - Ping :-) --------------DB435AB424FDBFFA07C03ECC Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA04056; Thu, 5 Jul 2001 08:52:42 -0400 (EDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA16994; Thu, 5 Jul 2001 08:52:42 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19906 for ietf-123-outbound.06@ietf.org; Thu, 5 Jul 2001 08:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA19327 for ; Thu, 5 Jul 2001 06:52:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06433 for ; Thu, 5 Jul 2001 06:52:56 -0400 (EDT) Message-Id: <200107051052.GAA06433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;;:; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Thu, 05 Jul 2001 06:52:56 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Detecting Data Plane Liveliness in RSVP-TE Author(s) : P. Pan, N. Sheth, D. Cooper Filename : draft-pan-lsp-ping-00.txt Pages : 7 Date : 03-Jul-01 This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSP's. The proposed mechanism requires a new optional RSVP object. The processing overhead imposed on LSR control plane is kept to minimum. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pan-lsp-ping-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pan-lsp-ping-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pan-lsp-ping-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010703124551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pan-lsp-ping-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pan-lsp-ping-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124551.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------DB435AB424FDBFFA07C03ECC-- From owner-mpls@UU.NET Sat Jul 7 01:43: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 SMTP id BAA02365 for ; Sat, 7 Jul 2001 01:43: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 QQkwpi16937; Sat, 7 Jul 2001 05:44:12 GMT Received: by mail-control.mail.uu.net id QQkwpi11976 for mpls-outgoing; Sat, 7 Jul 2001 05:43: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 QQkwpi11953 for ; Sat, 7 Jul 2001 05:43:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwpi20750 for ; Sat, 7 Jul 2001 05:42:18 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 QQkwpi27385 for ; Sat, 7 Jul 2001 05:42:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA11116 for mpls@uu.net; Sat, 7 Jul 2001 01:42:18 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwpi11674 for ; Sat, 7 Jul 2001 05:40:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwpi19365 for ; Sat, 7 Jul 2001 05:38:54 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkwpi20195 for ; Sat, 7 Jul 2001 05:38:53 GMT Received: from juniper.net ([172.16.167.236]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f675cnH98581; Fri, 6 Jul 2001 22:38:49 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B46A18C.EADEB625@juniper.net> Date: Fri, 06 Jul 2001 22:43:40 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls-list , ccamp-list CC: Yakov Rekhter , Kireeti Kompella , George Swallow , Dimitrios Pendarakis , Fong Liaw Subject: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-00.txt] Content-Type: multipart/mixed; boundary="------------C3A36C92E1B580CFF12E760F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------C3A36C92E1B580CFF12E760F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Here is a draft on minimizing the negative effects on MPLS traffic caused by LSR's control plane restart. We think this is a valuable feature for the LSR's. Look forward to hear from you. Thanks! - Ping --------------C3A36C92E1B580CFF12E760F Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA11765; Fri, 6 Jul 2001 09:52:02 -0400 (EDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA27430; Fri, 6 Jul 2001 09:52:01 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA24825 for ietf-123-outbound.06@ietf.org; Fri, 6 Jul 2001 09:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23712 for ; Fri, 6 Jul 2001 06:51:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25974 for ; Fri, 6 Jul 2001 06:51:02 -0400 (EDT) Message-Id: <200107061051.GAA25974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;;:; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pan-rsvp-te-restart-00.txt Date: Fri, 06 Jul 2001 06:51:01 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Graceful Restart Mechanism for RSVP-TE Author(s) : P. Pan et al. Filename : draft-pan-rsvp-te-restart-00.txt Pages : Date : 05-Jul-01 This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by LSR's control plane restart, and specifically by the restart of its RSVP-TE component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pan-rsvp-te-restart-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pan-rsvp-te-restart-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pan-rsvp-te-restart-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pan-rsvp-te-restart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pan-rsvp-te-restart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705113937.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------C3A36C92E1B580CFF12E760F-- From owner-mpls@UU.NET Sat Jul 7 07:03: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 HAA17767 for ; Sat, 7 Jul 2001 07:03: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 QQkwpp02760; Sat, 7 Jul 2001 07:29:14 GMT Received: by mail-control.mail.uu.net id QQkwpp01858 for mpls-outgoing; Sat, 7 Jul 2001 07:28: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 QQkwpp01851 for ; Sat, 7 Jul 2001 07:28: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 QQkwpp17222 for ; Sat, 7 Jul 2001 07:27:41 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 QQkwpp21222 for ; Sat, 7 Jul 2001 07:27:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA15223 for mpls@uu.net; Sat, 7 Jul 2001 03:27:40 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkwpp01765 for ; Sat, 7 Jul 2001 07:27:03 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 QQkwpp00584 for ; Sat, 7 Jul 2001 07:26:49 GMT Received: from eth.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.9.145.11]) id QQkwpp09709 for ; Sat, 7 Jul 2001 07:26:48 GMT Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Sat, 7 Jul 2001 12:46:04 +0530 Received: from host.secure4-hosting.net ([209.239.41.31]) by eth.net with Microsoft SMTPSVC(5.5.1877.537.53); Sat, 7 Jul 2001 12:14:06 +0530 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f676nT810532 for murukku@eth.net; Sat, 7 Jul 2001 02:49:29 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <3B46A074.B18FE3EC@juniper.net> Date: Fri, 06 Jul 2001 22:39:00 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls-list , mpls-ops CC: Nischal Sheth , Dave Cooper Subject: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Content-Type: multipart/mixed; boundary="------------DB435AB424FDBFFA07C03ECC" X-Mailing-List: archive/latest/1883 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------DB435AB424FDBFFA07C03ECC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is a draft on checking MPLS data plane. It would be a useful tool for network operators. Please let us know if it makes sense. Thanks! - Ping :-) --------------DB435AB424FDBFFA07C03ECC Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA04056; Thu, 5 Jul 2001 08:52:42 -0400 (EDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA16994; Thu, 5 Jul 2001 08:52:42 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19906 for ietf-123-outbound.06@ietf.org; Thu, 5 Jul 2001 08:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA19327 for ; Thu, 5 Jul 2001 06:52:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06433 for ; Thu, 5 Jul 2001 06:52:56 -0400 (EDT) Message-Id: <200107051052.GAA06433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;;:; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Thu, 05 Jul 2001 06:52:56 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Detecting Data Plane Liveliness in RSVP-TE Author(s) : P. Pan, N. Sheth, D. Cooper Filename : draft-pan-lsp-ping-00.txt Pages : 7 Date : 03-Jul-01 This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSP's. The proposed mechanism requires a new optional RSVP object. The processing overhead imposed on LSR control plane is kept to minimum. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pan-lsp-ping-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pan-lsp-ping-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pan-lsp-ping-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010703124551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pan-lsp-ping-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pan-lsp-ping-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124551.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------DB435AB424FDBFFA07C03ECC-- ------- 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 Sat Jul 7 14:01:34 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 OAA21179 for ; Sat, 7 Jul 2001 14:01: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 QQkwrg22491; Sat, 7 Jul 2001 18:01:32 GMT Received: by mail-control.mail.uu.net id QQkwrg25063 for mpls-outgoing; Sat, 7 Jul 2001 18:00: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 QQkwrg24876 for ; Sat, 7 Jul 2001 18:00: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 QQkwrg29058 for ; Sat, 7 Jul 2001 18:00:38 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkwrg04375 for ; Sat, 7 Jul 2001 18:00:37 GMT Received: from goneto.net (host213-120-36-10.host.btclick.com [213.120.36.10]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 01E5D15F819; Sat, 7 Jul 2001 19:00:19 +0100 (BST) Message-ID: <3B474EBD.82F1BE8F@goneto.net> Date: Sat, 07 Jul 2001 19:02:37 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew G. Malis" Cc: Luca Martini , Sasha Vainshtein , "'pwe3@ietf.org'" , "'mpls@uu.net'" , Alik Shimelmits , Gonen Zilber , Israel Sasson Subject: Re: [PWE3]Adoubtregardingdraft-martini-l2circuit-trans-mpls-06.txt References: <5.1.0.14.2.20010705103850.047190f0@mail.vivacenetworks.com> <5.1.0.14.2.20010705124411.046c5838@mail.vivacenetworks.com> <5.1.0.14.2.20010705131424.04891ea0@mail.vivacenetworks.com> <5.1.0.14.2.20010706095548.046db9b8@mail.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Andy, I'm not sure you're getting my point? I agree 100% that there is no way to be sure that your peer has a valid tunnel to you. The point is that if you don't have a valid tunnel to your peer then you should not advertise the VC label. The intention is that this will keep the bidirectional VC "down" unless both ends have valid tunnels to each other. It may be worth rewording the text to make this clearer? Giles "Andrew G. Malis" wrote: > > Giles, > > > > >MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you > > > >shouldn't withdraw the labels. > > > > > > > >But yes, I take your case about backup tunnels. Really this is the > > > >standard issue of layering and holddown timers isn't it? IF the backup > > > >tunnel doesn't kick in within x seconds THEN withdraw the advertised > > > >labels? > > > > > > It's not just that. Another problem the current language is, for example, > > > if A is advertising VC labels to B using DU, A needs to somehow figure out > > > if B has a tunnel (of any sort) back to A before it can advertise the label > > > to B. I think that's impossible in the general case. > > > >I'm ahead of you here (I think!) > > > >Luca and I had just this debate - I was trying to persuade him to take > >the text out on this very pretext. Somehow he persuaded me that you > >should still withdraw the label if you don't have a tunnel. My memory > >is rubbish, but I think the argument is that if A OR B doesn't have a > >tunnel then it will withdraw its label and the (bidirectional) circuit > >will go down. Also of course in the (non-general) case of RSVP-TE > >tunnels A and B should both know the status of tunnels in either > >direction? > > > >Giles > > I think it's impossible to make this check in the general case. Here are > some reasons: > > 1. The IP addresses used in RSVP and LDP signaling may be > different. Imagine an LSR using a distributed architecture over a number > of line cards. The RSVP tunnels are anchored in the line cards of their > associated interfaces, and use a unique IP address for each line card in > the RSVP sender object. However, the LDP signaling for VC labels is > anchored in a central processor card, and uses its own IP address. > > If you're using OSPF or ISIS within an area, then presumably you can look > at the RSVP and LDP IP addresses and confirm in the link state database > that the RSVP and LDP addresses are from the same router ID. However, that > is not possible across areas, between ASes, or when using non-link-state > routing protocols. > > 2. Even if an incoming TE tunnel's sender address matches that used for the > LDP signaling, the receiving LSR has no way of knowing whether or not the > sending LSR will choose to use that particular TE tunnel to carry the VCs; > it may be restricted to IP traffic engineering. > > So the sentence really has to go, since I think it's not implementable. > > Cheers, > Andy -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Mon Jul 9 08:04: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 IAA10446 for ; Mon, 9 Jul 2001 08:04: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 QQkwxs05472; Mon, 9 Jul 2001 12:03:58 GMT Received: by mail-control.mail.uu.net id QQkwxs23610 for mpls-outgoing; Mon, 9 Jul 2001 12:03: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 QQkwxs23600 for ; Mon, 9 Jul 2001 12:03: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 QQkwxs08695 for ; Mon, 9 Jul 2001 12:01:30 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 QQkwxs02731 for ; Mon, 9 Jul 2001 12:01:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA29672 for mpls@uu.net; Mon, 9 Jul 2001 08:01: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 QQkwxs16840 for ; Mon, 9 Jul 2001 12:00: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 QQkwxr21132 for ; Mon, 9 Jul 2001 11:58:32 GMT Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkwxr26182 for ; Mon, 9 Jul 2001 11:58:31 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f69BuiH06742; Mon, 9 Jul 2001 04:56:46 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp21.cisco.com [10.50.0.20]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AIW03390 (AUTH rraszuk); Mon, 9 Jul 2001 04:58:23 -0700 (PDT) Message-ID: <3B499BE8.13BADDC6@cisco.com> Date: Mon, 09 Jul 2001 04:56:24 -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: Bryan W CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: When to create label bindings References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bryan, > It seems that LSRs do not automatically create labels Extremely wrong !!! MPSL is control driven not data driven. > for all flows since it > is not economical to do so for very short flows. MPLS in your definition is extremely not economical as it creates all possible bindings even before any packet arrives. In addition some of those bindings will be maintained by all LSRs as long as there is route to their dst in IGP table and may never even be used. I would suggest to read MPLS related RFCs or available books as a starter. R. > Bryan W wrote: > > I am trying to learn MPLS and have the following question: > > It seems that LSRs do not automatically create labels for all flows since it > is not economical to do so for very short flows. However, what triggers the > label creation? is it a simple rule that specifies, for example, to create > a label when 5 packets arrive from the same FEC? if so, would there be a > time limit to the frequency of the packets such that if no packets arrive > after a certain time the flow and the label will expire? if a label is > created, in the above example, after 5 packets arrive, would that imply that > the label is a waste if the flow/FEC only has 5 packets? > > Thanks, > > BW > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.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 Mon Jul 9 08:27: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 IAA11184 for ; Mon, 9 Jul 2001 08:27: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 QQkwxt28815; Mon, 9 Jul 2001 12:27:56 GMT Received: by mail-control.mail.uu.net id QQkwxt04713 for mpls-outgoing; Mon, 9 Jul 2001 12:27: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 QQkwxt04708 for ; Mon, 9 Jul 2001 12:27:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwxt05446 for ; Mon, 9 Jul 2001 12:21:22 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f13.law7.hotmail.com [216.33.237.13]) id QQkwxt03555 for ; Mon, 9 Jul 2001 12:21:21 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 05:21:21 -0700 Received: from 24.176.213.132 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 09 Jul 2001 12:21:20 GMT X-Originating-IP: [24.176.213.132] From: "Bryan W" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Control driven vs. data driven Date: Mon, 09 Jul 2001 12:21:20 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2001 12:21:21.0082 (UTC) FILETIME=[A97AF9A0:01C10871] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can someone give me definitions and examples of control driven vs data driven label bindings? Thanks, Bryan _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Jul 9 09:08: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 SMTP id JAA12754 for ; Mon, 9 Jul 2001 09:08:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwxw05702; Mon, 9 Jul 2001 13:08:50 GMT Received: by mail-control.mail.uu.net id QQkwxw27576 for mpls-outgoing; Mon, 9 Jul 2001 13:08: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 QQkwxw27569 for ; Mon, 9 Jul 2001 13:08:12 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 QQkwxw13962 for ; Mon, 9 Jul 2001 13:07:53 GMT From: ytr@123india.com Received: from c009.snv.cp.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: c009-h010.c009.snv.cp.net [209.228.34.123]) id QQkwxw03632 for ; Mon, 9 Jul 2001 13:07:53 GMT Received: (cpmta 13754 invoked from network); 9 Jul 2001 06:07:48 -0700 Date: 9 Jul 2001 06:07:48 -0700 Message-ID: <20010709130748.13751.cpmta@c009.snv.cp.net> X-Sent: 9 Jul 2001 13:07:48 GMT Received: from [192.52.59.68] by mail.123india.com with HTTP; 09 Jul 2001 06:07:47 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: bryan555@hotmail.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET X-Mailer: Web Mail 3.9.3.3 Subject: Re: Control driven vs. data driven X-Sent-From: ytr@123india.com Sender: owner-mpls@UU.NET Precedence: bulk Hi, The labels are distributed when LSR recieves first data packet then it is called data driven label binding. Where as labels are distrubuted independent of data flows then it is called control driven approach. Usally in control driven approach labels are distributed prior to data traffic flows. If I am wrong pls correct me. Regards YTR On Mon, 09 July 2001, "Bryan W" wrote: > > Hi, > > Can someone give me definitions and examples of control driven vs data > driven label bindings? Thanks, > > Bryan > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com ______________________________________________________ 123India.com - India's Premier Portal Get your Free Email Account at http://www.123india.com From owner-mpls@UU.NET Mon Jul 9 10:13: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 SMTP id KAA15395 for ; Mon, 9 Jul 2001 10:13: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 QQkwya15231; Mon, 9 Jul 2001 14:12:32 GMT Received: by mail-control.mail.uu.net id QQkwya15885 for mpls-outgoing; Mon, 9 Jul 2001 14:11: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 QQkwya15849 for ; Mon, 9 Jul 2001 14:11:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkwya17905 for ; Mon, 9 Jul 2001 14:10:12 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 QQkwya13850 for ; Mon, 9 Jul 2001 14:10:07 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 KAA03368 for ; Mon, 9 Jul 2001 10:10: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 KAA11613 for ; Mon, 9 Jul 2001 10:10:06 -0400 (EDT) Message-ID: <3B49BB61.651951BB@marconi.com> Date: Mon, 09 Jul 2001 10:10:41 -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: TE-MIB and RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit francis.arts@alcatel.be wrote: > > As Suresh indicates it is possible to share resources between the > working path and the path used for protection. However, when doing > this a price is paid in terms of a reduced protection: if a link / > node that is used by both the working path and the protecting path > fails, both paths are gone. The use of SE style does not change this fact. SE style will allow common links to share resources. It has no impact over which links may or may not be common. That is decided by the ingress node when it generates the ERO objects. -- David From owner-mpls@UU.NET Mon Jul 9 10:14: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 SMTP id KAA15431 for ; Mon, 9 Jul 2001 10:14: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 QQkwya19384; Mon, 9 Jul 2001 14:14:30 GMT Received: by mail-control.mail.uu.net id QQkwya18705 for mpls-outgoing; Mon, 9 Jul 2001 14:13: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 QQkwya18012 for ; Mon, 9 Jul 2001 14:13:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwya23023 for ; Mon, 9 Jul 2001 14:12:57 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 QQkwya27615 for ; Mon, 9 Jul 2001 14:12:56 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25953 for ; Mon, 9 Jul 2001 10:12:55 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02321 for mpls@uu.net; Mon, 9 Jul 2001 10:12:53 -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 QQkwxm16681 for ; Mon, 9 Jul 2001 10:43:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwxm01250 for ; Mon, 9 Jul 2001 10:40:30 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f26.law7.hotmail.com [216.33.237.26]) id QQkwxm22210 for ; Mon, 9 Jul 2001 10:40:30 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 03:40:29 -0700 Received: from 24.176.213.132 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 09 Jul 2001 10:40:29 GMT X-Originating-IP: [24.176.213.132] From: "Bryan W" To: mpls@UU.NET Subject: When to create label bindings Date: Mon, 09 Jul 2001 10:40:29 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2001 10:40:29.0764 (UTC) FILETIME=[929D2040:01C10863] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am trying to learn MPLS, and I have a question regarding the following: It seems that the LSR does not automatically create label bindings since the setup cost of creating labels for flows of very short length outweighs the benefit of having labels. However, how does an LSR know when to create the bindings? if it uses a simple rule that creates a label when 5 packets of the same FEC passes through, would that imply that flows of packet sizes 5 to 10 will cause the label to be too expensive since, respectively, only 0 to 5 packets will enjoy the benefit of the label? Is there a time limit to the flow such that after 3 minutes without a packet from a labeled flow, the label will be terminated? Thanks, Bryan _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Jul 9 10:19:00 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 KAA15664 for ; Mon, 9 Jul 2001 10:19:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwyb27925; Mon, 9 Jul 2001 14:16:12 GMT Received: by mail-control.mail.uu.net id QQkwyb21316 for mpls-outgoing; Mon, 9 Jul 2001 14:15:39 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 QQkwyb21075 for ; Mon, 9 Jul 2001 14:15:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkwya16107 for ; Mon, 9 Jul 2001 14:13:08 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkwya20973 for ; Mon, 9 Jul 2001 14:13:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA06381 for ; Mon, 9 Jul 2001 10:13:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02325 for mpls@uu.net; Mon, 9 Jul 2001 10:13:05 -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 QQkwxs01859 for ; Mon, 9 Jul 2001 12:05:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwxs25242 for ; Mon, 9 Jul 2001 12:04:48 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f238.law7.hotmail.com [216.33.237.238]) id QQkwxs06954 for ; Mon, 9 Jul 2001 12:04:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 05:04:47 -0700 Received: from 24.176.213.132 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 09 Jul 2001 12:04:47 GMT X-Originating-IP: [24.176.213.132] From: "Bryan W" To: raszuk@cisco.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: When to create label bindings Date: Mon, 09 Jul 2001 12:04:47 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2001 12:04:47.0449 (UTC) FILETIME=[593A9C90:01C1086F] Sender: owner-mpls@UU.NET Precedence: bulk Can someone give me definitions and examples of control-driven and data-driven? thx >From: Robert Raszuk >Reply-To: raszuk@cisco.com >To: Bryan W >CC: mpls-ops@mplsrc.com, mpls@UU.NET >Subject: Re: When to create label bindings >Date: Mon, 09 Jul 2001 04:56:24 -0700 > >Bryan, > > > It seems that LSRs do not automatically create labels > >Extremely wrong !!! MPSL is control driven not data driven. > > > for all flows since it > > is not economical to do so for very short flows. > >MPLS in your definition is extremely not economical as it creates all >possible bindings even before any packet arrives. In addition some of >those bindings will be maintained by all LSRs as long as there is route >to their dst in IGP table and may never even be used. > >I would suggest to read MPLS related RFCs or available books as a >starter. > >R. > > > > Bryan W wrote: > > > > I am trying to learn MPLS and have the following question: > > > > It seems that LSRs do not automatically create labels for all flows >since it > > is not economical to do so for very short flows. However, what triggers >the > > label creation? is it a simple rule that specifies, for example, to >create > > a label when 5 packets arrive from the same FEC? if so, would there be >a > > time limit to the frequency of the packets such that if no packets >arrive > > after a certain time the flow and the label will expire? if a label is > > created, in the above example, after 5 packets arrive, would that imply >that > > the label is a waste if the flow/FEC only has 5 packets? > > > > Thanks, > > > > BW > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.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 Mon Jul 9 10:24: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 KAA15838 for ; Mon, 9 Jul 2001 10:24: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 QQkwyb12758; Mon, 9 Jul 2001 14:22:27 GMT Received: by mail-control.mail.uu.net id QQkwyb24661 for mpls-outgoing; Mon, 9 Jul 2001 14:21: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 QQkwyb24643 for ; Mon, 9 Jul 2001 14:21: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 QQkwyb26572 for ; Mon, 9 Jul 2001 14:21:19 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 QQkwyb10097 for ; Mon, 9 Jul 2001 14:21:19 GMT Message-ID: From: Jeff Parker To: "'Bryan W'" , raszuk@cisco.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: When to create label bindings Date: Mon, 9 Jul 2001 10:21:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Can someone give me definitions and examples of control-driven and > data-driven? thx Ipsilon's strategy was data-driven - if they come, we will build it. The phone network is control-driven - before you can come, we will use independant paths to setup the resources for your data. - jeff parker - axiowave networks From owner-mpls@UU.NET Mon Jul 9 10:26: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 KAA15931 for ; Mon, 9 Jul 2001 10:26: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 QQkwyb16460; Mon, 9 Jul 2001 14:23:59 GMT Received: by mail-control.mail.uu.net id QQkwyb25057 for mpls-outgoing; Mon, 9 Jul 2001 14:23: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 QQkwyb24765 for ; Mon, 9 Jul 2001 14:22:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkwyb06225 for ; Mon, 9 Jul 2001 14:20:56 GMT From: chris@bravara.com Received: from mailhost.bravara.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.bravidacorp.com [38.168.15.229]) id QQkwyb10660 for ; Mon, 9 Jul 2001 14:20:55 GMT Received: from home2ohncaesy5 (adsl-65-67-60-116.dsl.austtx.swbell.net [65.67.60.116]) by mailhost.bravara.com (Mirapoint) with ESMTP id AAJ67343 (AUTH chris); Mon, 9 Jul 2001 07:20:45 -0700 (PDT) Message-ID: <090001c10882$14fa8e60$793c4341@home2ohncaesy5> Reply-To: To: "Bryan W" , , References: Subject: Re: Control driven vs. data driven Date: Mon, 9 Jul 2001 09:18:48 -0500 Organization: bravara MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bryan - Control-driven: In the control-driven model, label bindings are created when control information is received by an MPLS-enabled node. Labels are assigned in response to the standard processing of routing protocol data, control data (i.e. RSVP), or in response to static configuration via the network admin/off-line tool. Labels are assigned and distributed before the arrival of user data flows, thus user data can be label swapped immediately upon arrival. Data-driven: The data-driven model is currently not supported by MPLS. In the data-driven model, label bindings are created when user data packets are received by an MPLS-enabled node. A MPLS-enabled node can either create a label binding as soon as it sees the first packet in a user data flow or wait until it has seen a specified number of packets in the particular flow. I hope this helps. ----- Original Message ----- From: "Bryan W" To: ; Sent: Monday, July 09, 2001 12:21 PM Subject: Control driven vs. data driven > Hi, > > Can someone give me definitions and examples of control driven vs data > driven label bindings? Thanks, > > Bryan > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > From owner-mpls@UU.NET Mon Jul 9 10:52: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 SMTP id KAA16919 for ; Mon, 9 Jul 2001 10:52: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 QQkwyd09283; Mon, 9 Jul 2001 14:50:28 GMT Received: by mail-control.mail.uu.net id QQkwyd27815 for mpls-outgoing; Mon, 9 Jul 2001 14:49: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 QQkwyd27770 for ; Mon, 9 Jul 2001 14:49:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwyd09592 for ; Mon, 9 Jul 2001 14:47:56 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkwyd26283 for ; Mon, 9 Jul 2001 14:47:56 GMT Message-ID: <3B49C41A.9440A578@sandburst.com> Date: Mon, 09 Jul 2001 10:47:54 -0400 From: Eric Gray MIME-Version: 1.0 To: raszuk@cisco.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: When to create label bindings References: <3B499BE8.13BADDC6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, I did not see the original posting on this. Another place to look for some ideas on this issue is at http://www.mindspring.com/~ewgray/faq.htm#FLOW. Naturally, I think the idea of reading a book on MPLS is a good idea as well. -- Eric Gray You wrote: > Bryan, > > > It seems that LSRs do not automatically create labels > > Extremely wrong !!! MPSL is control driven not data driven. > > > for all flows since it > > is not economical to do so for very short flows. > > MPLS in your definition is extremely not economical as it creates all > possible bindings even before any packet arrives. In addition some of > those bindings will be maintained by all LSRs as long as there is route > to their dst in IGP table and may never even be used. > > I would suggest to read MPLS related RFCs or available books as a > starter. > > R. > > > Bryan W wrote: > > > > I am trying to learn MPLS and have the following question: > > > > It seems that LSRs do not automatically create labels for all flows since it > > is not economical to do so for very short flows. However, what triggers the > > label creation? is it a simple rule that specifies, for example, to create > > a label when 5 packets arrive from the same FEC? if so, would there be a > > time limit to the frequency of the packets such that if no packets arrive > > after a certain time the flow and the label will expire? if a label is > > created, in the above example, after 5 packets arrive, would that imply that > > the label is a waste if the flow/FEC only has 5 packets? > > > > Thanks, > > > > BW > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.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 Mon Jul 9 11:13: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 SMTP id LAA17713 for ; Mon, 9 Jul 2001 11:13:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwye22044; Mon, 9 Jul 2001 15:12:58 GMT Received: by mail-control.mail.uu.net id QQkwye18828 for mpls-outgoing; Mon, 9 Jul 2001 15:12: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 QQkwye18808 for ; Mon, 9 Jul 2001 15:11: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 QQkwye28647 for ; Mon, 9 Jul 2001 15:11:20 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 QQkwye18828 for ; Mon, 9 Jul 2001 15:11:19 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA15049 for mpls@uu.net; Mon, 9 Jul 2001 11:11: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 QQkwye18638 for ; Mon, 9 Jul 2001 15:10: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 QQkwye26159 for ; Mon, 9 Jul 2001 15:09:05 GMT Received: from mail.integralaccess.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQkwye13241 for ; Mon, 9 Jul 2001 15:09:05 GMT Received: from LKHIRALLAH [192.168.100.171] by mail.integralaccess.com (SMTPD32-6.04) id A9081F1103B6; Mon, 09 Jul 2001 11:08:56 -0400 From: "Larry Khirallah" To: "Bryan W" , , Subject: RE: Control driven vs. data driven Date: Mon, 9 Jul 2001 11:08:52 -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.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit data driven label bindings are created when some threshold of packet flow is reached (i.e. when a certain pre-defined amount of packets of the same flow are received) a better name might have been data LOAD driven control driven is irrespective of load hope this helps... larry k > -----Original Message----- > From: Bryan W [mailto:bryan555@hotmail.com] > Sent: Monday, July 09, 2001 12:21 PM > To: mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Control driven vs. data driven > > > Hi, > > Can someone give me definitions and examples of control driven vs data > driven label bindings? Thanks, > > Bryan > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.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 Mon Jul 9 11:18: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 LAA17884 for ; Mon, 9 Jul 2001 11:18: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 QQkwyf04614; Mon, 9 Jul 2001 15:18:22 GMT Received: by mail-control.mail.uu.net id QQkwyf19704 for mpls-outgoing; Mon, 9 Jul 2001 15:17: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 QQkwyf19681 for ; Mon, 9 Jul 2001 15:17:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwyf08655 for ; Mon, 9 Jul 2001 15:15:36 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 QQkwyf28336 for ; Mon, 9 Jul 2001 15:15:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA15483 for mpls@uu.net; Mon, 9 Jul 2001 11:15: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 QQkwye19228 for ; Mon, 9 Jul 2001 15:14:59 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 QQkwye29460 for ; Mon, 9 Jul 2001 15:14:03 GMT Received: from mail.integralaccess.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQkwye01578 for ; Mon, 9 Jul 2001 15:14:03 GMT Received: from LKHIRALLAH [192.168.100.171] by mail.integralaccess.com (SMTPD32-6.04) id AA342E1B0412; Mon, 09 Jul 2001 11:13:56 -0400 From: "Larry Khirallah" To: "Bryan W" , Cc: Subject: RE: When to create label bindings Date: Mon, 9 Jul 2001 11:13:52 -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.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bryan W [mailto:bryan555@hotmail.com] > Sent: Monday, July 09, 2001 11:05 AM > To: mpls-ops@mplsrc.com > Cc: mpls@UU.NET > Subject: When to create label bindings > > > I am trying to learn MPLS and have the following question: > > It seems that LSRs do not automatically create labels for all > flows since it > is not economical to do so for very short flows. However, what > triggers the > label creation? is it a simple rule that specifies, for example, > to create > a label when 5 packets arrive from the same FEC? this would be an example of 'data-driven' label bindings, and the 'simple rule' is configurable.. > if so, would there be a > time limit to the frequency of the packets such that if no packets arrive > after a certain time the flow and the label will expire? if a label is > created, in the above example, after 5 packets arrive, would that > imply that > the label is a waste if the flow/FEC only has 5 packets? > i guess it depends upon your definition of 'waste'... in most reallife situations, you would select to configure a 'threshold' number which defines a high degree of likelihood that a 'flow' would continue once the 'threshold' is reached... you could 'age' the binding if you like, and configure it to 'unbind' after a certain expiration period... once again, alot is left to the designer:) larry k From owner-mpls@UU.NET Mon Jul 9 15:41:47 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 PAA26865 for ; Mon, 9 Jul 2001 15:41: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 QQkwyw22472; Mon, 9 Jul 2001 19:40:51 GMT Received: by mail-control.mail.uu.net id QQkwyw05036 for mpls-outgoing; Mon, 9 Jul 2001 19:40: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 QQkwyw05031 for ; Mon, 9 Jul 2001 19:40:06 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 QQkwyw13811 for ; Mon, 9 Jul 2001 19:39:42 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 QQkwyw20498 for ; Mon, 9 Jul 2001 19:39:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA05129 for mpls@uu.net; Mon, 9 Jul 2001 15:39:41 -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 QQkwyw04973 for ; Mon, 9 Jul 2001 19:39: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 QQkwyw27401 for ; Mon, 9 Jul 2001 19:37:17 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 QQkwyw16979 for ; Mon, 9 Jul 2001 19:37:17 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 PAA06444; Mon, 9 Jul 2001 15:37:08 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA11274; Mon, 9 Jul 2001 15:37:08 -0400 (EDT) Message-Id: <200107091937.PAA11274@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Ping Pan cc: mpls-list , mpls-ops , Nischal Sheth , Dave Cooper , swallow@cisco.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of "Fri, 06 Jul 2001 22:39:00 PDT." <3B46A074.B18FE3EC@juniper.net> Date: Mon, 09 Jul 2001 15:37:07 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Ping - Totally agree that something along these lines is necessary. Some comments: The draft should say explicitly that the Echo and LSP-Ping messages are sent down the LSPs. If you have multiple LSPs between two nodes then it may be hard to determine that an LSP has failed, since you will get Echo-Reply messages from the other tunnels. The draft should recommend use of the Identifier field in the Echo message in this case. You don't give a message type for the LSP-ping. Were you thinking of a new message? Perhaps the Notify message could be used? There needs to be a means of clearing the LSP-echo object from the RESV message. (So that the test can be repeated at a later point). I would simply add a timer that gets set when you first insert the LSP-ping object in the RESV message and renewed each time you receive a subsequent LSP-ping message. Once the messages cease, the timer will fire and you then send a RESV message without the LSP-ping object. You might add a note to the intermediate node processing that says the text in only there to emphasize good practice. It doen't really impose any new requirements. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Jul 9 17:05: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 RAA28668 for ; Mon, 9 Jul 2001 17:05:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwzc04422; Mon, 9 Jul 2001 21:05:59 GMT Received: by mail-control.mail.uu.net id QQkwzc13663 for mpls-outgoing; Mon, 9 Jul 2001 21:05: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 QQkwzc13172 for ; Mon, 9 Jul 2001 21:05: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 QQkwzc11319 for ; Mon, 9 Jul 2001 21:03:33 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 QQkwzc28762 for ; Mon, 9 Jul 2001 21:03:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA10886 for mpls@uu.net; Mon, 9 Jul 2001 17:03: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 QQkwzc05671 for ; Mon, 9 Jul 2001 21:00:56 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 QQkwzb00578 for ; Mon, 9 Jul 2001 20:57:19 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 QQkwzb05259 for ; Mon, 9 Jul 2001 20:57:18 GMT Received: (qmail 8809 invoked by uid 104); 9 Jul 2001 20:57:18 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.443242 secs); 09/07/2001 13:57:17 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 9 Jul 2001 20:57:17 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f69KvHP05595 for ; Mon, 9 Jul 2001 13:57:17 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jul 2001 14:02:23 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D59@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: draft-pan-lsp-ping-00.txt Date: Mon, 9 Jul 2001 14:02:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C108BA.728BFA40" 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_01C108BA.728BFA40 Content-Type: text/plain; charset="iso-8859-1" Hi, An observations/question: The draft says that the LSP ping packets are sent to the egress LSR with UDP encapsulation. I assume the IP address of the Ping packets are set to the IP address of the desired egress LSR. What happens if a ping packet is delivered to an undesired egress LSR? From the MPLS architecture point of view, it seems that the undesired egress LSR will probably try to forward the Ping packet to the desired LSR using the IP address in the Ping packet, which eventually could send echo-reply back to source. Therefore although the LSP has a wrong path the source will never find out. Yours, Shahram Davari <> ------_=_NextPart_000_01C108BA.728BFA40 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C108BA.728BFA40-- From owner-mpls@UU.NET Mon Jul 9 19:38: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 TAA01136 for ; Mon, 9 Jul 2001 19:38: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 QQkwzm15190; Mon, 9 Jul 2001 23:38:51 GMT Received: by mail-control.mail.uu.net id QQkwzm19785 for mpls-outgoing; Mon, 9 Jul 2001 23:38: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 QQkwzm19762 for ; Mon, 9 Jul 2001 23:37:55 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 QQkwzm29479 for ; Mon, 9 Jul 2001 23:36:09 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkwzm10511 for ; Mon, 9 Jul 2001 23:36:08 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f69Na7f28745 for ; Mon, 9 Jul 2001 19:36:07 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f69NZsi28671; Mon, 9 Jul 2001 19:35:54 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id TAA00968; Mon, 9 Jul 2001 19:35:53 -0400 (EDT) Message-ID: <3B4A3FD7.DA385B75@lucent.com> Date: Mon, 09 Jul 2001 19:35:51 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@uu.net'" Subject: Re: draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D59@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, It's good question. One possible solution is that the penultimate hop should make sure the LSP ping is from its IP fast data path and the egress LSR should make sure the LSP ping is from the penultimate hop directly. Right? Yangguang Shahram Davari wrote: > > Hi, > > An observations/question: > > The draft says that the LSP ping packets are sent to the egress LSR with UDP encapsulation. I assume the IP address of the Ping packets are set to the IP address of the desired egress LSR. What happens if a ping packet is delivered to an undesired egress LSR? From the MPLS architecture point of view, it seems that the undesired egress LSR will probably try to forward the Ping packet to the desired LSR using the IP address in the Ping packet, which eventually could send echo-reply back to source. Therefore although the LSP has a wrong path the source will never find out. > > Yours, > Shahram Davari > > <> From owner-mpls@UU.NET Mon Jul 9 19:40: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 TAA01187 for ; Mon, 9 Jul 2001 19:40:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkwzm19417; Mon, 9 Jul 2001 23:40:50 GMT Received: by mail-control.mail.uu.net id QQkwzm19920 for mpls-outgoing; Mon, 9 Jul 2001 23: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 QQkwzm19892 for ; Mon, 9 Jul 2001 23:39:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkwzm04825 for ; Mon, 9 Jul 2001 23:39:25 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkwzm18103 for ; Mon, 9 Jul 2001 23:39:25 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f69NdOf00291 for ; Mon, 9 Jul 2001 19:39:24 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f69NdOi00285; Mon, 9 Jul 2001 19:39:24 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id TAA01369; Mon, 9 Jul 2001 19:39:23 -0400 (EDT) Message-ID: <3B4A40AA.B1EBB29D@lucent.com> Date: Mon, 09 Jul 2001 19:39:22 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@uu.net'" Subject: Re: draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D59@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, It's good question. One possible solution is that the penultimate hop should make sure the LSP ping is from its IP fast data path (there seems to be some extra work here) and the egress LSR control plane should make sure the LSP ping is from its penultimate hop directly. Right? Yangguang Shahram Davari wrote: > > Hi, > > An observations/question: > > The draft says that the LSP ping packets are sent to the egress LSR with UDP encapsulation. I assume the IP address of the Ping packets are set to the IP address of the desired egress LSR. What happens if a ping packet is delivered to an undesired egress LSR? From the MPLS architecture point of view, it seems that the undesired egress LSR will probably try to forward the Ping packet to the desired LSR using the IP address in the Ping packet, which eventually could send echo-reply back to source. Therefore although the LSP has a wrong path the source will never find out. > > Yours, > Shahram Davari > > <> From owner-mpls@UU.NET Mon Jul 9 20:46: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 UAA02552 for ; Mon, 9 Jul 2001 20:46: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 QQkwzr05039; Tue, 10 Jul 2001 00:46:43 GMT Received: by mail-control.mail.uu.net id QQkwzr17069 for mpls-outgoing; Tue, 10 Jul 2001 00:46: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 QQkwzr16990 for ; Tue, 10 Jul 2001 00:45: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 QQkwzr15159 for ; Tue, 10 Jul 2001 00:45:32 GMT Received: from ureach.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkwzr09091 for ; Tue, 10 Jul 2001 00:45:32 GMT Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49]) by ureach.com (8.9.1/8.8.5) with ESMTP id UAA18674 for ; Mon, 9 Jul 2001 20:45:32 -0400 Received: (from nobody@localhost) by www21.ureach.com (8.9.3/8.9.1) id UAA19689; Mon, 9 Jul 2001 20:45:32 -0400 Date: Mon, 9 Jul 2001 20:45:32 -0400 Message-Id: <200107100045.UAA19689@www21.ureach.com> To: mpls@UU.NET From: Anouk Rocher Reply-to: Subject: Label Spaces and Uniqueness Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Arun, Ross RFC 3031 in section 3.14 says (in the penultimate paragraph) "In MPLS, there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant." Does this mean that while doing label stacking, it is neccessary to allocate labels from a single label space? Isn't this a bit too restrictive for the cases where the inner label represents customer traffic transiting a provider and the outer label represents a path through the provider? In other ways, I think it is appropriate in some situations for labels at different levels of the label-stack to be from different label spaces. Comments? Anouk ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-mpls@UU.NET Mon Jul 9 22:06:25 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 WAA04442 for ; Mon, 9 Jul 2001 22:06: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 QQkwzw03159; Tue, 10 Jul 2001 02:06:37 GMT Received: by mail-control.mail.uu.net id QQkwzw26219 for mpls-outgoing; Tue, 10 Jul 2001 02:06: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 QQkwzw26111 for ; Tue, 10 Jul 2001 02:05: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 QQkwzw03918 for ; Tue, 10 Jul 2001 02:02:27 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 QQkwzw08886 for ; Tue, 10 Jul 2001 02:02:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA26893 for mpls@uu.net; Mon, 9 Jul 2001 22:02:26 -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 QQkwzw19323 for ; Tue, 10 Jul 2001 02:01:46 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 QQkwzw02492 for ; Tue, 10 Jul 2001 02:01:01 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkwzw24293 for ; Tue, 10 Jul 2001 02:01:01 GMT Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6A20rH69030; Mon, 9 Jul 2001 19:00:53 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B4A61D5.2CD45413@juniper.net> Date: Mon, 09 Jul 2001 19:00:53 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: mpls-list , mpls-ops , Nischal Sheth , Dave Cooper Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107091937.PAA11274@telescope.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Swallow wrote: > > Ping - > > Totally agree that something along these lines is necessary. > George, Thanks. > Some comments: > > The draft should say explicitly that the Echo and LSP-Ping messages > are sent down the LSPs. > OK. > If you have multiple LSPs between two nodes then it may be hard to > determine that an LSP has failed, since you will get Echo-Reply > messages from the other tunnels. The draft should recommend use of > the Identifier field in the Echo message in this case. > When using LSP-ping, as we mentioned in 5.1, the echo message should have enough information to identify an LSP. That implies, the message will have RSVP Session and Sender-Template objects. I will articulate it more explicitly soon. > You don't give a message type for the LSP-ping. Were you thinking of > a new message? Perhaps the Notify message could be used? > For LSP-ping messages, the echo packets are encapsulated in UDP with a well-known port number. At the egress, the LSR picks up the echo by "listening" to the UDP port, and replies them back in Resv. I didn't consider the Notify message.... Let me think about it. > There needs to be a means of clearing the LSP-echo object from the > RESV message. (So that the test can be repeated at a later point). > I would simply add a timer that gets set when you first insert the > LSP-ping object in the RESV message and renewed each time you receive > a subsequent LSP-ping message. Once the messages cease, the timer > will fire and you then send a RESV message without the LSP-ping > object. > Interesting. How do I inform the egress about the timer? In the first LSP-ping message, or Path? And how do I turn it off? > You might add a note to the intermediate node processing that says > the text in only there to emphasize good practice. It doen't really > impose any new requirements. > OK. I will. > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 Very helpful. Thanks! - Ping From owner-mpls@UU.NET Tue Jul 10 02:10: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 SMTP id CAA23788 for ; Tue, 10 Jul 2001 02:10:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxam21980; Tue, 10 Jul 2001 06:10:49 GMT Received: by mail-control.mail.uu.net id QQkxam13576 for mpls-outgoing; Tue, 10 Jul 2001 06:10: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 QQkxam13567 for ; Tue, 10 Jul 2001 06:10:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxam24860 for ; Tue, 10 Jul 2001 06:09:00 GMT Received: from inet-tsb.toshiba.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQkxam11653 for ; Tue, 10 Jul 2001 06:08:59 GMT Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id PAA19727; Tue, 10 Jul 2001 15:08:48 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id PAA26791; Tue, 10 Jul 2001 15:08:48 +0900 (JST) Received: from chappy.isl.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id PAA09230; Tue, 10 Jul 2001 15:08:47 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by chappy.isl.rdc.toshiba.co.jp (8.11.3/8.11.3) with ESMTP id f6A65dS07311; Tue, 10 Jul 2001 15:05:40 +0900 (JST) Date: Tue, 10 Jul 2001 15:05:38 +0900 Message-ID: From: Ken Nagami To: Ping Pan Cc: George Swallow , mpls-list , mpls-ops , Nischal Sheth , Dave Cooper Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-Reply-To: <3B4A61D5.2CD45413@juniper.net> References: <200107091937.PAA11274@telescope.cisco.com> <3B4A61D5.2CD45413@juniper.net> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) Organization: Toshiba MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: owner-mpls@UU.NET Precedence: bulk Hi Ping, >> You don't give a message type for the LSP-ping. Were you thinking of >> a new message? Perhaps the Notify message could be used? >> >> For LSP-ping messages, the echo packets are encapsulated in UDP with a >> well-known port number. At the egress, the LSR picks up the echo by >> "listening" to the UDP port, and replies them back in Resv. I didn't >> consider the Notify message.... Let me think about it. Why do you use a RSVP RESV message for an LSP-ping reply? I think it is better to use an UDP packet which is the same as LSP-ping echo message. If you don't use an MPLS control message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for all kind of LSP, such as a static LSP and an LSP established by LDP. I think the section 4 in the draft-satoru-mpls-1hop-lsp-00.txt is the same motivation for your draft. Regards, Ken Nagami From owner-mpls@UU.NET Tue Jul 10 02:59: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 CAA24370 for ; Tue, 10 Jul 2001 02:59:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxap13957; Tue, 10 Jul 2001 06:59:52 GMT Received: by mail-control.mail.uu.net id QQkxap17368 for mpls-outgoing; Tue, 10 Jul 2001 06:59: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 QQkxap17360 for ; Tue, 10 Jul 2001 06:59:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxap29367 for ; Tue, 10 Jul 2001 06:58:14 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQkxap12978 for ; Tue, 10 Jul 2001 06:58:11 GMT Received: from madhu.netbrahma.com ([172.16.72.181]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3F353TLN; Tue, 10 Jul 2001 12:26:23 +0530 Received: from madhu by madhu.netbrahma.com with local (Exim 3.22 #1 (Debian)) id 15JrUf-0002Z3-00 for ; Tue, 10 Jul 2001 12:29:37 +0530 Date: Tue, 10 Jul 2001 12:29:37 +0530 From: Madhusudhan M To: mpls@UU.NET Subject: Session Attribute,.. why optional? Message-ID: <20010710122937.B9561@madhu.netbrahma.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-mpls@UU.NET Precedence: bulk Hi According to RFC 2702,..Requirements of Traffic Engineering over MPLS,... in section 5.4... clearly mentions about the Basic Traffic Engineering Attributes of Traffic Trunks which include - Traffic parameter attributes - Generic Path selection and maintenance attributes - Priority attribute - Preemption attribute - Resilience attribute - Policing attribute Resource Class Affinity attributes are very much important to specify the class of resource which are to be explicitly included or excluded from the path of the traffic trunk.( Section 5.6.3 of RFC 2702) But if u coinsider the Session Attribute Object which contains the Resource Affinity object present in RSVP-TE protocol which is mainly to satisfy the above requirement of the Traffic Engineering is an OPTIONAL Object. I feel when RSVP-TE is designed to support Traffic Enginnering for MPLS, Session Attribute should be a MANDATORY object which has to be considered while setting up the TUNNEL. Section 5.6.3 clearly states the importance of Resource Affinity Attributes which act as policy attributes which as defined in Section 5.4 come under basic TE Attributes of Traffic Trunks which can be used to impose additional constraints on the path traversed by a given traffic trunk. Please correct me if i am wrong..... -- Madhusudhan ---------------- Never be led astray onto the path of virtue. From owner-mpls@UU.NET Tue Jul 10 07:23: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 SMTP id HAA26660 for ; Tue, 10 Jul 2001 07:23: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 QQkxbh06204; Tue, 10 Jul 2001 11:23:27 GMT Received: by mail-control.mail.uu.net id QQkxbh16826 for mpls-outgoing; Tue, 10 Jul 2001 11:22:56 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 QQkxbh16814 for ; Tue, 10 Jul 2001 11:22: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 QQkxbh02744 for ; Tue, 10 Jul 2001 11:21:13 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f39.law4.hotmail.com [216.33.149.39]) id QQkxbh08045 for ; Tue, 10 Jul 2001 11:21:13 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Jul 2001 04:21:12 -0700 Received: from 63.198.218.15 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 10 Jul 2001 11:21:12 GMT X-Originating-IP: [63.198.218.15] From: "Tissa Senevirathne" To: ppvpn@zephion.net, mpls@UU.NET, ccamp@ops.ietf.org, pwe3@ietf.org Subject: Could you comment on ID draft-tsenevir-bgp-l2vpn-00.txt Date: Tue, 10 Jul 2001 11:21:12 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2001 11:21:12.0943 (UTC) FILETIME=[6D4667F0:01C10932] Sender: owner-mpls@UU.NET Precedence: bulk http://search.ietf.org/internet-drafts/draft-tsenevir-bgp-l2vpn-00.txt The above draft present BGP-MP based approach in providing Layer 2 VPN services. The work presented here extends the 2547bis to provide both Layer 2VPN and Layer 3 VPN. Hence allowing providers to provision both Layer 2 and Layer 3VPN services using a single control protocol. I appreciate if you could review and provide comments and feedback Thanks Tissa _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Jul 10 09:12: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 JAA28466 for ; Tue, 10 Jul 2001 09:12: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 QQkxbo15576; Tue, 10 Jul 2001 13:12:32 GMT Received: by mail-control.mail.uu.net id QQkxbo05849 for mpls-outgoing; Tue, 10 Jul 2001 13:11: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 QQkxbo05832 for ; Tue, 10 Jul 2001 13:11: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 QQkxbo05399 for ; Tue, 10 Jul 2001 13:09:21 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 QQkxbo20643 for ; Tue, 10 Jul 2001 13:09:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA23828 for mpls@uu.net; Tue, 10 Jul 2001 09:09:19 -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 QQkxbf24822 for ; Tue, 10 Jul 2001 10:53:52 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 QQkxbf01234 for ; Tue, 10 Jul 2001 10:52:18 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 QQkxbf19474 for ; Tue, 10 Jul 2001 10:52:17 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 f6AAqAP21384; Tue, 10 Jul 2001 03:52:10 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4.cisco.com [10.50.0.3]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AJJ03407 (AUTH rraszuk); Tue, 10 Jul 2001 03:51:55 -0700 (PDT) Message-ID: <3B4ADDD1.B8EC91FF@cisco.com> Date: Tue, 10 Jul 2001 03:49:54 -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: Ken Nagami CC: Ping Pan , George Swallow , mpls-list , mpls-ops , Nischal Sheth , Dave Cooper Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107091937.PAA11274@telescope.cisco.com> <3B4A61D5.2CD45413@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ken, I am affraid if you don't use the RSVP RESV msg the return of LSP-ping packet your response may fail in the same way as the initial ICMP ping failed. Remeber the assumption here is that the data path is broken and control path fine. The current sequence seems to be following: Step 1: Ingress LSR is sending regular ICMP pings via the LSP_X Two cases: A) pings are returned OK (LSP_X is fine) B) pings are lost 1. - LSP_X is fine and return path is broken 2. - LSP_X is broken by itself If B then goto step 2. Step 2: Ingress LSR is sending UDP LSP-pings via LSP_X Two cases: A) UDP LSP-pings arrive on the tail (egress) and ECHO is copied into RSVP RESV msg, then returned to the ingress head proving that LSP_X is fine just there was some issue with the return path of the ICMP from Step 1. B) LSP1's data plane is broken by itself somewhere so the tail (R4) never receives the LSP-ping and R1 never receives the LSP_ECHO object in the RESV msg. R. > Ken Nagami wrote: > > Hi Ping, > > >> You don't give a message type for the LSP-ping. Were you thinking of > >> a new message? Perhaps the Notify message could be used? > >> > > >> For LSP-ping messages, the echo packets are encapsulated in UDP with a > >> well-known port number. At the egress, the LSR picks up the echo by > >> "listening" to the UDP port, and replies them back in Resv. I didn't > >> consider the Notify message.... Let me think about it. > > Why do you use a RSVP RESV message for an LSP-ping reply? > I think it is better to use an UDP packet which is the same as > LSP-ping echo message. If you don't use an MPLS control > message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for > all kind of LSP, such as a static LSP and an LSP established by LDP. > > I think the section 4 in the draft-satoru-mpls-1hop-lsp-00.txt is the same > motivation for your draft. > > Regards, > > Ken Nagami From owner-mpls@UU.NET Tue Jul 10 09: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 SMTP id JAA28538 for ; Tue, 10 Jul 2001 09:16: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 QQkxbp23023; Tue, 10 Jul 2001 13:16:23 GMT Received: by mail-control.mail.uu.net id QQkxbp06240 for mpls-outgoing; Tue, 10 Jul 2001 13:15: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 QQkxbo05993 for ; Tue, 10 Jul 2001 13:14: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 QQkxbo21966 for ; Tue, 10 Jul 2001 13:13:38 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkxbo02095 for ; Tue, 10 Jul 2001 13:13:37 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 10 Jul 2001 18:51: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 f6ADDWt25952; Tue, 10 Jul 2001 18:43:33 +0530 Reply-To: From: "Srikanth" To: Subject: Associating an Entity with a non-PSC interface Date: Tue, 10 Jul 2001 18:47:13 +0530 Message-Id: <000001c10942$a3083480$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, In the case of Generalized Cr-Ldp running between two routers, connected by a non-PSC interface, LDP session should be present between the two for establishment of tunnels. However, draft-ietf-mpls-ldp-mib-07.txt mentions only PSC Parameters. Then, how do we associate an Entity with a non-PSC Interface? Thanks in advance, Srikanth Narayanan. From owner-mpls@UU.NET Tue Jul 10 10:14: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 KAA29974 for ; Tue, 10 Jul 2001 10:14: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 QQkxbs06287; Tue, 10 Jul 2001 14:13:44 GMT Received: by mail-control.mail.uu.net id QQkxbs00781 for mpls-outgoing; Tue, 10 Jul 2001 14:13: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 QQkxbs00765 for ; Tue, 10 Jul 2001 14:13:00 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 QQkxbs12381 for ; Tue, 10 Jul 2001 14:10:38 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 QQkxbs10075 for ; Tue, 10 Jul 2001 14:10:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA28270 for mpls@uu.net; Tue, 10 Jul 2001 10:10:36 -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 QQkxbs00127 for ; Tue, 10 Jul 2001 14:10:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxbs10704 for ; Tue, 10 Jul 2001 14:09:53 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 QQkxbs08801 for ; Tue, 10 Jul 2001 14:09:52 GMT Received: (qmail 20891 invoked by uid 104); 10 Jul 2001 14:09:52 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.402363 secs); 10/07/2001 07:09:51 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 14:09:51 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AE9qP14324; Tue, 10 Jul 2001 07:09:52 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 07:14:59 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5D@BBY1EXM01> From: Shahram Davari To: "'Yangguang Xu'" Cc: "'mpls@uu.net'" Subject: RE: draft-pan-lsp-ping-00.txt Date: Tue, 10 Jul 2001 07:14: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 Hi, > -----Original Message----- > From: Yangguang Xu [mailto:xuyg@lucent.com] > Sent: Monday, July 09, 2001 7:39 PM > To: Shahram Davari > Cc: 'mpls@uu.net' > Subject: Re: draft-pan-lsp-ping-00.txt > > > Hello, > > It's good question. One possible solution is that the > penultimate hop should > make sure the LSP ping is from its IP fast data path (there > seems to be some > extra work here) and the egress LSR control plane should make > sure the LSP ping > is from its penultimate hop directly. Right? This is not possible, becasue penultimate hop MUST not look at the IP header. -Shahram > > Yangguang > > Shahram Davari wrote: > > > > Hi, > > > > An observations/question: > > > > The draft says that the LSP ping packets are sent to the > egress LSR with UDP encapsulation. I assume the IP address of > the Ping packets are set to the IP address of the desired > egress LSR. What happens if a ping packet is delivered to an > undesired egress LSR? From the MPLS architecture point of > view, it seems that the undesired egress LSR will probably > try to forward the Ping packet to the desired LSR using the > IP address in the Ping packet, which eventually could send > echo-reply back to source. Therefore although the LSP has a > wrong path the source will never find out. > > > > Yours, > > Shahram Davari > > > > <> > From owner-mpls@UU.NET Tue Jul 10 10:17: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 SMTP id KAA00006 for ; Tue, 10 Jul 2001 10:17: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 QQkxbs08669; Tue, 10 Jul 2001 14:14:59 GMT Received: by mail-control.mail.uu.net id QQkxbs00788 for mpls-outgoing; Tue, 10 Jul 2001 14:13:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxbs00776 for ; Tue, 10 Jul 2001 14:13:09 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 QQkxbs13529 for ; Tue, 10 Jul 2001 14:12: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 QQkxbs13007 for ; Tue, 10 Jul 2001 14:12:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA28367 for mpls@uu.net; Tue, 10 Jul 2001 10:12: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 QQkxbs00404 for ; Tue, 10 Jul 2001 14:11:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxbs21610 for ; Tue, 10 Jul 2001 14:07:21 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 QQkxbs04562 for ; Tue, 10 Jul 2001 14:07:20 GMT Received: (qmail 20612 invoked by uid 104); 10 Jul 2001 14:07:20 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.395009 secs); 10/07/2001 07:07:19 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 14:07:19 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AE7KP13372; Tue, 10 Jul 2001 07:07:20 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 07:12:27 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5C@BBY1EXM01> From: Shahram Davari To: "'anouk@ureach.com'" , mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 07:12:27 -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, > -----Original Message----- > From: Anouk Rocher [mailto:anouk@ureach.com] > Sent: Monday, July 09, 2001 8:46 PM > To: mpls@UU.NET > Subject: Label Spaces and Uniqueness > > > Eric, Arun, Ross > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > "In MPLS, there is no notion of > having a different label space for different levels of the > hierarchy; > when interpreting a label, the level of the label is irrelevant." > > Does this mean that while doing label stacking, it is neccessary to > allocate labels from a single label space? Yes. Isn't this a bit too > restrictive for the cases where the inner label represents > customer traffic transiting a provider and the outer label represents > a path through the provider? No. This rule must be followed. The reason is that an LSR has no way of knowing which level of hierarchy a label belongs to. > > In other ways, I think it is appropriate in some situations for labels > at different levels of the label-stack to be from different > label spaces. NO. This is not right. The only time that you may find exactly same labels in different layers of hierarchy is when those labels are distributed by two different LSRs. This may happen when you have a label stack of more than 2 labels. -Shahram > > Comments? > > Anouk > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > From owner-mpls@UU.NET Tue Jul 10 10:20: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 KAA00068 for ; Tue, 10 Jul 2001 10:20: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 QQkxbt25346; Tue, 10 Jul 2001 14:19:46 GMT Received: by mail-control.mail.uu.net id QQkxbt01612 for mpls-outgoing; Tue, 10 Jul 2001 14:19: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 QQkxbt01563 for ; Tue, 10 Jul 2001 14:18:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxbs20169 for ; Tue, 10 Jul 2001 14:14:50 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 QQkxbs13076 for ; Tue, 10 Jul 2001 14:14: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 KAA09941 for ; Tue, 10 Jul 2001 10:14: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 KAA24015 for ; Tue, 10 Jul 2001 10:14:49 -0400 (EDT) Message-ID: <3B4B0DC3.8200B7D3@marconi.com> Date: Tue, 10 Jul 2001 10:14: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: Label Spaces and Uniqueness References: <200107100045.UAA19689@www21.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk Rocher wrote: > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > "In MPLS, there is no notion of > having a different label space for different levels of the > hierarchy; when interpreting a label, the level of the label is > irrelevant." > > Does this mean that while doing label stacking, it is neccessary to > allocate labels from a single label space? Yes. > Isn't this a bit too restrictive for the cases where the inner > label represents customer traffic transiting a provider and the > outer label represents a path through the provider? What's your alternative? When a data packet arrives, how are you going to know what label space the top label should belong to? -- David From owner-mpls@UU.NET Tue Jul 10 10:46: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 KAA01771 for ; Tue, 10 Jul 2001 10:46: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 QQkxbv04843; Tue, 10 Jul 2001 14:46:32 GMT Received: by mail-control.mail.uu.net id QQkxbv04797 for mpls-outgoing; Tue, 10 Jul 2001 14:45: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 QQkxbv04779 for ; Tue, 10 Jul 2001 14:45:44 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 QQkxbv23881 for ; Tue, 10 Jul 2001 14:45:03 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 QQkxbv21249 for ; Tue, 10 Jul 2001 14:45:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17113; Tue, 10 Jul 2001 10:44:47 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA05083; Tue, 10 Jul 2001 10:44:44 -0400 (EDT) Message-Id: <200107101444.KAA05083@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: raszuk@cisco.com cc: Ken Nagami , Ping Pan , George Swallow , mpls-list , mpls-ops , Nischal Sheth , Dave Cooper Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Tue, 10 Jul 2001 03:49:54 -0700. <3B4ADDD1.B8EC91FF@cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Jul 2001 10:44:44 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01771 I'm still confused about what this actually tells you. From the failure of the ICMP pings, you already know that either the LSP's data plane is failing, or else there is no operational return path for data packets. However, there is apparently an operational path for the forward and reverse control traffic. If you send the LSP-ping down the LSP itself, then it "ought to" fail if and only if the LSP's data plane is failing. So presumably, if it succeeds you know that the failure is in the reverse data path. If you do not send the LSP-ping down the LSP itself, then it will likely succeed, but you don't learn anything. So the most you can learn from this is that the failure of the original ICMP ping is due to a problem in the return path for data packets. Is that correct? But if all you want to know is whether the reverse data path is working, why not just do ordinary ICMP ping in the reverse direction? What am I missing? From owner-mpls@UU.NET Tue Jul 10 11:05: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 LAA02716 for ; Tue, 10 Jul 2001 11:05: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 QQkxbw21617; Tue, 10 Jul 2001 15:05:51 GMT Received: by mail-control.mail.uu.net id QQkxbw17576 for mpls-outgoing; Tue, 10 Jul 2001 15:05: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 QQkxbw17470 for ; Tue, 10 Jul 2001 15:05: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 QQkxbw20488 for ; Tue, 10 Jul 2001 15:04: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 QQkxbw04409 for ; Tue, 10 Jul 2001 15:04:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA04694 for mpls@uu.net; Tue, 10 Jul 2001 11:04:00 -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 QQkxbw11674 for ; Tue, 10 Jul 2001 15:03:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxbw19419 for ; Tue, 10 Jul 2001 15:01:23 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 QQkxbw02538 for ; Tue, 10 Jul 2001 15:01:22 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 LAA19100; Tue, 10 Jul 2001 11:01:11 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA23846; Tue, 10 Jul 2001 11:01:11 -0400 (EDT) Message-Id: <200107101501.LAA23846@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Ping Pan cc: George Swallow , mpls-list , mpls-ops , Nischal Sheth , Dave Cooper , swallow@cisco.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of "Mon, 09 Jul 2001 19:00:53 PDT." <3B4A61D5.2CD45413@juniper.net> Date: Tue, 10 Jul 2001 11:01:11 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Ping - > > If you have multiple LSPs between two nodes then it may be hard to > > determine that an LSP has failed, since you will get Echo-Reply > > messages from the other tunnels. The draft should recommend use of > > the Identifier field in the Echo message in this case. > > > > When using LSP-ping, as we mentioned in 5.1, the echo message should > have enough information to identify an LSP. That implies, the message > will have RSVP Session and Sender-Template objects. I will articulate it > more explicitly soon. As I understand the draft you monitor tunnels with normal ICMP pings and only use the LSP-ping when something appears awry. Right? What I was referring to in the above comment is the *normal* ICMP ping. > > There needs to be a means of clearing the LSP-echo object from the > > RESV message. (So that the test can be repeated at a later point). > > I would simply add a timer that gets set when you first insert the > > LSP-ping object in the RESV message and renewed each time you receive > > a subsequent LSP-ping message. Once the messages cease, the timer > > will fire and you then send a RESV message without the LSP-ping > > object. > > > > Interesting. How do I inform the egress about the timer? I was just thinking of a default (perhaps configurable) say 1 minute? > In the first > LSP-ping message, or Path? And how do I turn it off? Keep sending LSP-pings. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 10 11:08: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 LAA02886 for ; Tue, 10 Jul 2001 11:08: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 QQkxbw13956; Tue, 10 Jul 2001 15:01:24 GMT Received: by mail-control.mail.uu.net id QQkxbw08692 for mpls-outgoing; Tue, 10 Jul 2001 15:00: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 QQkxbw07881 for ; Tue, 10 Jul 2001 15:00: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 QQkxbv16409 for ; Tue, 10 Jul 2001 14:59:47 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxbv29560 for ; Tue, 10 Jul 2001 14:59:47 GMT Message-ID: <3B4B185C.6AC2BD30@sandburst.com> Date: Tue, 10 Jul 2001 10:59:40 -0400 From: Eric Gray MIME-Version: 1.0 To: David Charlap , Shahram Davari Cc: mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: <200107100045.UAA19689@www21.ureach.com> <3B4B0DC3.8200B7D3@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 and Shahram, Two issues: one is that the original question assumes an erroneous behavior and the other is that the text really is too restrictive (but so what?). The erroneous behavior is the reference to 'inner' labels that belong to a different domain. In this case, they are clearly drawn from a different label 'context' (the fact that they are drawn from the same 20-bit number space is not at all interesting). But this is irrelevant because an LSR would only see these labels if someone, somewhere, is misbehaving badly. The text really is too restrictive because it specifies a behavior that is strictly of local significance to a single LSR. Occasionally, specifications of interoperable behavior will overstep their boundaries and attempt to specify behaviors that have little or nothing to do with interoperability. Often, this happens in the interest of simplifying the over-all behavioral description. When this is the case, this can be (and often is) a very good thing. However, where an implementer can be sure a specification has done this, there is no reason not to depart from the specified behavior in implementing a behavior that is strictly of local significance. Certainly it is possible for an LSR to use the LSP on which a labeled packet is received as 'context' for interpreting that label - as long as the LSR is able to determine which LSP it is receiving the packet on. This would be one way to treat an LSP as a logical interface. Possible does not equate to easy, so it may be the case that many LSRs do not do this. But that does not mean it won't work. -- Eric Gray David Charlap wrote: > Anouk Rocher wrote: > > > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > > > "In MPLS, there is no notion of > > having a different label space for different levels of the > > hierarchy; when interpreting a label, the level of the label is > > irrelevant." > > > > Does this mean that while doing label stacking, it is neccessary to > > allocate labels from a single label space? > > Yes. > > > Isn't this a bit too restrictive for the cases where the inner > > label represents customer traffic transiting a provider and the > > outer label represents a path through the provider? > > What's your alternative? When a data packet arrives, how are you going > to know what label space the top label should belong to? > > -- David Shahram Davari wrote: > Hi, > > > -----Original Message----- > > From: Anouk Rocher [mailto:anouk@ureach.com] > > Sent: Monday, July 09, 2001 8:46 PM > > To: mpls@UU.NET > > Subject: Label Spaces and Uniqueness > > > > > > Eric, Arun, Ross > > > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > > > "In MPLS, there is no notion of > > having a different label space for different levels of the > > hierarchy; > > when interpreting a label, the level of the label is irrelevant." > > > > Does this mean that while doing label stacking, it is neccessary to > > allocate labels from a single label space? > > Yes. > > Isn't this a bit too > > restrictive for the cases where the inner label represents > > customer traffic transiting a provider and the outer label represents > > a path through the provider? > > No. This rule must be followed. The reason is that an LSR has no way of > knowing which level of hierarchy a label belongs to. > > > > > In other ways, I think it is appropriate in some situations for labels > > at different levels of the label-stack to be from different > > label spaces. > > NO. This is not right. The only time that you may find exactly same labels > in different layers of hierarchy is when those labels are distributed by two > different LSRs. This may happen when you have a label stack of more than 2 labels. > > -Shahram > From owner-mpls@UU.NET Tue Jul 10 11:10: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 LAA02961 for ; Tue, 10 Jul 2001 11:10:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxbw24119; Tue, 10 Jul 2001 15:06:56 GMT Received: by mail-control.mail.uu.net id QQkxbw17592 for mpls-outgoing; Tue, 10 Jul 2001 15:05:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxbw17571 for ; Tue, 10 Jul 2001 15:05: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 QQkxbv09929 for ; Tue, 10 Jul 2001 14:58: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 QQkxbv19312 for ; Tue, 10 Jul 2001 14:58:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA04207 for mpls@uu.net; Tue, 10 Jul 2001 10:58:23 -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 QQkxbv06042 for ; Tue, 10 Jul 2001 14:57: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 QQkxbv03888 for ; Tue, 10 Jul 2001 14:51:26 GMT Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkxbv05860 for ; Tue, 10 Jul 2001 14:51:25 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6AEnNH26950; Tue, 10 Jul 2001 07:49:33 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4.cisco.com [10.50.0.3]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AJK00584 (AUTH rraszuk); Tue, 10 Jul 2001 07:50:25 -0700 (PDT) Message-ID: <3B4B15BA.9E8A0703@cisco.com> Date: Tue, 10 Jul 2001 07:48:26 -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: erosen@cisco.com CC: Ken Nagami , Ping Pan , George Swallow , mpls-list , mpls-ops , Nischal Sheth , Dave Cooper Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107101444.KAA05083@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, > So the most you can learn from this is that the failure of the original ICMP > ping is due to a problem in the return path for data packets. Is that > correct? Yes and in the same time prove that the LSP under test is fine. > But if all you want to know is whether the reverse data path is working, why > not just do ordinary ICMP ping in the reverse direction? I am sure the same test procedure will be executed in the reverse direction as well again to verify unidirectional LSP state not the both direction state. I think that is the author's intention. R. > > What am I missing? > Eric Rosen wrote: > > I'm still confused about what this actually tells you. > > From the failure of the ICMP pings, you already know that either the LSP's > data plane is failing, or else there is no operational return path for data > packets. However, there is apparently an operational path for the forward > and reverse control traffic. > > If you send the LSP-ping down the LSP itself, then it "ought to" fail if and > only if the LSP's data plane is failing. So presumably, if it succeeds you > know that the failure is in the reverse data path. > > If you do not send the LSP-ping down the LSP itself, then it will likely > succeed, but you don't learn anything. > > So the most you can learn from this is that the failure of the original ICMP > ping is due to a problem in the return path for data packets. Is that > correct? > > But if all you want to know is whether the reverse data path is working, why > not just do ordinary ICMP ping in the reverse direction? > > What am I missing? From owner-mpls@UU.NET Tue Jul 10 11:32: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 SMTP id LAA03904 for ; Tue, 10 Jul 2001 11:32: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 QQkxbx03563; Tue, 10 Jul 2001 15:27:22 GMT Received: by mail-control.mail.uu.net id QQkxbx29169 for mpls-outgoing; Tue, 10 Jul 2001 15:26: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 QQkxbx29153 for ; Tue, 10 Jul 2001 15:26: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 QQkxbx15807 for ; Tue, 10 Jul 2001 15:26:17 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f5.law4.hotmail.com [216.33.149.5]) id QQkxbx01158 for ; Tue, 10 Jul 2001 15:26:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Jul 2001 08:26:16 -0700 Received: from 192.35.17.233 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 10 Jul 2001 15:26:15 GMT X-Originating-IP: [192.35.17.233] From: "Sherry Wei" To: Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 15:26:15 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2001 15:26:16.0117 (UTC) FILETIME=[A90CB650:01C10954] Sender: owner-mpls@UU.NET Precedence: bulk Hi, If the same label value exsists in different levels of the label stack, will it cause a loop? For example, the up most label value is 20 and the second up most label value is also 20. In the ILM table, this label value indicates the according operation is "pop and lookup"... I think the same label value in different levels of the stack should have different meaning. Please correct me if I am not right. Sherry >From: Shahram Davari >To: "'anouk@ureach.com'" , mpls@UU.NET >Subject: RE: Label Spaces and Uniqueness >Date: Tue, 10 Jul 2001 07:12:27 -0700 > >Hi, > > > -----Original Message----- > > From: Anouk Rocher [mailto:anouk@ureach.com] > > Sent: Monday, July 09, 2001 8:46 PM > > To: mpls@UU.NET > > Subject: Label Spaces and Uniqueness > > > > > > Eric, Arun, Ross > > > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > > > "In MPLS, there is no notion of > > having a different label space for different levels of the > > hierarchy; > > when interpreting a label, the level of the label is irrelevant." > > > > Does this mean that while doing label stacking, it is neccessary to > > allocate labels from a single label space? > >Yes. > > Isn't this a bit too > > restrictive for the cases where the inner label represents > > customer traffic transiting a provider and the outer label represents > > a path through the provider? > >No. This rule must be followed. The reason is that an LSR has no way of >knowing which level of hierarchy a label belongs to. > > > > > In other ways, I think it is appropriate in some situations for labels > > at different levels of the label-stack to be from different > > label spaces. > >NO. This is not right. The only time that you may find exactly same labels >in different layers of hierarchy is when those labels are distributed by >two >different LSRs. This may happen when you have a label stack of more than 2 >labels. > >-Shahram > > > > > Comments? > > > > Anouk > > > > ________________________________________________ > > Get your own "800" number > > Voicemail, fax, email, and a lot more > > http://www.ureach.com/reg/tag > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Tue Jul 10 11:32: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 SMTP id LAA03915 for ; Tue, 10 Jul 2001 11:32: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 QQkxbx21071; Tue, 10 Jul 2001 15:28:35 GMT Received: by mail-control.mail.uu.net id QQkxbx29202 for mpls-outgoing; Tue, 10 Jul 2001 15:27:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxbx29174 for ; Tue, 10 Jul 2001 15:26: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 QQkxbx01625 for ; Tue, 10 Jul 2001 15:23:45 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 QQkxbx24742 for ; Tue, 10 Jul 2001 15:23:45 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Tue, 10 Jul 2001 16:22:05 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Tue, 10 Jul 2001 16:21:58 +0100 Message-ID: To: ken.nagami@toshiba.co.jp, pingpan@juniper.net Cc: swallow@cisco.com, mpls@UU.NET, mpls-ops@mplsrc.com, nsheth@juniper.net, dcooper@gblx.net Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Tue, 10 Jul 2001 16:21:54 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Ping/Ken, Ken wrote 10 July 2001 07:06 > If you don't use an MPLS control > message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for > all kind of LSP, such as a static LSP and an LSP established by LDP. NH=>I agree. Here are some further comments on the draft and the problem it is trying to address: 1 MPLS traffic-plane defect handling should, as a design principle, be independent of the signalling protocol used in the control-plane (or indeed any other functional component of the control-plane, eg routing protocol, or the management-plane). So whether we are considering LDP, RSVP-TE or CR-LDP (or other) signalling (routing) protocols the defect handling of the traffic-plane should be independent of these and identical (as far as practicably possible) in all cases. 2 One specific limit case of 1 is where there is no control-plane. Traffic-plane defect handling must be still valid and consistent in this case. 3 An aside corollary of 1 and 2 is that any trails provisioned by network management (be these with or without a control-plane component, eg so-called 'hard' and 'soft' permanent connections) must not be taken down by failures of any control-plane components. In the case of this draft (see section 6.2), one would not wish to remove soft permanent LSPs due to a failure of the returned ICMP-like objects in the RESV messages....either due to (i) a failure of the (return) data-plane of the control-plane or (ii) a failure of the (returned) RSVP protocol itself. 4 Before defining specific solutions for defect handling of the traffic-plane (or indeed the control-plane functional components, eg its data-plane or the specific signalling or routing protocols used thereon) one must first identify/agree what defect types are relevant. For standardisation/interworking, and subsequent specification of outage metrics which might be used in SLAs and thus require linking with NMS/OSS activities like fault-management and billing, operators will need to clear entry and exit criteria specified for defects, and the consequent actions that need to be taken on specific defect entry. For example, for some defect types it may be vital to squelch the traffic-plane data (of the client layer networks) to protect the security of customer traffic, eg traffic leaking out of a VPN say. Alarm handling must also be considered to suppress alarm storms in higher layer networks. The defects that need defining for MPLS layer trails are: - simple breaks sourced from layer networks below the MPLS fabric, eg SDH - simple breaks sourced from layer networks within the MPLS fabric, ie at a lower or peer LSP level to the LSP level considered - swapped LSPs at a given LSP level - mismerged LSPs at a given LSP level (where the offending LSP traffic may or may not be affected, ie mis-direction or unintended replication respectively) Currently the draft does not address any of the above. 6 Of perhaps more minor note......the control-plane gets continuously loaded with traffic-plane OAM traffic (it has to since defect detection must be proactive, ie should not rely on user to complain). Please see draft-harrison-mpls-oam-req-00.txt (problem defintion) and draft-harrison-mpls-oam-00.txt (solution to problem definition) which take all the above points into account. regards, Neil From owner-mpls@UU.NET Tue Jul 10 11:44: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 LAA04422 for ; Tue, 10 Jul 2001 11:44: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 QQkxby05458; Tue, 10 Jul 2001 15:43:05 GMT Received: by mail-control.mail.uu.net id QQkxby00486 for mpls-outgoing; Tue, 10 Jul 2001 15:42: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 QQkxby00478 for ; Tue, 10 Jul 2001 15:42: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 QQkxby21635 for ; Tue, 10 Jul 2001 15:37:06 GMT Received: from web11405.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11405.mail.yahoo.com [216.136.131.235]) id QQkxby09326 for ; Tue, 10 Jul 2001 15:37:05 GMT Message-ID: <20010710153705.18613.qmail@web11405.mail.yahoo.com> Received: from [65.194.140.2] by web11405.mail.yahoo.com via HTTP; Tue, 10 Jul 2001 08:37:05 PDT Date: Tue, 10 Jul 2001 08:37:05 -0700 (PDT) From: Sanjay Wadhwa Subject: Re: draft-pan-lsp-ping-00.txt To: Shahram Davari , "'mpls@uu.net'" In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D59@BBY1EXM01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk The ingress could send this packet with IP ttl of 1 since the intention is to never ip forward this packet. The wrong egress in this case would drop it which is the desired behaviour. -Sanjay --- Shahram Davari wrote: > Hi, > > An observations/question: > > The draft says that the LSP ping packets are sent to the egress LSR > with UDP encapsulation. I assume the IP address of the Ping packets > are set to the IP address of the desired egress LSR. What happens if > a ping packet is delivered to an undesired egress LSR? From the MPLS > architecture point of view, it seems that the undesired egress LSR > will probably try to forward the Ping packet to the desired LSR using > the IP address in the Ping packet, which eventually could send > echo-reply back to source. Therefore although the LSP has a wrong > path the source will never find out. > > Yours, > Shahram Davari > > <> > > ATTACHMENT part 2 application/octet-stream name=Shahram Davari.vcf __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Jul 10 11:52: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 LAA04899 for ; Tue, 10 Jul 2001 11:52: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 QQkxbz15904; Tue, 10 Jul 2001 15:51:41 GMT Received: by mail-control.mail.uu.net id QQkxbz01680 for mpls-outgoing; Tue, 10 Jul 2001 15:51: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 QQkxbz01670 for ; Tue, 10 Jul 2001 15:50:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxbz15089 for ; Tue, 10 Jul 2001 15:49:49 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 QQkxbz07667 for ; Tue, 10 Jul 2001 15:49:49 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA10328 for mpls@uu.net; Tue, 10 Jul 2001 11:49:48 -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 QQkxby29899 for ; Tue, 10 Jul 2001 15: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 QQkxby18610 for ; Tue, 10 Jul 2001 15:34:37 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxby18780 for ; Tue, 10 Jul 2001 15:34:37 GMT Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6AFYOH89353; Tue, 10 Jul 2001 08:34:24 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B4B2080.B9BC992B@juniper.net> Date: Tue, 10 Jul 2001 08:34:24 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ken Nagami CC: George Swallow , mpls-list , mpls-ops , Nischal Sheth , Dave Cooper Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107091937.PAA11274@telescope.cisco.com> <3B4A61D5.2CD45413@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ken Nagami wrote: > > Hi Ping, > > >> You don't give a message type for the LSP-ping. Were you thinking of > >> a new message? Perhaps the Notify message could be used? > >> > > >> For LSP-ping messages, the echo packets are encapsulated in UDP with a > >> well-known port number. At the egress, the LSR picks up the echo by > >> "listening" to the UDP port, and replies them back in Resv. I didn't > >> consider the Notify message.... Let me think about it. > > Why do you use a RSVP RESV message for an LSP-ping reply? > I think it is better to use an UDP packet which is the same as > LSP-ping echo message. If you don't use an MPLS control > message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for > all kind of LSP, such as a static LSP and an LSP established by LDP. > Ken, LSP-ping is used to probe the data path. There are cases where the data path goes wrong, and you have no idea where the problem is (forwarding LSP, reverse LSP, ...). Since the only operational path that you can count is the control path, so you reply via RSVP. If you use UDP to return the reply, what if the returning path is broken? Should the user assumes the forwarding LSP is bad, or the reverse? At the same time, if you can come up with a simple, scalable, backward compatible method to use for LDP (including the case where you can label merging) as well, please do let us know. :-) - Ping From owner-mpls@UU.NET Tue Jul 10 12:05: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 MAA06111 for ; Tue, 10 Jul 2001 12:05: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 QQkxca11481; Tue, 10 Jul 2001 16:05:28 GMT Received: by mail-control.mail.uu.net id QQkxca11857 for mpls-outgoing; Tue, 10 Jul 2001 16:04: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 QQkxca11466 for ; Tue, 10 Jul 2001 16:04:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxca02515 for ; Tue, 10 Jul 2001 16:03:27 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 QQkxca07617 for ; Tue, 10 Jul 2001 16:03:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA12265 for mpls@uu.net; Tue, 10 Jul 2001 12:03:25 -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 QQkxca08430 for ; Tue, 10 Jul 2001 16:02: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 QQkxca01340 for ; Tue, 10 Jul 2001 16:02:29 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 QQkxca05760 for ; Tue, 10 Jul 2001 16:02:28 GMT Received: (qmail 1970 invoked by uid 104); 10 Jul 2001 16:02:28 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.405816 secs); 10/07/2001 09:02:27 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 16:02:27 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AG2SP08318; Tue, 10 Jul 2001 09:02:28 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 09:07:36 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D61@BBY1EXM01> From: Shahram Davari To: "'Sanjay Wadhwa'" , "'mpls@uu.net'" Subject: RE: draft-pan-lsp-ping-00.txt Date: Tue, 10 Jul 2001 09:07:35 -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 Sanjay, Seems like a good solution. But the only problem is that the source won't find out why the LSP has connectivity problem, is it due to mis-routing or is it due to lower level failures. Yours, -Shahram > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > Sent: Tuesday, July 10, 2001 11:37 AM > To: Shahram Davari; 'mpls@uu.net' > Subject: Re: draft-pan-lsp-ping-00.txt > > > The ingress could send this packet with IP ttl of 1 since the > intention > is to never ip forward this packet. The wrong egress in this > case would > drop it which is the desired behaviour. > > -Sanjay > > > --- Shahram Davari wrote: > > Hi, > > > > An observations/question: > > > > The draft says that the LSP ping packets are sent to the egress LSR > > with UDP encapsulation. I assume the IP address of the Ping packets > > are set to the IP address of the desired egress LSR. What happens if > > a ping packet is delivered to an undesired egress LSR? From the MPLS > > architecture point of view, it seems that the undesired egress LSR > > will probably try to forward the Ping packet to the desired > LSR using > > the IP address in the Ping packet, which eventually could send > > echo-reply back to source. Therefore although the LSP has a wrong > > path the source will never find out. > > > > Yours, > > Shahram Davari > > > > <> > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram Davari.vcf > > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > From owner-mpls@UU.NET Tue Jul 10 12:08: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 MAA06189 for ; Tue, 10 Jul 2001 12: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 QQkxca13735; Tue, 10 Jul 2001 16:06:50 GMT Received: by mail-control.mail.uu.net id QQkxca13769 for mpls-outgoing; Tue, 10 Jul 2001 16:06: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 QQkxca13159 for ; Tue, 10 Jul 2001 16:05: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 QQkxca16344 for ; Tue, 10 Jul 2001 16:04:29 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 QQkxca09515 for ; Tue, 10 Jul 2001 16:04:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA12440 for mpls@uu.net; Tue, 10 Jul 2001 12:04: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 QQkxbz01885 for ; Tue, 10 Jul 2001 15:52: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 QQkxbz05897 for ; Tue, 10 Jul 2001 15:50:00 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 QQkxbz12434 for ; Tue, 10 Jul 2001 15:49:59 GMT Received: (qmail 56 invoked by uid 104); 10 Jul 2001 15:49:59 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.437075 secs); 10/07/2001 08:49:58 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 15:49:58 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AFnxP01854; Tue, 10 Jul 2001 08:49:59 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 08:55:07 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> From: Shahram Davari To: "'Sherry Wei'" Cc: mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 08:55: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 Sherry, You are partially right. Only when those labels are distributed by the same LSR must be unique across different levels. For example assume this architecture: B-----C--------E-------F A-------B----------------------F-------G LSP1: ABFG LSP2: BCEF Assume LSR F distributes label L1 to B for LSP1, and label L2 to E for LSP2. Since LSR E has is not allowed and does not need to look at the lower label belonging to LSP1, it can distribute an identical label L1 to C for LSP2. So in the cross section from C->E the packet may have 2 labels both being L1. I think Eric Gray is right, and probably RFC-3031 should say: "In an LSR (rather than MPLS), there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant." Yours, -Shahram > -----Original Message----- > From: Sherry Wei [mailto:sherry_wei@hotmail.com] > Sent: Tuesday, July 10, 2001 11:26 AM > To: Shahram Davari > Cc: mpls@uu.net > Subject: RE: Label Spaces and Uniqueness > > > Hi, > > If the same label value exsists in different levels of the > label stack, will > it cause a loop? For example, the up most label value is 20 > and the second > up most label value is also 20. In the ILM table, this label > value indicates > the according operation is "pop and lookup"... I think the > same label value > in different levels of the stack should have different meaning. > > Please correct me if I am not right. > > Sherry > > > >From: Shahram Davari > >To: "'anouk@ureach.com'" , mpls@UU.NET > >Subject: RE: Label Spaces and Uniqueness > >Date: Tue, 10 Jul 2001 07:12:27 -0700 > > > >Hi, > > > > > -----Original Message----- > > > From: Anouk Rocher [mailto:anouk@ureach.com] > > > Sent: Monday, July 09, 2001 8:46 PM > > > To: mpls@UU.NET > > > Subject: Label Spaces and Uniqueness > > > > > > > > > Eric, Arun, Ross > > > > > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > > > > > "In MPLS, there is no notion of > > > having a different label space for different levels of the > > > hierarchy; > > > when interpreting a label, the level of the label is > irrelevant." > > > > > > Does this mean that while doing label stacking, it is > neccessary to > > > allocate labels from a single label space? > > > >Yes. > > > > Isn't this a bit too > > > restrictive for the cases where the inner label represents > > > customer traffic transiting a provider and the outer > label represents > > > a path through the provider? > > > >No. This rule must be followed. The reason is that an LSR > has no way of > >knowing which level of hierarchy a label belongs to. > > > > > > > > In other ways, I think it is appropriate in some > situations for labels > > > at different levels of the label-stack to be from different > > > label spaces. > > > >NO. This is not right. The only time that you may find > exactly same labels > >in different layers of hierarchy is when those labels are > distributed by > >two > >different LSRs. This may happen when you have a label stack > of more than 2 > >labels. > > > >-Shahram > > > > > > > > Comments? > > > > > > Anouk > > > > > > ________________________________________________ > > > Get your own "800" number > > > Voicemail, fax, email, and a lot more > > > http://www.ureach.com/reg/tag > > > > > > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Tue Jul 10 12:30: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 SMTP id MAA07244 for ; Tue, 10 Jul 2001 12:30: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 QQkxcb22755; Tue, 10 Jul 2001 16:28:22 GMT Received: by mail-control.mail.uu.net id QQkxcb25907 for mpls-outgoing; Tue, 10 Jul 2001 16:27: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 QQkxcb25895 for ; Tue, 10 Jul 2001 16:27: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 QQkxcb11930 for ; Tue, 10 Jul 2001 16:27:04 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 QQkxcb03144 for ; Tue, 10 Jul 2001 16:27:04 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26601 for ; Tue, 10 Jul 2001 12:27:02 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05011 for ; Tue, 10 Jul 2001 12:27:03 -0400 (EDT) Message-ID: <3B4B2CC2.EA2243A7@marconi.com> Date: Tue, 10 Jul 2001 12:26:42 -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: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > You are partially right. Only when those labels are distributed by > the same LSR must be unique across different levels. For example > assume this architecture: > > > B-----C--------E-------F > A-------B----------------------F-------G > > LSP1: ABFG > LSP2: BCEF > > Assume LSR F distributes label L1 to B for LSP1, and label L2 to E > for LSP2. Since LSR E has is not allowed and does not need to look > at the lower label belonging to LSP1, it can distribute an identical > label L1 to C for LSP2. So in the cross section from C->E the packet > may have 2 labels both being L1. No argument here. But I dont't think this is the really important issue. It is obvious that E might send a label mapping identical to what's used in the outer LSP. After all, E has no knowledge of that outer LSP. It would be unreasonable to expect a router to remain in sync with routers that it is not sharing signaling information with. A more important question is what happens at router F. Router F must not send the same label to E and to B. When a packet arrives from E, the outer label will indicate a pop. Then the remaining label will indicate a swap. (Let's pretend there are more routers beyond G, so PHP won't come into play here.) If the two labels are identical, then the forwarding engine in F won't be able to apply different semantics to them. It should not use the size of the label stack as a way of differentiating, because the outer label (sent from F to E) may appear without a stack underneath it. (eg. for traffic that originates from B and terminates at F). This is what the RFC is talking about. The only way for F to determine whether a packet is from LSP1 or LSP2 is using the label. If the label values for the two are identical, then some other means, beyond the scope of MPLS, must be used to determine the LSP that the packet belongs to. The easiest way to ensure that the same label is not used for the two LSPs is to use the same label space for the two. -- David From owner-mpls@UU.NET Tue Jul 10 12:33: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 MAA07440 for ; Tue, 10 Jul 2001 12:33: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 QQkxcc00243; Tue, 10 Jul 2001 16:31:57 GMT Received: by mail-control.mail.uu.net id QQkxcc26384 for mpls-outgoing; Tue, 10 Jul 2001 16:31: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 QQkxcc26282 for ; Tue, 10 Jul 2001 16:31: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 QQkxcc02914 for ; Tue, 10 Jul 2001 16:30:01 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 QQkxcb26010 for ; Tue, 10 Jul 2001 16:29:59 GMT Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6AGTgb09232 for ; Tue, 10 Jul 2001 12:29:42 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 10 Jul 2001 12:29:44 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ2YW8Y>; Tue, 10 Jul 2001 12:29:45 -0400 Message-ID: <6DDA62170439D31185750000F80826AC0692D03D@zmerd004.ca.nortel.com> From: "David Allan" To: Ping Pan Cc: mpls-list , mpls-ops Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Tue, 10 Jul 2001 12:29:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1095D.85911190" 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_01C1095D.85911190 Content-Type: text/plain; charset="iso-8859-1" Ping: I am specifically concerned that although this tool may be percieved as useful, it really has very limited applicability, it assumes a specific MPLS payload and a specific control plane. How many of these mechanisms do we wish to support before we finally have a comprehensive toolkit? IMHO It would be a whole lot more useful if we just tackled the problem in its entirety instead of via the incremental approach we have seen to date. One group of authors (Neil Harrison and company) has a requirements draft posted already, and we'll be bringing forward a framework to London that builds upon it (to be posted later this week), Perhaps we can start to put these problems to bed a bit more systematically.... cheers Dave ------_=_NextPart_001_01C1095D.85911190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

Ping:

I am specifically concerned that although this tool = may be percieved as useful, it really has very limited applicability, = it assumes a specific MPLS payload and a specific control plane. How = many of these mechanisms do we wish to support before we finally have a = comprehensive toolkit?

IMHO It would be a whole lot more useful if we just = tackled the problem in its entirety instead of via the incremental = approach we have seen to date.

One group of authors (Neil Harrison and company) has = a requirements draft posted already, and we'll be bringing forward a = framework to London that builds upon it (to be posted later this week), = Perhaps we can start to put these problems to bed a bit more = systematically....

cheers
Dave

------_=_NextPart_001_01C1095D.85911190-- From owner-mpls@UU.NET Tue Jul 10 13:18: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 NAA09602 for ; Tue, 10 Jul 2001 13:18: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 QQkxcf26438; Tue, 10 Jul 2001 17:17:53 GMT Received: by mail-control.mail.uu.net id QQkxcf22661 for mpls-outgoing; Tue, 10 Jul 2001 17:17: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 QQkxcf22647 for ; Tue, 10 Jul 2001 17:17: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 QQkxcf06402 for ; Tue, 10 Jul 2001 17:16:23 GMT Received: from satoru.prism by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ONIcc-06p29.ppp.odn.ad.jp [210.237.243.121]) id QQkxcf23640 for ; Tue, 10 Jul 2001 17:16:21 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.3/8.11.3) with ESMTP id f6AHE7n00651; Wed, 11 Jul 2001 02:14:08 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: pingpan@juniper.net Cc: ken.nagami@toshiba.co.jp, swallow@cisco.com, mpls@UU.NET, mpls-ops@mplsrc.com, nsheth@juniper.net, dcooper@gblx.net Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-Reply-To: <3B4B2080.B9BC992B@juniper.net> References: <3B4A61D5.2CD45413@juniper.net> <3B4B2080.B9BC992B@juniper.net> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010711021407M.satoru@japan-telecom.co.jp> Date: Wed, 11 Jul 2001 02:14:07 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 79 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: Ping Pan Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Tue, 10 Jul 2001 08:34:24 -0700 > Ken, > > LSP-ping is used to probe the data path. There are cases where the data > path goes wrong, and you have no idea where the problem is (forwarding > LSP, reverse LSP, ...). Since the only operational path that you can > count is the control path, so you reply via RSVP. > > If you use UDP to return the reply, what if the returning path is > broken? Should the user assumes the forwarding LSP is bad, or the > reverse? Ping, I can't understand why do you use RSVP msg for reply LSP-ping. It is only way to LSP using RSVP or other DoD/Orderd label distribution mode. Isn't it same thing that simply IP reachability from egress to ingress for other label distribution mode? (For example, DU/Independent label distribution) LSP is unidirectional path besically. Thus, I suppose LSP-ping reply scheme will be done by only have to simply IP reachability from egress to ingress. > > At the same time, if you can come up with a simple, scalable, backward > compatible method to use for LDP (including the case where you can label > merging) as well, please do let us know. :-) > > - Ping How about Section.4 in draft-satoru-mpls-1hop-lsp-00.txt? It can use not only "KeepAlive" purpose but also LSP-ping. > 4. The Possible to LSP "KeepAlive" using 1-hop LSP > > 4.1 Background > > This "LSP KeepAlive" ability is extremely important for the > applications which use LSP but cannot know the state of LSP itself > (for instance, consider the situation where BGP / MPLS VPNs are > used; they will recognise the network as "available" only if the > possibility of the IP accessibility to the PE exits, whatever the > state of the LSP). > > 4.2 Method of "LSP KeepAlive" process > > The "KeepAlive" of LSP is possible by the use of IP Packet > transmission to FEC from the ingress LER with the minimum IP TTL > (minimum value=1) through 1-hop LSP. This is because if there is a > cut within LSP then there will be no reply. > > In order to carry out "KeepAlive" of LSP, the expansion process is > also require for the core LSR such that IP TTL will not be replaced > by MPLS TTL, just like in the egress LER. This is because, if there > is a cut within LSP the core LSR will "pop" the label. This means > that the original core LSR will be made to act as an egress LER. > > The reply can be expected from the entire installed, if, such as > ICMP ECHO is used for setting of the IP Packet in this situation. > > The TTL does not have to, or more precisely, should not have a value > of 1 for reply. In case of TTL value on the reply message being 1, > it will go to the opposite side of LSP "KeepAlive" since the LSP is > a one-way path. This LSP "KeepAlive" cannot be "KeepAlive" for each > LSP. > > The TTL value on the LSP KeepAlive's reply message should have large > enough value. Also, if there is no route for the reply message to > return, it will look as though the healthy LSP does not exit. -- Satoru Matsushima From owner-mpls@UU.NET Tue Jul 10 13:29: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 NAA10127 for ; Tue, 10 Jul 2001 13:29: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 QQkxcf06079; Tue, 10 Jul 2001 17:29:14 GMT Received: by mail-control.mail.uu.net id QQkxcf25103 for mpls-outgoing; Tue, 10 Jul 2001 17:28: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 QQkxcf25089 for ; Tue, 10 Jul 2001 17:28: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 QQkxcf13148 for ; Tue, 10 Jul 2001 17:26:13 GMT Received: from satoru.prism by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ONIcc-06p32.ppp.odn.ad.jp [210.237.243.124]) id QQkxcf12793 for ; Tue, 10 Jul 2001 17:26:12 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.3/8.11.3) with ESMTP id f6AHODn00689; Wed, 11 Jul 2001 02:24:14 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: Shahram_Davari@pmc-sierra.com Cc: swadhwa01@yahoo.com, mpls@UU.NET Subject: RE: draft-pan-lsp-ping-00.txt In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D61@BBY1EXM01> References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D61@BBY1EXM01> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010711022413K.satoru@japan-telecom.co.jp> Date: Wed, 11 Jul 2001 02:24:13 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 67 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit That's in draft-satoru-mpls-1hop-lsp-00.txt Would you mind to read this draft? -- Satoru Matsushima From: Shahram Davari Subject: RE: draft-pan-lsp-ping-00.txt Date: Tue, 10 Jul 2001 09:07:35 -0700 > Hi Sanjay, > > Seems like a good solution. But the only problem is that the source won't find out why the LSP has connectivity problem, is it due to mis-routing or is it due to lower level failures. > > Yours, > -Shahram > > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > Sent: Tuesday, July 10, 2001 11:37 AM > > To: Shahram Davari; 'mpls@uu.net' > > Subject: Re: draft-pan-lsp-ping-00.txt > > > > > > The ingress could send this packet with IP ttl of 1 since the > > intention > > is to never ip forward this packet. The wrong egress in this > > case would > > drop it which is the desired behaviour. > > > > -Sanjay > > > > > > --- Shahram Davari wrote: > > > Hi, > > > > > > An observations/question: > > > > > > The draft says that the LSP ping packets are sent to the egress LSR > > > with UDP encapsulation. I assume the IP address of the Ping packets > > > are set to the IP address of the desired egress LSR. What happens if > > > a ping packet is delivered to an undesired egress LSR? From the MPLS > > > architecture point of view, it seems that the undesired egress LSR > > > will probably try to forward the Ping packet to the desired > > LSR using > > > the IP address in the Ping packet, which eventually could send > > > echo-reply back to source. Therefore although the LSP has a wrong > > > path the source will never find out. > > > > > > Yours, > > > Shahram Davari > > > > > > <> > > > > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram Davari.vcf > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail > > http://personal.mail.yahoo.com/ > > > > From owner-mpls@UU.NET Tue Jul 10 13:41: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 NAA10837 for ; Tue, 10 Jul 2001 13:41: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 QQkxcg29070; Tue, 10 Jul 2001 17:41:07 GMT Received: by mail-control.mail.uu.net id QQkxcg26269 for mpls-outgoing; Tue, 10 Jul 2001 17:40:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxcg26263 for ; Tue, 10 Jul 2001 17:40: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 QQkxcg01680 for ; Tue, 10 Jul 2001 17:36:08 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxcg09545 for ; Tue, 10 Jul 2001 17:36:04 GMT Message-ID: <3B4B3CFE.87CF1F1C@sandburst.com> Date: Tue, 10 Jul 2001 13:35:58 -0400 From: Eric Gray MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> <3B4B2CC2.EA2243A7@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, The current wording in RFC 3031 implies more than that you shouldn't give the same label out to two different peers (with distinct semantics) when you will be popping the top label off. The current wording means you shouldn't give the same label out with two different meanings where one applies to packets received with a pop-and-look-again upper label and the other applies when it is received as the first label. This latter implication is a little too restrictive - especially in light of subsequent work on LSP tunnels and forwarding adjacencies. However, it may have been meant to provide correct LSR behavior in a particularly pathological case. That case would be when a PHop LSR (far from being cooperative in the usual PHP way) actually maliciously inserts an extra label in forwarding a labeled packet to the NHop LSR. It would happen like this: PHop swaps an existing label for the label given by the downstream LSR for the LSP in question, PHop pushes on a label for an LSP that terminates at NHop and PHop forwards the now stacked labeled packet to the NHop LSR. This is pathological because the PHop LSR is inserting a label that does not add value and does add work for NHop. Moreover, this behavior will make it impossible for NHop to distinguish locally distributed labels from remotely distributed labels. But this behavior is also obviously malicious and should result in an implementer being placed in Coventry for a very long time (at least until overcome by bankruptcy). Barring this bizarre behavior, it will always be possible to distinguish remotely distributed labels received on a non-PHP LSP from locally distributed labels. Even with this bizarre behavior, it is possible to distinguish labels received on LSP tunnels from labels received in the raw or on a plain LSP. -- Eric Gray You wrote: > Shahram Davari wrote: > > > > You are partially right. Only when those labels are distributed by > > the same LSR must be unique across different levels. For example > > assume this architecture: > > > > > > B-----C--------E-------F > > A-------B----------------------F-------G > > > > LSP1: ABFG > > LSP2: BCEF > > > > Assume LSR F distributes label L1 to B for LSP1, and label L2 to E > > for LSP2. Since LSR E has is not allowed and does not need to look > > at the lower label belonging to LSP1, it can distribute an identical > > label L1 to C for LSP2. So in the cross section from C->E the packet > > may have 2 labels both being L1. > > No argument here. But I dont't think this is the really important > issue. It is obvious that E might send a label mapping identical to > what's used in the outer LSP. After all, E has no knowledge of that > outer LSP. It would be unreasonable to expect a router to remain in > sync with routers that it is not sharing signaling information with. > > A more important question is what happens at router F. > > Router F must not send the same label to E and to B. When a packet > arrives from E, the outer label will indicate a pop. Then the remaining > label will indicate a swap. (Let's pretend there are more routers > beyond G, so PHP won't come into play here.) > > If the two labels are identical, then the forwarding engine in F won't > be able to apply different semantics to them. It should not use the > size of the label stack as a way of differentiating, because the outer > label (sent from F to E) may appear without a stack underneath it. (eg. > for traffic that originates from B and terminates at F). > > This is what the RFC is talking about. The only way for F to determine > whether a packet is from LSP1 or LSP2 is using the label. If the label > values for the two are identical, then some other means, beyond the > scope of MPLS, must be used to determine the LSP that the packet belongs > to. The easiest way to ensure that the same label is not used for the > two LSPs is to use the same label space for the two. > > -- David From owner-mpls@UU.NET Tue Jul 10 13:50: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 NAA11244 for ; Tue, 10 Jul 2001 13:50: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 QQkxch17152; Tue, 10 Jul 2001 17:50:03 GMT Received: by mail-control.mail.uu.net id QQkxch29089 for mpls-outgoing; Tue, 10 Jul 2001 17:48:29 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 QQkxch29035 for ; Tue, 10 Jul 2001 17:48:17 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 QQkxch04576 for ; Tue, 10 Jul 2001 17:46:05 GMT Received: from smtp1.phx.gblx.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQkxch21105 for ; Tue, 10 Jul 2001 17:46:04 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id f6AHjJQ23842; Tue, 10 Jul 2001 10:45:19 -0700 (MST) Received: from UNKNOWN(64.208.25.102), claiming to be "davevaio" via SMTP by smtp1, id smtpdAAAeFaWIU; Tue Jul 10 10:45:12 2001 From: "Dave Cooper" To: "David Allan" , "Ping Pan" Cc: "mpls-list" , "mpls-ops" Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Tue, 10 Jul 2001 10:43:30 -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: <6DDA62170439D31185750000F80826AC0692D03D@zmerd004.ca.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, I think its up to the operators to ascertain usefulness and applicability. We were motivated to submit this draft because of the urgency in detecting LSP integrity in MPLS TE networks. No, it doesnt address all of the requirements outlined in the OAM draft. But it attempts to address one of the most significant issues we face in today's MPLS networks. Our goal is to keep it as simple as possible but accomplish this objective. Thanks, Dave -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Allan Sent: Tuesday, July 10, 2001 9:30 AM To: Ping Pan Cc: mpls-list; mpls-ops Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Ping: I am specifically concerned that although this tool may be percieved as useful, it really has very limited applicability, it assumes a specific MPLS payload and a specific control plane. How many of these mechanisms do we wish to support before we finally have a comprehensive toolkit? IMHO It would be a whole lot more useful if we just tackled the problem in its entirety instead of via the incremental approach we have seen to date. One group of authors (Neil Harrison and company) has a requirements draft posted already, and we'll be bringing forward a framework to London that builds upon it (to be posted later this week), Perhaps we can start to put these problems to bed a bit more systematically.... cheers Dave From owner-mpls@UU.NET Tue Jul 10 13:51: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 NAA11337 for ; Tue, 10 Jul 2001 13:51: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 QQkxch01451; Tue, 10 Jul 2001 17:51:27 GMT Received: by mail-control.mail.uu.net id QQkxch29215 for mpls-outgoing; Tue, 10 Jul 2001 17:48: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 QQkxch29109 for ; Tue, 10 Jul 2001 17:48: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 QQkxcg28175 for ; Tue, 10 Jul 2001 17:44:45 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 QQkxcg18695 for ; Tue, 10 Jul 2001 17:44: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 NAA03886 for ; Tue, 10 Jul 2001 13:44:41 -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 NAA21127 for ; Tue, 10 Jul 2001 13:44:43 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 13:44:41 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5554C5CF@VIE-MSGUSR-01> From: "Naidu, Venkata" To: "Charlap, David" , mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 13:44:40 -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 David, Shahram, Eric: Please look at my inline comments: -> Shahram Davari wrote: -> > -> > -> > B-----C--------E-------F -> > A-------B----------------------F-------G -> > -> > LSP1: ABFG -> > LSP2: BCEF -> > -> A more important question is what happens at router F. -> -> Router F must not send the same label to E and to B. When a packet -> arrives from E, the outer label will indicate a pop. Then -> the remaining -> label will indicate a swap. (Let's pretend there are more routers -> beyond G, so PHP won't come into play here.) Why not? As long as I use labels from different label space. And I think this is a very importance feature in Fast-Reroute in LSP protection. LSP1: ABFG uses labels from global label space, so, even after reroute of LSP2 (because of some failure) F receives data in that on a different interface and can interpret data correctly because the inner label is from global label space. LSP2: BCEF uses per interface label space. As far as I know both of these label spaces can coincide and more over F can allocate the "same" local significance label to B as well as to E. (as long as it distinguishes which LSP the data is flowing) Is this possible. If not why not? -> This is what the RFC is talking about. The only way for F -> to determine -> whether a packet is from LSP1 or LSP2 is using the label. And of course the receive interface too!!! -> If the label -> values for the two are identical, then some other means, beyond the -> scope of MPLS, must be used to determine the LSP that the -> packet belongs -> to. The easiest way to ensure that the same label is not -> used for the -> two LSPs is to use the same label space for the two. --Venkata Naidu From owner-mpls@UU.NET Tue Jul 10 13:55: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 SMTP id NAA11530 for ; Tue, 10 Jul 2001 13:55:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxch27860; Tue, 10 Jul 2001 17:55:48 GMT Received: by mail-control.mail.uu.net id QQkxch00247 for mpls-outgoing; Tue, 10 Jul 2001 17:55: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 QQkxch00196 for ; Tue, 10 Jul 2001 17:54: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 QQkxch25193 for ; Tue, 10 Jul 2001 17:54:04 GMT Received: from squid.squirehome.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu163-42-132.nc.rr.com [24.163.42.132]) id QQkxch17928 for ; Tue, 10 Jul 2001 17:54:03 GMT Received: from acm.org (sc-f100-01.extremenetworks.com [63.251.106.30]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6AHrwt01222; Tue, 10 Jul 2001 13:54:00 -0400 Message-ID: <3B4B412D.8B6211B3@acm.org> Date: Tue, 10 Jul 2001 13:53:49 -0400 From: Matt Squire X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> <3B4B2CC2.EA2243A7@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > A more important question is what happens at router F. > > Router F must not send the same label to E and to B. When a packet > arrives from E, the outer label will indicate a pop. Then the remaining > label will indicate a swap. (Let's pretend there are more routers > beyond G, so PHP won't come into play here.) > > If the two labels are identical, then the forwarding engine in F won't > be able to apply different semantics to them. It should not use the > size of the label stack as a way of differentiating, because the outer > label (sent from F to E) may appear without a stack underneath it. (eg. > for traffic that originates from B and terminates at F). > > This is what the RFC is talking about. The only way for F to determine > whether a packet is from LSP1 or LSP2 is using the label. If the label > values for the two are identical, then some other means, beyond the > scope of MPLS, must be used to determine the LSP that the packet belongs > to. The easiest way to ensure that the same label is not used for the > two LSPs is to use the same label space for the two. > But there are many potential ways for F to distinguish the context of a packet and hence the label space. It could look at the port or VC or, as Eric mentioned, it can view an LSP as a port and have a label space for that port/LSP. When a packet arrives the LSR has to determine the context, ie label space, and view the packet in that context. As long as the LSR can do that, it can have any insane internal label assignment methodolgy that it wants. There are oodles of possibilities, most of them impractical but interoperable. I agree with the original text that says the level is not important. Its not important, at least not directly. However, as pointed out by Eric's earlier note, it could have indirect importance by reflecting a different context in which to interpret the label. - Matt From owner-mpls@UU.NET Tue Jul 10 14:08: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 OAA12459 for ; Tue, 10 Jul 2001 14:08: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 QQkxci03410; Tue, 10 Jul 2001 18:08:58 GMT Received: by mail-control.mail.uu.net id QQkxci13981 for mpls-outgoing; Tue, 10 Jul 2001 18:08: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 QQkxci13514 for ; Tue, 10 Jul 2001 18:08: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 QQkxci17841 for ; Tue, 10 Jul 2001 18:04:20 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 QQkxci13592 for ; Tue, 10 Jul 2001 18:04:20 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 OAA05881 for ; Tue, 10 Jul 2001 14:04:17 -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 OAA26516 for ; Tue, 10 Jul 2001 14:04:19 -0400 (EDT) Message-ID: <3B4B438E.70377A5D@marconi.com> Date: Tue, 10 Jul 2001 14:03: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: Label Spaces and Uniqueness References: <39469E08BD83D411A3D900204840EC5554C5CF@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 "Naidu, Venkata" wrote: > David, Shahram, Eric: > > Please look at my inline comments: > >> Shahram Davari wrote: >>> >>> >>> B-----C--------E-------F >>> A-------B----------------------F-------G >>> >>> LSP1: ABFG >>> LSP2: BCEF >> >> A more important question is what happens at router F. >> >> Router F must not send the same label to E and to B. When a packet >> arrives from E, the outer label will indicate a pop. Then the >> remaining label will indicate a swap. (Let's pretend there are >> more routers beyond G, so PHP won't come into play here.) > > Why not? As long as I use labels from different label space. > And I think this is a very importance feature in Fast-Reroute > in LSP protection. > > LSP1: ABFG uses labels from global label space, so, even > after reroute of LSP2 (because of some failure) F receives > data in that on a different interface and can interpret > data correctly because the inner label is from global > label space. > > LSP2: BCEF uses per interface label space. As far as I know > both of these label spaces can coincide and more over > F can allocate the "same" local significance label to B as > well as to E. (as long as it distinguishes which LSP the > data is flowing) > > Is this possible. If not why not? When the labeled packet arrives, how will you be able to determine which label space to use? This isn't part of any header. All you've got is a label stack and the opaque payload. If you can determine the label space, then sure, go right ahead. But I think the only factors that you can use are either layer-2 information or physical port information. >> This is what the RFC is talking about. The only way for F >> to determine whether a packet is from LSP1 or LSP2 is using the >> label. > > And of course the receive interface too!!! In the above example, F only has one interface - connected to E. The line from B-F is not a separate link. It is representing a tunnel through LSP2. -- David From owner-mpls@UU.NET Tue Jul 10 14:11: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 OAA12611 for ; Tue, 10 Jul 2001 14:11: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 QQkxci01765; Tue, 10 Jul 2001 18:12:11 GMT Received: by mail-control.mail.uu.net id QQkxci20244 for mpls-outgoing; Tue, 10 Jul 2001 18:11: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 QQkxci19600 for ; Tue, 10 Jul 2001 18:11: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 QQkxci00553 for ; Tue, 10 Jul 2001 18:09:34 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 QQkxci26261 for ; Tue, 10 Jul 2001 18:09:34 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 OAA06368 for ; Tue, 10 Jul 2001 14:09:32 -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 OAA28691 for ; Tue, 10 Jul 2001 14:09:34 -0400 (EDT) Message-ID: <3B4B44C8.7A1D0528@marconi.com> Date: Tue, 10 Jul 2001 14:09:12 -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: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> <3B4B2CC2.EA2243A7@marconi.com> <3B4B412D.8B6211B3@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Matt Squire wrote: > > But there are many potential ways for F to distinguish the context > of a packet and hence the label space. It could look at the port or > VC or, as Eric mentioned, it can view an LSP as a port and have a > label space for that port/LSP. Port? If you mean physical interface, yes. It's always possible to determine label space based on that. If you're talking about TCP/UDP port, then no - an MPLS forwarder should not use the payload as the basis for any forwarding decisions. VC? With most MPLS-over-ATM implementations, the VC is the top label. If you are talking about Juniper's implementation - using shim headers to multiplex all LSPs into a single VC, then there's no issue. Each VC is equivalent to a separate physical interface. As for the LSP, you've just created a circular definition. The LSP is determined by the label. But you also want to compute the meaning of that label from the LSP. > When a packet arrives the LSR has to determine the context, ie label > space, and view the packet in that context. As long as the LSR can > do that, it can have any insane internal label assignment methodolgy > that it wants. There are oodles of possibilities, most of them > impractical but interoperable. Sure. But aside from physical port information or L2 information, the only other way to determine the LSP is by looking at the top label. -- David From owner-mpls@UU.NET Tue Jul 10 14:33: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 SMTP id OAA13746 for ; Tue, 10 Jul 2001 14:33:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxck22254; Tue, 10 Jul 2001 18:33:21 GMT Received: by mail-control.mail.uu.net id QQkxck25181 for mpls-outgoing; Tue, 10 Jul 2001 18:32: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 QQkxck25164 for ; Tue, 10 Jul 2001 18:32: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 QQkxck14305 for ; Tue, 10 Jul 2001 18:31:54 GMT Received: from uniwest1.redstonecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.194.140.130]) id QQkxck19771 for ; Tue, 10 Jul 2001 18:31:53 GMT Received: by UNIWEST1 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 14:31:48 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C0210F5CE@UNIWEST1> From: "Shekhar, Ravi" To: "'David Charlap'" , mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 14:31:39 -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 > >>> > >>> B-----C--------E-------F > >>> A-------B----------------------F-------G > >>> > >>> LSP1: ABFG > >>> LSP2: BCEF > >> > >> A more important question is what happens at router F. > >> > >> Router F must not send the same label to E and to B. When a packet > >> arrives from E, the outer label will indicate a pop. Then the > >> remaining label will indicate a swap. (Let's pretend there are > >> more routers beyond G, so PHP won't come into play here.) > > > > Why not? As long as I use labels from different label space. > > And I think this is a very importance feature in Fast-Reroute > > in LSP protection. > > > > LSP1: ABFG uses labels from global label space, so, even > > after reroute of LSP2 (because of some failure) F receives > > data in that on a different interface and can interpret > > data correctly because the inner label is from global > > label space. > > > > LSP2: BCEF uses per interface label space. As far as I know > > both of these label spaces can coincide and more over > > F can allocate the "same" local significance label to B as > > well as to E. (as long as it distinguishes which LSP the > > data is flowing) > > > > Is this possible. If not why not? > > When the labeled packet arrives, how will you be able to > determine which > label space to use? This isn't part of any header. All A packet from B traversing LSP1 cannot arrive at F natively since they are remote peers. It has to arrive encapsulated and it so happens here that encapsulation is the outer label (of LSP2). So, in this scenario, the outermost label cannot have the same context as the one used for distributing label to B by F and its safe to assume that the only context outer-most label has is the one used for distributing label to E by F. > you've got is a > label stack and the opaque payload. > > If you can determine the label space, then sure, go right > ahead. But I > think the only factors that you can use are either layer-2 information > or physical port information. Or the fact that the router (F here) has already looked at the outer label (which defines a tunneled interface in a sense) and so its time to switch the label space to one which was used while distributing label to B for this tunneled interface. In short, treat outermost label as a tunneled interface (layer 2.5 !!). - Ravi Shekhar. From owner-mpls@UU.NET Tue Jul 10 14:44: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 OAA14127 for ; Tue, 10 Jul 2001 14:44: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 QQkxck01350; Tue, 10 Jul 2001 18:44:50 GMT Received: by mail-control.mail.uu.net id QQkxck27440 for mpls-outgoing; Tue, 10 Jul 2001 18:44: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 QQkxck27426 for ; Tue, 10 Jul 2001 18:44:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxck00505 for ; Tue, 10 Jul 2001 18:43:53 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxck10039 for ; Tue, 10 Jul 2001 18:43:53 GMT Message-ID: <3B4B4CE2.64AA680@sandburst.com> Date: Tue, 10 Jul 2001 14:43:46 -0400 From: Eric Gray MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> <3B4B2CC2.EA2243A7@marconi.com> <3B4B412D.8B6211B3@acm.org> <3B4B44C8.7A1D0528@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, Welcome back to the continuing saga of 'word wars'. Matt almost certainly was talking about 'logical port' and the word 'VC' has meaning outside of ATM. The point is that it is possible to treat each layer of 'encapsulation' that is removed at a network device as establishing a logical context for use in interpreting the next layer of 'encapsulation'. 'Encapsulation' can easily be seen to apply to each layer of an MPLS stack that is removed at a single network device. In this sense, I know of no real-world physical reason why the same thing you say about the physical interface would not also apply to logical interfaces - particularly since, by the time you get to it, a packet processing device may be completely unable to distinguish the two concepts. -- Eric Gray You wrote: > Matt Squire wrote: > > > > But there are many potential ways for F to distinguish the context > > of a packet and hence the label space. It could look at the port or > > VC or, as Eric mentioned, it can view an LSP as a port and have a > > label space for that port/LSP. > > Port? If you mean physical interface, yes. It's always possible to > determine label space based on that. If you're talking about TCP/UDP > port, then no - an MPLS forwarder should not use the payload as the > basis for any forwarding decisions. > > VC? With most MPLS-over-ATM implementations, the VC is the top label. > > If you are talking about Juniper's implementation - using shim headers > to multiplex all LSPs into a single VC, then there's no issue. Each VC > is equivalent to a separate physical interface. > > As for the LSP, you've just created a circular definition. The LSP is > determined by the label. But you also want to compute the meaning of > that label from the LSP. > > > When a packet arrives the LSR has to determine the context, ie label > > space, and view the packet in that context. As long as the LSR can > > do that, it can have any insane internal label assignment methodolgy > > that it wants. There are oodles of possibilities, most of them > > impractical but interoperable. > > Sure. But aside from physical port information or L2 information, the > only other way to determine the LSP is by looking at the top label. > > -- David From owner-mpls@UU.NET Tue Jul 10 14:53: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 SMTP id OAA14641 for ; Tue, 10 Jul 2001 14:53: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 QQkxcl03726; Tue, 10 Jul 2001 18:53:35 GMT Received: by mail-control.mail.uu.net id QQkxcl29290 for mpls-outgoing; Tue, 10 Jul 2001 18:53:03 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 QQkxcl29262 for ; Tue, 10 Jul 2001 18:52:46 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 QQkxcl16455 for ; Tue, 10 Jul 2001 18:52:37 GMT Received: from ureach.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxcl16993 for ; Tue, 10 Jul 2001 18:52:36 GMT Received: from www22.ureach.com (IDENT:root@www22.ureach.com [172.16.2.50]) by ureach.com (8.9.1/8.8.5) with ESMTP id OAA06862; Tue, 10 Jul 2001 14:38:43 -0400 Received: (from nobody@localhost) by www22.ureach.com (8.9.3/8.9.1) id OAA07603; Tue, 10 Jul 2001 14:39:26 -0400 Date: Tue, 10 Jul 2001 14:39:26 -0400 Message-Id: <200107101839.OAA07603@www22.ureach.com> To: eric.gray@sandburst.com, mpls@UU.NET, "David Charlap" From: Anouk Rocher Reply-to: Subject: Re: Re: Label Spaces and Uniqueness Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Let me clarify with a more specific example. Lets say we want to deploy one of the l2 vpn mechanisms - say the one in draft-maritini-* The inner label there is negotiated between the ingress and egress LSRs via LDP (sort of multi-hop). The inner label is negotiated (say) via RSVP-TE. I don't see a reason why LDP and RSVP-TE be forced to use the same label space in this case. (I am sure there are similar cases while using wavelengths as labels.) Am I missing something obvious? Anouk. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Tue, 10 Jul 2001, David Charlap (david.charlap@marconi.com) wrote: > Anouk Rocher wrote: > > > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > > > "In MPLS, there is no notion of > > having a different label space for different levels of the > > hierarchy; when interpreting a label, the level of the label is > > irrelevant." > > > > Does this mean that while doing label stacking, it is neccessary to > > allocate labels from a single label space? > > Yes. > > > Isn't this a bit too restrictive for the cases where the inner > > label represents customer traffic transiting a provider and the > > outer label represents a path through the provider? > > What's your alternative? When a data packet arrives, how are you going > to know what label space the top label should belong to? > > -- David > > From owner-mpls@UU.NET Tue Jul 10 15:28: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 SMTP id PAA16528 for ; Tue, 10 Jul 2001 15:28: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 QQkxcn17391; Tue, 10 Jul 2001 19:26:32 GMT Received: by mail-control.mail.uu.net id QQkxcn24519 for mpls-outgoing; Tue, 10 Jul 2001 19:25: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 QQkxcn24507 for ; Tue, 10 Jul 2001 19:25: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 QQkxcn03696 for ; Tue, 10 Jul 2001 19:23:46 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxcn01318 for ; Tue, 10 Jul 2001 19:23:46 GMT Message-ID: <3B4B5641.2BF1F5DF@sandburst.com> Date: Tue, 10 Jul 2001 15:23:45 -0400 From: Eric Gray MIME-Version: 1.0 To: anouk@ureach.com Cc: mpls@UU.NET, David Charlap Subject: Re: Label Spaces and Uniqueness References: <200107101839.OAA07603@www22.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk, I assume that David can answer for himself, however I would like to get some things clarified. Please see comments/questions below. Anouk Rocher wrote: > David, > > Let me clarify with a more specific example. Lets say we want > to deploy one of the l2 vpn mechanisms - say the one in draft-maritini-* > The inner label there is negotiated between the ingress and egress > LSRs via LDP (sort of multi-hop). The inner label is negotiated (say) > via RSVP-TE. I believe one of these should be 'outer label'. I assume you mean higher level, when you say 'outer' and lower level when you say 'inner' but, even so, I am not sure which should be which in your description above (just that they cannot both be the same). Would you recast your question somehow distinguishing which is which? > > > I don't see a reason why LDP and RSVP-TE be forced to use the same > label space in this case. (I am sure there are similar cases while > using wavelengths as labels.) > > Am I missing something obvious? So, one reason would be if PHP is used. In this case, the egress for the lower level label will not have received the higher level label and will not be able to distinguish it from other labels it receives from the penultimate hop. Give that this is the case, then the egress LSR must not distribute a label to be used by the remote LSR at the other end of the LSP tunnel with a different meaning then an identical label distributed to the local LSR that happens to be the punultimate hop for the LSP tunnel. This is an example of when the label space MUST be the same. Does this answer your question? > > > Anouk. > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > > ---- On Tue, 10 Jul 2001, David Charlap (david.charlap@marconi.com) wrote: > > > Anouk Rocher wrote: > > > > > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > > > > > "In MPLS, there is no notion of > > > having a different label space for different levels of the > > > hierarchy; when interpreting a label, the level of the label is > > > irrelevant." > > > > > > Does this mean that while doing label stacking, it is neccessary to > > > allocate labels from a single label space? > > > > Yes. > > > > > Isn't this a bit too restrictive for the cases where the inner > > > label represents customer traffic transiting a provider and the > > > outer label represents a path through the provider? > > > > What's your alternative? When a data packet arrives, how are you going > > to know what label space the top label should belong to? > > > > -- David > > > > From owner-mpls@UU.NET Tue Jul 10 15:39: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 PAA17134 for ; Tue, 10 Jul 2001 15:39: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 QQkxco16864; Tue, 10 Jul 2001 19:39:29 GMT Received: by mail-control.mail.uu.net id QQkxco26729 for mpls-outgoing; Tue, 10 Jul 2001 19:38:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxco26720 for ; Tue, 10 Jul 2001 19:38:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxco14861 for ; Tue, 10 Jul 2001 19:38:39 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 QQkxco11385 for ; Tue, 10 Jul 2001 19:38:39 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 PAA16004 for ; Tue, 10 Jul 2001 15:38:36 -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 PAA28605 for ; Tue, 10 Jul 2001 15:38:39 -0400 (EDT) Message-ID: <3B4B59AA.3F962E80@marconi.com> Date: Tue, 10 Jul 2001 15:38:18 -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: Label Spaces and Uniqueness References: <200107101839.OAA07603@www22.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk Rocher wrote: > > Let me clarify with a more specific example. Lets say we want > to deploy one of the l2 vpn mechanisms - say the one in > draft-maritini-* The inner label there is negotiated between the > ingress and egress LSRs via LDP (sort of multi-hop). The inner label > is negotiated (say) via RSVP-TE. > > I don't see a reason why LDP and RSVP-TE be forced to use the same > label space in this case. (I am sure there are similar cases while > using wavelengths as labels.) As Eric just wrote, one example is if the inner LSP is using PHP. In which case, the egress router will always get a single lable. It will have no way of knowing if that label was originally part of a stack or if it was always a standalone label. In which case, a single label space must be used, to guarantee that the inner and outer labels have different values. -- David From owner-mpls@UU.NET Tue Jul 10 15:43: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 SMTP id PAA17456 for ; Tue, 10 Jul 2001 15:43: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 QQkxco13676; Tue, 10 Jul 2001 19:43:25 GMT Received: by mail-control.mail.uu.net id QQkxco27397 for mpls-outgoing; Tue, 10 Jul 2001 19:42: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 QQkxco27262 for ; Tue, 10 Jul 2001 19:42:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxco18257 for ; Tue, 10 Jul 2001 19:39:08 GMT Received: from web11402.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11402.mail.yahoo.com [216.136.131.232]) id QQkxco12182 for ; Tue, 10 Jul 2001 19:39:08 GMT Message-ID: <20010710193907.7037.qmail@web11402.mail.yahoo.com> Received: from [65.194.140.2] by web11402.mail.yahoo.com via HTTP; Tue, 10 Jul 2001 12:39:07 PDT Date: Tue, 10 Jul 2001 12:39:07 -0700 (PDT) From: Sanjay Wadhwa Subject: RE: draft-pan-lsp-ping-00.txt To: Shahram Davari , "'mpls@uu.net'" In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D61@BBY1EXM01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram I am not sure I understand your concern. Maybe I missed your point. Since the rsvp control path (which is used for response) is alive i.e. RESV w/o LSP_ECHO are being received fine (after sending the echo request) by the ingress, but is not getting echo response in the RESV, ingress can conclude that the lsp data plane is broken, which is what I think the scheme is trying to achieve. The end result in this case would be to consider the LSP as down. However, if the wrong egress does ip forward the packet (u'r original concern), the ingress has no way to figure that LSP data plane is broken. -Sanjay --- Shahram Davari wrote: > Hi Sanjay, > > Seems like a good solution. But the only problem is that the source > won't find out why the LSP has connectivity problem, is it due to > mis-routing or is it due to lower level failures. > > Yours, > -Shahram > > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > Sent: Tuesday, July 10, 2001 11:37 AM > > To: Shahram Davari; 'mpls@uu.net' > > Subject: Re: draft-pan-lsp-ping-00.txt > > > > > > The ingress could send this packet with IP ttl of 1 since the > > intention > > is to never ip forward this packet. The wrong egress in this > > case would > > drop it which is the desired behaviour. > > > > -Sanjay > > > > > > --- Shahram Davari wrote: > > > Hi, > > > > > > An observations/question: > > > > > > The draft says that the LSP ping packets are sent to the egress > LSR > > > with UDP encapsulation. I assume the IP address of the Ping > packets > > > are set to the IP address of the desired egress LSR. What happens > if > > > a ping packet is delivered to an undesired egress LSR? From the > MPLS > > > architecture point of view, it seems that the undesired egress > LSR > > > will probably try to forward the Ping packet to the desired > > LSR using > > > the IP address in the Ping packet, which eventually could send > > > echo-reply back to source. Therefore although the LSP has a wrong > > > path the source will never find out. > > > > > > Yours, > > > Shahram Davari > > > > > > <> > > > > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram > Davari.vcf > > > > > > > > __________________________________________________ > > 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 Tue Jul 10 15:45: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 PAA17671 for ; Tue, 10 Jul 2001 15:45: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 QQkxcp23154; Tue, 10 Jul 2001 19:45:32 GMT Received: by mail-control.mail.uu.net id QQkxco27551 for mpls-outgoing; Tue, 10 Jul 2001 19:44: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 QQkxco27488 for ; Tue, 10 Jul 2001 19:43:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxco19733 for ; Tue, 10 Jul 2001 19:42:07 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 QQkxco24079 for ; Tue, 10 Jul 2001 19:42:06 GMT Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6AJfnb07272 for ; Tue, 10 Jul 2001 15:41:49 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 10 Jul 2001 15:41:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ2Y7N1>; Tue, 10 Jul 2001 15:41:49 -0400 Message-ID: From: "Don Fedyk" To: Eric Gray , anouk@ureach.com, David Charlap Cc: mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 15:41:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10978.4D1EE380" 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_01C10978.4D1EE380 Content-Type: text/plain; charset="iso-8859-1" Hi So what I think I heard is either: Standard says: All labels from the same space. No problems. But in practice I thought VPNs used: Assume per/interface outer labels, the next inner stacked label from per node space. PHP to be avoided adjacent to boxes doing this. In the end it is a local decision of the box. No other box cares what algorithm the allocating box is using. So should the standard be updated? Don ------_=_NextPart_001_01C10978.4D1EE380 Content-Type: text/html; charset="iso-8859-1" RE: Label Spaces and Uniqueness

Hi

So what I think I heard is either:

Standard says: All labels from the same space. No problems.

But in practice I thought VPNs used:

Assume per/interface outer labels, the next inner stacked label
from per node space. PHP to be avoided adjacent to boxes doing this.

In the end it is a local decision of the box. No other box
cares what algorithm the allocating box is using.

So should the standard be updated?

Don







------_=_NextPart_001_01C10978.4D1EE380-- From owner-mpls@UU.NET Tue Jul 10 15:53: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 PAA18729 for ; Tue, 10 Jul 2001 15:53: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 QQkxcp04060; Tue, 10 Jul 2001 19:54:02 GMT Received: by mail-control.mail.uu.net id QQkxcp29059 for mpls-outgoing; Tue, 10 Jul 2001 19:53:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxcp29047 for ; Tue, 10 Jul 2001 19:53:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxcp18662 for ; Tue, 10 Jul 2001 19:50: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 QQkxcp02746 for ; Tue, 10 Jul 2001 19:50:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA08186 for mpls@uu.net; Tue, 10 Jul 2001 15:50: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 QQkxcp28582 for ; Tue, 10 Jul 2001 19:49:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxcp15182 for ; Tue, 10 Jul 2001 19:48:42 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 QQkxcp23284 for ; Tue, 10 Jul 2001 19:48:41 GMT Received: (qmail 2807 invoked by uid 104); 10 Jul 2001 19:48:41 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.796123 secs); 10/07/2001 12:48:40 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 19:48:39 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AJmeP01476; Tue, 10 Jul 2001 12:48:40 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 12:53:48 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D65@BBY1EXM01> From: Shahram Davari To: "'Don Fedyk'" , Eric Gray , anouk@ureach.com, David Charlap Cc: mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 12:53:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1097A.08D28900" 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_01C1097A.08D28900 Content-Type: text/plain; charset="iso-8859-1" Hi, Also, who needs more than 1 million labels per interface? -Shahram -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com] Sent: Tuesday, July 10, 2001 3:41 PM To: Eric Gray; anouk@ureach.com; David Charlap Cc: mpls@UU.NET Subject: RE: Label Spaces and Uniqueness Hi So what I think I heard is either: Standard says: All labels from the same space. No problems. But in practice I thought VPNs used: Assume per/interface outer labels, the next inner stacked label from per node space. PHP to be avoided adjacent to boxes doing this. In the end it is a local decision of the box. No other box cares what algorithm the allocating box is using. So should the standard be updated? Don ------_=_NextPart_001_01C1097A.08D28900 Content-Type: text/html; charset="iso-8859-1" RE: Label Spaces and Uniqueness
Hi,
 
Also, who needs more than 1 million labels per interface?
 
-Shahram
-----Original Message-----
From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com]
Sent: Tuesday, July 10, 2001 3:41 PM
To: Eric Gray; anouk@ureach.com; David Charlap
Cc: mpls@UU.NET
Subject: RE: Label Spaces and Uniqueness

Hi

So what I think I heard is either:

Standard says: All labels from the same space. No problems.

But in practice I thought VPNs used:

Assume per/interface outer labels, the next inner stacked label
from per node space. PHP to be avoided adjacent to boxes doing this.

In the end it is a local decision of the box. No other box
cares what algorithm the allocating box is using.

So should the standard be updated?

Don







------_=_NextPart_001_01C1097A.08D28900-- From owner-mpls@UU.NET Tue Jul 10 15:56: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 PAA19122 for ; Tue, 10 Jul 2001 15:56: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 QQkxcp26390; Tue, 10 Jul 2001 19:56:37 GMT Received: by mail-control.mail.uu.net id QQkxcp29452 for mpls-outgoing; Tue, 10 Jul 2001 19:56: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 QQkxcp29445 for ; Tue, 10 Jul 2001 19:55:53 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 QQkxcp27499 for ; Tue, 10 Jul 2001 19:48:31 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 QQkxcp29553 for ; Tue, 10 Jul 2001 19:48:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA07909 for mpls@uu.net; Tue, 10 Jul 2001 15:48:30 -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 QQkxcp28257 for ; Tue, 10 Jul 2001 19:47: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 QQkxcp24719 for ; Tue, 10 Jul 2001 19:46:18 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 QQkxcp24948 for ; Tue, 10 Jul 2001 19:46:17 GMT Received: (qmail 2422 invoked by uid 104); 10 Jul 2001 19:46:17 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.416085 secs); 10/07/2001 12:46:16 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 19:46:16 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AJkHP00482; Tue, 10 Jul 2001 12:46:17 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 12:51:25 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D64@BBY1EXM01> From: Shahram Davari To: "'Sanjay Wadhwa'" , "'mpls@uu.net'" Subject: RE: draft-pan-lsp-ping-00.txt Date: Tue, 10 Jul 2001 12:51:25 -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 Sanjay, > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > Sent: Tuesday, July 10, 2001 3:39 PM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: draft-pan-lsp-ping-00.txt > > > Hi Shahram > I am not sure I understand your concern. Maybe I missed your point. > Since the rsvp control path (which is used for response) is alive i.e. > RESV w/o LSP_ECHO are being received fine (after sending the echo > request) by the ingress, but is not getting echo response in the RESV, > ingress can conclude that the lsp data plane is broken, which > is what I > think the scheme is trying to achieve. The end result in this case > would be to consider the LSP as down. This is correct. But for diagnostic purpose you want to know why the LSP is down. Is it because there was an error in one of the switching tables in its path, or because for example a fiber was broken. -Shahram > However, if the wrong egress does ip forward the packet (u'r original > concern), the ingress has no way to figure that LSP data plane is > broken. > > -Sanjay > > > --- Shahram Davari wrote: > > Hi Sanjay, > > > > Seems like a good solution. But the only problem is that the source > > won't find out why the LSP has connectivity problem, is it due to > > mis-routing or is it due to lower level failures. > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > > Sent: Tuesday, July 10, 2001 11:37 AM > > > To: Shahram Davari; 'mpls@uu.net' > > > Subject: Re: draft-pan-lsp-ping-00.txt > > > > > > > > > The ingress could send this packet with IP ttl of 1 since the > > > intention > > > is to never ip forward this packet. The wrong egress in this > > > case would > > > drop it which is the desired behaviour. > > > > > > -Sanjay > > > > > > > > > --- Shahram Davari wrote: > > > > Hi, > > > > > > > > An observations/question: > > > > > > > > The draft says that the LSP ping packets are sent to the egress > > LSR > > > > with UDP encapsulation. I assume the IP address of the Ping > > packets > > > > are set to the IP address of the desired egress LSR. > What happens > > if > > > > a ping packet is delivered to an undesired egress LSR? From the > > MPLS > > > > architecture point of view, it seems that the undesired egress > > LSR > > > > will probably try to forward the Ping packet to the desired > > > LSR using > > > > the IP address in the Ping packet, which eventually could send > > > > echo-reply back to source. Therefore although the LSP > has a wrong > > > > path the source will never find out. > > > > > > > > Yours, > > > > Shahram Davari > > > > > > > > <> > > > > > > > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram > > Davari.vcf > > > > > > > > > > > > __________________________________________________ > > > 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 Tue Jul 10 16:05: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 QAA19929 for ; Tue, 10 Jul 2001 16:05: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 QQkxcq25461; Tue, 10 Jul 2001 20:05:18 GMT Received: by mail-control.mail.uu.net id QQkxcq03507 for mpls-outgoing; Tue, 10 Jul 2001 20:04: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 QQkxcq03354 for ; Tue, 10 Jul 2001 20:04:32 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 QQkxcq02146 for ; Tue, 10 Jul 2001 20:03:45 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 QQkxcq22807 for ; Tue, 10 Jul 2001 20:03: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 QAA18776 for ; Tue, 10 Jul 2001 16:03:42 -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 QAA06446 for ; Tue, 10 Jul 2001 16:03:44 -0400 (EDT) Message-ID: <3B4B5F8A.BBFCD476@marconi.com> Date: Tue, 10 Jul 2001 16:03:22 -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: Label Spaces and Uniqueness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Don Fedyk wrote: > > So what I think I heard is either: > > Standard says: All labels from the same space. No problems. > > But in practice I thought VPNs used: > > Assume per/interface outer labels, the next inner stacked label > from per node space. PHP to be avoided adjacent to boxes doing this. > > In the end it is a local decision of the box. No other box > cares what algorithm the allocating box is using. What it ultimately boils down to is: If multiple label spaces are used on a box, that box must be able to unambiguously determine which label space to use for looking up labels. Any mechanism that allows this is legal. Under certain circumstances (eg. a label stack where the egress of the inner LSP is using PHP) it may not be possible to unambiguously determine the label space. In which case, the LSPs involved in those situations must all draw labels from the same label space. -- David From owner-mpls@UU.NET Tue Jul 10 16:09: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 QAA20343 for ; Tue, 10 Jul 2001 16:09: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 QQkxcq24590; Tue, 10 Jul 2001 20:09:10 GMT Received: by mail-control.mail.uu.net id QQkxcq12510 for mpls-outgoing; Tue, 10 Jul 2001 20:08: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 QQkxcq12464 for ; Tue, 10 Jul 2001 20:08: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 QQkxcq05845 for ; Tue, 10 Jul 2001 20:06:48 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxcq20334 for ; Tue, 10 Jul 2001 20:06:48 GMT Message-ID: <3B4B6056.6EBADE24@sandburst.com> Date: Tue, 10 Jul 2001 16:06:46 -0400 From: Eric Gray MIME-Version: 1.0 To: Don Fedyk Cc: anouk@ureach.com, David Charlap , mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Don, While some are hunting on the details of when it is a local matter and when it is not, I think that most are not of the opinion that this is of such overwhelming importance that the specification must be changed at once (if ever). I once made the point on this list that there is unlikely to be a reason to update the MPLS Architecture RFC. In defense of the RFC, however, the original question neglected to include the context associated with the text quoted (speaking of labels and context). A few paragraphs above the quoted text (from the next to last paragraph of section 3.14), the section sets context for prohibiting assignment of different meanings to the same labels when certain conditions are not met. The paragraph from which the text is quoted is continuing in this context. Therefore, the quoted text is not as sweeping as it at first appears - even though (taken out of context as it was) it appears to be more restrictive than it needs to be in the general case. -- Eric Gray You wrote: > Hi > > So what I think I heard is either: > > Standard says: All labels from the same space. No problems. > > But in practice I thought VPNs used: > > Assume per/interface outer labels, the next inner stacked label > from per node space. PHP to be avoided adjacent to boxes doing this. > > In the end it is a local decision of the box. No other box > cares what algorithm the allocating box is using. > > So should the standard be updated? > > Don From owner-mpls@UU.NET Tue Jul 10 16:24: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 QAA21679 for ; Tue, 10 Jul 2001 16:24: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 QQkxcr01493; Tue, 10 Jul 2001 20:24:40 GMT Received: by mail-control.mail.uu.net id QQkxcr24256 for mpls-outgoing; Tue, 10 Jul 2001 20:24: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 QQkxcr24232 for ; Tue, 10 Jul 2001 20:24: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 QQkxcr18970 for ; Tue, 10 Jul 2001 20:21:57 GMT Received: from uniwest1.redstonecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.194.140.130]) id QQkxcr16034 for ; Tue, 10 Jul 2001 20:21:57 GMT Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <3VLJA02Z>; Tue, 10 Jul 2001 16:21:17 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C015261B5@UNIWEST1> From: "Wadhwa, Sanjay" To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: draft-pan-lsp-ping-00.txt Date: Tue, 10 Jul 2001 16:13: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 Hi Shahram Broken fiber would effect the rsvp control path. If the rsvp control path is healthy, then not getting the LSP-echo object in the RESV (after a certain amount of time beyond sending the echo-request) would point to messed up switch table entry in an LSR along the way, which is what this draft seems to be addressing I think.. -Sanjay > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, July 10, 2001 3:51 PM > To: 'Sanjay Wadhwa'; 'mpls@uu.net' > Subject: RE: draft-pan-lsp-ping-00.txt > > > Hi Sanjay, > > > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > Sent: Tuesday, July 10, 2001 3:39 PM > > To: Shahram Davari; 'mpls@uu.net' > > Subject: RE: draft-pan-lsp-ping-00.txt > > > > > > Hi Shahram > > I am not sure I understand your concern. Maybe I missed your point. > > Since the rsvp control path (which is used for response) is > alive i.e. > > RESV w/o LSP_ECHO are being received fine (after sending the echo > > request) by the ingress, but is not getting echo response > in the RESV, > > ingress can conclude that the lsp data plane is broken, which > > is what I > > think the scheme is trying to achieve. The end result in this case > > would be to consider the LSP as down. > > This is correct. But for diagnostic purpose you want to know why the > LSP is down. Is it because there was an error in one of the > switching tables > in its path, or because for example a fiber was broken. > > -Shahram > > > However, if the wrong egress does ip forward the packet > (u'r original > > concern), the ingress has no way to figure that LSP data plane is > > broken. > > > > -Sanjay > > > > > > --- Shahram Davari wrote: > > > Hi Sanjay, > > > > > > Seems like a good solution. But the only problem is that > the source > > > won't find out why the LSP has connectivity problem, is it due to > > > mis-routing or is it due to lower level failures. > > > > > > Yours, > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > > > Sent: Tuesday, July 10, 2001 11:37 AM > > > > To: Shahram Davari; 'mpls@uu.net' > > > > Subject: Re: draft-pan-lsp-ping-00.txt > > > > > > > > > > > > The ingress could send this packet with IP ttl of 1 since the > > > > intention > > > > is to never ip forward this packet. The wrong egress in this > > > > case would > > > > drop it which is the desired behaviour. > > > > > > > > -Sanjay > > > > > > > > > > > > --- Shahram Davari wrote: > > > > > Hi, > > > > > > > > > > An observations/question: > > > > > > > > > > The draft says that the LSP ping packets are sent to > the egress > > > LSR > > > > > with UDP encapsulation. I assume the IP address of the Ping > > > packets > > > > > are set to the IP address of the desired egress LSR. > > What happens > > > if > > > > > a ping packet is delivered to an undesired egress > LSR? From the > > > MPLS > > > > > architecture point of view, it seems that the undesired egress > > > LSR > > > > > will probably try to forward the Ping packet to the desired > > > > LSR using > > > > > the IP address in the Ping packet, which eventually could send > > > > > echo-reply back to source. Therefore although the LSP > > has a wrong > > > > > path the source will never find out. > > > > > > > > > > Yours, > > > > > Shahram Davari > > > > > > > > > > <> > > > > > > > > > > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram > > > Davari.vcf > > > > > > > > > > > > > > > > __________________________________________________ > > > > 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 Tue Jul 10 16:36: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 QAA22619 for ; Tue, 10 Jul 2001 16:36: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 QQkxcs08559; Tue, 10 Jul 2001 20:36:32 GMT Received: by mail-control.mail.uu.net id QQkxcs25251 for mpls-outgoing; Tue, 10 Jul 2001 20:36:00 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 QQkxcs25243 for ; Tue, 10 Jul 2001 20:35:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxcs27779 for ; Tue, 10 Jul 2001 20:34:35 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 QQkxcs07342 for ; Tue, 10 Jul 2001 20:34:34 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA18954; Tue, 10 Jul 2001 16:34:25 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA07065; Tue, 10 Jul 2001 16:34:23 -0400 (EDT) Message-Id: <200107102034.QAA07065@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "Dave Cooper" cc: "David Allan" , "Ping Pan" , "mpls-list" , "mpls-ops" Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Tue, 10 Jul 2001 10:43:30 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Jul 2001 16:34:22 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I'm still trying to be sure I understand just what this mechanism is to be used for. If a given LSP is working, and was set up with RSVP-TE, this mechanism will allow you to verify that it is working. If a given LSP is not working, this mechanism does not provide you with any diagnostic information. So you can use it for two purposes: - to test regularly whether an LSP is working - to eliminate "LSP data plane outage" as the source of a particular problem. This does seem useful. I think though that draft-bonica-icmp-mpls is also an attempt to provide the testing function, along with some diagnostic capability, but without a dependence on a particular control plane. Do you see draft-pan-lsp-ping as being superior in some respect? From owner-mpls@UU.NET Tue Jul 10 16:45: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 QAA23172 for ; Tue, 10 Jul 2001 16:45: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 QQkxcs24915; Tue, 10 Jul 2001 20:44:56 GMT Received: by mail-control.mail.uu.net id QQkxcs26356 for mpls-outgoing; Tue, 10 Jul 2001 20:44: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 QQkxcs26351 for ; Tue, 10 Jul 2001 20:44: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 QQkxcs12067 for ; Tue, 10 Jul 2001 20:41:30 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 QQkxcs18633 for ; Tue, 10 Jul 2001 20:41:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA14929 for mpls@uu.net; Tue, 10 Jul 2001 16:41:29 -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 QQkxcs26047 for ; Tue, 10 Jul 2001 20:40: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 QQkxcs01990 for ; Tue, 10 Jul 2001 20:37:57 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 QQkxcs11950 for ; Tue, 10 Jul 2001 20:37:56 GMT Received: (qmail 12097 invoked by uid 104); 10 Jul 2001 20:37:55 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.438258 secs); 10/07/2001 13:37:55 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 10 Jul 2001 20:37:54 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6AKbtP25020; Tue, 10 Jul 2001 13:37:55 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 13:43:03 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D66@BBY1EXM01> From: Shahram Davari To: "'Wadhwa, Sanjay'" , "'mpls@uu.net'" Subject: RE: draft-pan-lsp-ping-00.txt Date: Tue, 10 Jul 2001 13:43:03 -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 guess you are right. Another observation/comment: What if the LSP is setup to carry a particular protocol, such as Ethernet. Then it is not possible to use that LSP to carry the UDP/IP based Ping packets. Yours, -Shahram > -----Original Message----- > From: Wadhwa, Sanjay [mailto:SWadhwa@unispherenetworks.com] > Sent: Tuesday, July 10, 2001 4:14 PM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: draft-pan-lsp-ping-00.txt > > > Hi Shahram > Broken fiber would effect the rsvp control path. If the > rsvp control path > is healthy, then not getting the LSP-echo object in the RESV (after a > certain amount of time beyond sending the echo-request) would point to > messed up switch table entry in an LSR along the way, which > is what this > draft seems to be addressing I think.. > > -Sanjay > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Tuesday, July 10, 2001 3:51 PM > > To: 'Sanjay Wadhwa'; 'mpls@uu.net' > > Subject: RE: draft-pan-lsp-ping-00.txt > > > > > > Hi Sanjay, > > > > > > > -----Original Message----- > > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > > Sent: Tuesday, July 10, 2001 3:39 PM > > > To: Shahram Davari; 'mpls@uu.net' > > > Subject: RE: draft-pan-lsp-ping-00.txt > > > > > > > > > Hi Shahram > > > I am not sure I understand your concern. Maybe I missed > your point. > > > Since the rsvp control path (which is used for response) is > > alive i.e. > > > RESV w/o LSP_ECHO are being received fine (after sending the echo > > > request) by the ingress, but is not getting echo response > > in the RESV, > > > ingress can conclude that the lsp data plane is broken, which > > > is what I > > > think the scheme is trying to achieve. The end result in this case > > > would be to consider the LSP as down. > > > > This is correct. But for diagnostic purpose you want to know why the > > LSP is down. Is it because there was an error in one of the > > switching tables > > in its path, or because for example a fiber was broken. > > > > -Shahram > > > > > However, if the wrong egress does ip forward the packet > > (u'r original > > > concern), the ingress has no way to figure that LSP data plane is > > > broken. > > > > > > -Sanjay > > > > > > > > > --- Shahram Davari wrote: > > > > Hi Sanjay, > > > > > > > > Seems like a good solution. But the only problem is that > > the source > > > > won't find out why the LSP has connectivity problem, is > it due to > > > > mis-routing or is it due to lower level failures. > > > > > > > > Yours, > > > > -Shahram > > > > > > > > > -----Original Message----- > > > > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > > > > Sent: Tuesday, July 10, 2001 11:37 AM > > > > > To: Shahram Davari; 'mpls@uu.net' > > > > > Subject: Re: draft-pan-lsp-ping-00.txt > > > > > > > > > > > > > > > The ingress could send this packet with IP ttl of 1 since the > > > > > intention > > > > > is to never ip forward this packet. The wrong egress in this > > > > > case would > > > > > drop it which is the desired behaviour. > > > > > > > > > > -Sanjay > > > > > > > > > > > > > > > --- Shahram Davari wrote: > > > > > > Hi, > > > > > > > > > > > > An observations/question: > > > > > > > > > > > > The draft says that the LSP ping packets are sent to > > the egress > > > > LSR > > > > > > with UDP encapsulation. I assume the IP address of the Ping > > > > packets > > > > > > are set to the IP address of the desired egress LSR. > > > What happens > > > > if > > > > > > a ping packet is delivered to an undesired egress > > LSR? From the > > > > MPLS > > > > > > architecture point of view, it seems that the > undesired egress > > > > LSR > > > > > > will probably try to forward the Ping packet to the desired > > > > > LSR using > > > > > > the IP address in the Ping packet, which eventually > could send > > > > > > echo-reply back to source. Therefore although the LSP > > > has a wrong > > > > > > path the source will never find out. > > > > > > > > > > > > Yours, > > > > > > Shahram Davari > > > > > > > > > > > > <> > > > > > > > > > > > > > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram > > > > Davari.vcf > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > 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 Tue Jul 10 16:46:26 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 QAA23293 for ; Tue, 10 Jul 2001 16:46: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 QQkxct02400; Tue, 10 Jul 2001 20:46:40 GMT Received: by mail-control.mail.uu.net id QQkxct26680 for mpls-outgoing; Tue, 10 Jul 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 QQkxct26648 for ; Tue, 10 Jul 2001 20:45: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 QQkxcs19826 for ; Tue, 10 Jul 2001 20:43:55 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxcs07481 for ; Tue, 10 Jul 2001 20:43:55 GMT Message-ID: <3B4B6909.2D76B9D3@sandburst.com> Date: Tue, 10 Jul 2001 16:43:53 -0400 From: Eric Gray MIME-Version: 1.0 To: Shahram Davari Cc: "'Don Fedyk'" , anouk@ureach.com, David Charlap , mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D65@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, While the point you make about needing more than a million labels per interface is a good one, I do not believe it is particularly relevant in this discussion. Oddly enough, many of the same issues with supporting the 'per-platform' label space in ATM apply as well when using MPLS based forwarding hardware in a distributed forwarding system. ATM has an upper bound on the number of per-interface 'labels' that is much higher than a million, and yet it is a generally assumed that an ATM LSR will not support the per-platform label space (at least for ATM VPI/VCI 'labels'). Issues with dancing lightly around labels that have already been distributed in association with MPLS forwarding at forwarding hardware elsewhere in a system are entertaining, to say the least. Hence, bluntly asserting that labels cannot be con- sidered in a context of how they were received (effectively asserting per-platform label space) is a 'simplification' that may add its own complexities. As such, I believe that the decision of whether or not to consider labels in some context is one that should be left as an engineering trade-off for implementers to make - in as much as it may be considered of local significance only. Don't you agree? -- Eric Gray You wrote: > Hi,Also, who needs more than 1 million labels per interface?-Shahram > > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com] > Sent: Tuesday, July 10, 2001 3:41 PM > To: Eric Gray; anouk@ureach.com; David Charlap > Cc: mpls@UU.NET > Subject: RE: Label Spaces and Uniqueness > Hi > > So what I think I heard is either: > > Standard says: All labels from the same space. No problems. > > But in practice I thought VPNs used: > > Assume per/interface outer labels, the next inner stacked label > from per node space. PHP to be avoided adjacent to boxes doing this. > > In the end it is a local decision of the box. No other box > cares what algorithm the allocating box is using. > > So should the standard be updated? > > Don > > > > > > From owner-mpls@UU.NET Tue Jul 10 17:19: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 RAA24990 for ; Tue, 10 Jul 2001 17:19: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 QQkxcv13056; Tue, 10 Jul 2001 21:18:54 GMT Received: by mail-control.mail.uu.net id QQkxcv19734 for mpls-outgoing; Tue, 10 Jul 2001 21:18: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 QQkxcv19729 for ; Tue, 10 Jul 2001 21:18:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxcv19476 for ; Tue, 10 Jul 2001 21:16:18 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 QQkxcv07069 for ; Tue, 10 Jul 2001 21:16:17 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA24266; Tue, 10 Jul 2001 17:16:07 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA07228; Tue, 10 Jul 2001 17:16:05 -0400 (EDT) Message-Id: <200107102116.RAA07228@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "Dave Cooper" cc: "David Allan" , "Ping Pan" , "mpls-list" , "mpls-ops" Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Tue, 10 Jul 2001 16:34:22 -0400. <200107102034.QAA07065@erosen-u10.cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Jul 2001 17:16:05 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I meant to say "draft-bonica-tunproto-00", not "draft-bonica-icmp-mpls", in my last message. From owner-mpls@UU.NET Tue Jul 10 18:13: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 SAA27026 for ; Tue, 10 Jul 2001 18:13: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 QQkxcy21640; Tue, 10 Jul 2001 22:13:43 GMT Received: by mail-control.mail.uu.net id QQkxcy15155 for mpls-outgoing; Tue, 10 Jul 2001 22:13: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 QQkxcy15140 for ; Tue, 10 Jul 2001 22:12: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 QQkxcy07255 for ; Tue, 10 Jul 2001 22:12:40 GMT Received: from ureach.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxcy12112 for ; Tue, 10 Jul 2001 22:12:40 GMT Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49]) by ureach.com (8.9.1/8.8.5) with ESMTP id SAA02767; Tue, 10 Jul 2001 18:12:39 -0400 Received: (from nobody@localhost) by www21.ureach.com (8.9.3/8.9.1) id SAA27069; Tue, 10 Jul 2001 18:12:39 -0400 Date: Tue, 10 Jul 2001 18:12:39 -0400 Message-Id: <200107102212.SAA27069@www21.ureach.com> To: "Don Fedyk" , "Eric Gray " , " David Charlap " From: Anouk Rocher Reply-to: Subject: Re: RE: Label Spaces and Uniqueness cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Minor point in line Don. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Tue, 10 Jul 2001, Don Fedyk (dwfedyk@nortelnetworks.com) wrote: > Hi > > So what I think I heard is either: > > Standard says: All labels from the same space. No problems. > > But in practice I thought VPNs used: > > Assume per/interface outer labels, the next inner stacked label > from per node space. PHP to be avoided adjacent to boxes doing this. As per my understanding, VPNs need not use per interface labels for the outer label. Per Platform labels for this should work equally well. Or was there a point in there that I missed? > > In the end it is a local decision of the box. No other box > cares what algorithm the allocating box is using. > > So should the standard be updated? > > Don Anouk. From owner-mpls@UU.NET Tue Jul 10 18:19: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 SAA27226 for ; Tue, 10 Jul 2001 18:19: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 QQkxcz26840; Tue, 10 Jul 2001 22:19:34 GMT Received: by mail-control.mail.uu.net id QQkxcz15763 for mpls-outgoing; Tue, 10 Jul 2001 22:19:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxcz15746 for ; Tue, 10 Jul 2001 22:18:55 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 QQkxcz10515 for ; Tue, 10 Jul 2001 22:15:04 GMT Received: from ureach.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxcz16886 for ; Tue, 10 Jul 2001 22:15:03 GMT Received: from www22.ureach.com (IDENT:root@www22.ureach.com [172.16.2.50]) by ureach.com (8.9.1/8.8.5) with ESMTP id SAA10500; Tue, 10 Jul 2001 18:15:03 -0400 Received: (from nobody@localhost) by www22.ureach.com (8.9.3/8.9.1) id QAA11129; Tue, 10 Jul 2001 16:47:51 -0400 Date: Tue, 10 Jul 2001 16:47:51 -0400 Message-Id: <200107102047.QAA11129@www22.ureach.com> To: "Eric Gray" From: Anouk Rocher Reply-to: Subject: Re: Re: Label Spaces and Uniqueness cc: mpls@UU.NET, " David Charlap " Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I am sorry I mis-wrote. You are absolutely right (and you did answer my question except for the follow on below). I meant that the "outer" label is established by RSVP TE and the inner by LDP. According to the martini drafts, the inner label is usually associate with a layer 2 entity like frame-relay DLCI. I see your point about problems with independent label spaces operating at different levels of the stack if PHP is used. However, is it a MUST (in ietf terminology) to support PHP? Ie if I have network which does not rely on PHP, is it otherwise reasonable to allow independent label spaces - in the above example one for the inside of a network (outer label, using rsvp-te) and one for the edges (inner-label, using LDP). Thanks! Anouk. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Tue, 10 Jul 2001, Eric Gray (eric.gray@sandburst.com) wrote: > Anouk, > > I assume that David can answer for himself, however I would like to > get some things clarified. Please see comments/questions below. > > Anouk Rocher wrote: > > > David, > > > > Let me clarify with a more specific example. Lets say we want > > to deploy one of the l2 vpn mechanisms - say the one in > draft-maritini-* > > The inner label there is negotiated between the ingress and egress > > LSRs via LDP (sort of multi-hop). The inner label is negotiated (say) > > via RSVP-TE. > > I believe one of these should be 'outer label'. I assume you mean > higher > level, when you say 'outer' and lower level when you say 'inner' but, > even > so, I am not sure which should be which in your description above (just > that they cannot both be the same). > > Would you recast your question somehow distinguishing which is which? > > > > > > > I don't see a reason why LDP and RSVP-TE be forced to use the same > > label space in this case. (I am sure there are similar cases while > > using wavelengths as labels.) > > > > Am I missing something obvious? > > So, one reason would be if PHP is used. In this case, the egress for > the > lower level label will not have received the higher level label and will > not > be able to distinguish it from other labels it receives from the > penultimate > hop. Give that this is the case, then the egress LSR must not > distribute > a label to be used by the remote LSR at the other end of the LSP tunnel > with a different meaning then an identical label distributed to the > local > LSR that happens to be the punultimate hop for the LSP tunnel. > > This is an example of when the label space MUST be the same. Does this > answer your question? From owner-mpls@UU.NET Tue Jul 10 18:27: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 SAA27500 for ; Tue, 10 Jul 2001 18:27: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 QQkxcz28315; Tue, 10 Jul 2001 22:27:24 GMT Received: by mail-control.mail.uu.net id QQkxcz16368 for mpls-outgoing; Tue, 10 Jul 2001 22:26: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 QQkxcz16340 for ; Tue, 10 Jul 2001 22:26:42 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 QQkxcz00805 for ; Tue, 10 Jul 2001 22:25:41 GMT Received: from squid.squirehome.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu163-42-132.nc.rr.com [24.163.42.132]) id QQkxcz14138 for ; Tue, 10 Jul 2001 22:25:40 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6AMOat01380; Tue, 10 Jul 2001 18:24:36 -0400 Message-ID: <3B4B80A4.DD3FFB91@acm.org> Date: Tue, 10 Jul 2001 18:24:36 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Eric Gray CC: David Charlap , mpls@UU.NET Subject: Re: Label Spaces and Uniqueness References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D5F@BBY1EXM01> <3B4B2CC2.EA2243A7@marconi.com> <3B4B412D.8B6211B3@acm.org> <3B4B44C8.7A1D0528@marconi.com> <3B4B4CE2.64AA680@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > > Matt Squire wrote: > > > > > > But there are many potential ways for F to distinguish the context > > > of a packet and hence the label space. It could look at the port or > > > VC or, as Eric mentioned, it can view an LSP as a port and have a > > > label space for that port/LSP. > > > > Port? If you mean physical interface, yes. It's always possible to > > determine label space based on that. If you're talking about TCP/UDP > > port, then no - an MPLS forwarder should not use the payload as the > > basis for any forwarding decisions. > > > > VC? With most MPLS-over-ATM implementations, the VC is the top label. > > I mean logical interface. People create logical interfaces over physical interfaces in oodles of ways (ATM VC, VLAN/Ethernet, FR, GRE, PPP, ...). An LSP provides another way of partitioning a physical interface into multiple logical ports/channels/thingies. > > As for the LSP, you've just created a circular definition. The LSP is > > determined by the label. But you also want to compute the meaning of > > that label from the LSP. > > Actually I'm talking about a stacked implementation. Its clear that one could treat an LSP, from a certain perspective, as you would any physical port (ie ethernet/mpls, run spanning tree, etc.). You could then just treat that LSP as a port over which you run LDP/RSVPTE/BGP/... Its clear that the label space of in that context can be implemented in such a way that they are independent of other label spaces on the box. Its just label stacking. > > > When a packet arrives the LSR has to determine the context, ie label > > > space, and view the packet in that context. As long as the LSR can > > > do that, it can have any insane internal label assignment methodolgy > > > that it wants. There are oodles of possibilities, most of them > > > impractical but interoperable. > > > > Sure. But aside from physical port information or L2 information, the > > only other way to determine the LSP is by looking at the top label. > > I am in vehement agreement that there's no need to change the doc. Arguments for or against the correctness could be made either way. As long as I can interpret the labels I distribute, I'm free to do it in any way I want using as many label spaces as I wish. I shall now shut up on the subject forever as its not worth arguing over. If I comment on it again, feel free to pull me aside and beat me with a stick. No, I mean it. A big stick. - Matt From owner-mpls@UU.NET Tue Jul 10 18:33: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 SAA27770 for ; Tue, 10 Jul 2001 18:33: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 QQkxda29097; Tue, 10 Jul 2001 22:33:51 GMT Received: by mail-control.mail.uu.net id QQkxda16908 for mpls-outgoing; Tue, 10 Jul 2001 22:33: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 QQkxda16895 for ; Tue, 10 Jul 2001 22:33: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 QQkxda01064 for ; Tue, 10 Jul 2001 22:31:06 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxda24439 for ; Tue, 10 Jul 2001 22:31:06 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6AMUmH20751; Tue, 10 Jul 2001 15:30:48 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200107102230.f6AMUmH20751@merlot.juniper.net> To: erosen@cisco.com cc: "Dave Cooper" , "mpls-list" , "mpls-ops" Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-Reply-To: Your message of "Tue, 10 Jul 2001 16:34:22 EDT." <200107102034.QAA07065@erosen-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73804.994804248.1@juniper.net> Date: Tue, 10 Jul 2001 15:30:48 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Eric, > I'm still trying to be sure I understand just what this mechanism is to be > used for. > > If a given LSP is working, and was set up with RSVP-TE, this mechanism will > allow you to verify that it is working. > > If a given LSP is not working, this mechanism does not provide you with any > diagnostic information. > > So you can use it for two purposes: > > - to test regularly whether an LSP is working > > - to eliminate "LSP data plane outage" as the source of a particular > problem. > > This does seem useful. > > I think though that draft-bonica-icmp-mpls is also an attempt to provide the > testing function, along with some diagnostic capability, but without a > dependence on a particular control plane. Do you see draft-pan-lsp-ping as > being superior in some respect? yes. Yakov. From owner-mpls@UU.NET Tue Jul 10 18:40:01 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 SAA27961 for ; Tue, 10 Jul 2001 18:40:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxda24045; Tue, 10 Jul 2001 22:40:17 GMT Received: by mail-control.mail.uu.net id QQkxda17368 for mpls-outgoing; Tue, 10 Jul 2001 22:39: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 QQkxda17360 for ; Tue, 10 Jul 2001 22:39:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxda06995 for ; Tue, 10 Jul 2001 22:37:24 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 QQkxda13511 for ; Tue, 10 Jul 2001 22:37:23 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 f6AMb6b26576 for ; Tue, 10 Jul 2001 18:37:06 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Jul 2001 18:37:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ2Y0T8>; Tue, 10 Jul 2001 18:37:11 -0400 Message-ID: From: "Don Fedyk" To: anouk , Eric Gray , David Charlap Cc: mpls@UU.NET Subject: RE: RE: Label Spaces and Uniqueness Date: Tue, 10 Jul 2001 18:37:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10990.D7689320" 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_01C10990.D7689320 Content-Type: text/plain; charset="iso-8859-1" > From: Anouk Rocher [mailto:anouk@ureach.com] > Subject: Re: RE: Label Spaces and Uniqueness > > Minor point in line Don. > > ---- On Tue, 10 Jul 2001, Don Fedyk > (dwfedyk@nortelnetworks.com) wrote: > > > Hi > > > > So what I think I heard is either: > > > > Standard says: All labels from the same space. No problems. > > > > But in practice I thought VPNs used: > > > > Assume per/interface outer labels, the next inner stacked label > > from per node space. PHP to be avoided adjacent to boxes doing this. > > As per my understanding, VPNs need not use per interface labels for > the outer label. Per Platform labels for this should work > equally well. > > Or was there a point in there that I missed? Actually there is a subtlety that I skimmed over. There is a difference between requirements on labels for forwarding and allocation. Much of the discussion for the label space has been motivated by forwarding. This is the first point, all labels from per platform space works from a forwarding paradigm. However, in some instances people are looking at per interface label space on the outer labels to allow more freedom in allocating (inner) VPN labels. You can reallocate ranges with more freedom for example. Then this has implications on forwarding. Don ------_=_NextPart_001_01C10990.D7689320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: Label Spaces and Uniqueness

> From: Anouk Rocher [mailto:anouk@ureach.com]
> Subject: Re: RE: Label Spaces and = Uniqueness
>
> Minor point in line Don.
>
> ---- On Tue, 10 Jul 2001, Don Fedyk
> (dwfedyk@nortelnetworks.com) wrote:
>
> > Hi
> >
> > So what I think I heard is either:
> >
> > Standard says: All labels from the same = space. No problems.
> >
> > But in practice I thought VPNs = used:
> >
> > Assume per/interface outer labels, the = next inner stacked label
> > from per node space. PHP to be avoided = adjacent to boxes doing this.
>
> As per my understanding, VPNs need not use per = interface labels for
> the outer label. Per Platform labels for this = should work
> equally well.
>
> Or was there a point in there that I = missed?

Actually there is a subtlety that I skimmed over. = There is a difference between requirements on labels for forwarding and = allocation. Much of the discussion

for the label space has been motivated by forwarding. = This is the first point,
all labels from per platform space works from a = forwarding paradigm. However,
in some instances people are looking at per = interface label space on the outer
labels to allow more freedom in allocating (inner) = VPN labels. You can
reallocate ranges with more freedom for example. = Then this has implications on forwarding.

Don
 

------_=_NextPart_001_01C10990.D7689320-- From owner-mpls@UU.NET Tue Jul 10 19:09: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 TAA28943 for ; Tue, 10 Jul 2001 19:09: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 QQkxdc14891; Tue, 10 Jul 2001 23:09:27 GMT Received: by mail-control.mail.uu.net id QQkxdc09356 for mpls-outgoing; Tue, 10 Jul 2001 23:08: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 QQkxdc09313 for ; Tue, 10 Jul 2001 23:08:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxdc15081 for ; Tue, 10 Jul 2001 23:07:06 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 QQkxdc08664 for ; Tue, 10 Jul 2001 23:07:05 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 f6AN6lb27480 for ; Tue, 10 Jul 2001 19:06:47 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Jul 2001 19:06:59 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ2Y0Y5>; Tue, 10 Jul 2001 19:07:01 -0400 Message-ID: From: "Don Fedyk" To: Dave Cooper , "David Allan" , Ping Pan Cc: mpls-list , mpls-ops Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Tue, 10 Jul 2001 19:06:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10995.017C3960" 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_01C10995.017C3960 Content-Type: text/plain; charset="iso-8859-1" The urgency to deploy a fix should not be confused with the necessity to fix it right. Don > -----Original Message----- > From: Dave Cooper [mailto:dcooper@gblx.net] > Sent: Tuesday, July 10, 2001 1:44 PM > To: Allan, David [CAR:NS00:EXCH]; Ping Pan > Cc: mpls-list; mpls-ops > Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] > > > David, > I think its up to the operators to ascertain > usefulness and applicability. We were motivated > to submit this draft because of the urgency in > detecting LSP integrity in MPLS TE networks. > No, it doesnt address all of the requirements > outlined in the OAM draft. But it attempts to > address one of the most significant issues we face in > today's MPLS networks. Our goal is to keep it > as simple as possible but accomplish this objective. > > Thanks, > Dave > > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of David Allan > Sent: Tuesday, July 10, 2001 9:30 AM > To: Ping Pan > Cc: mpls-list; mpls-ops > Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] > > > Ping: > I am specifically concerned that although this tool may be > percieved as useful, it really has very limited > applicability, it assumes > a specific MPLS payload and a specific control plane. How > many of these mechanisms do we wish to support before we > finally have a > comprehensive toolkit? > IMHO It would be a whole lot more useful if we just tackled > the problem in its entirety instead of via the incremental approach we > have seen to date. > One group of authors (Neil Harrison and company) has a > requirements draft posted already, and we'll be bringing > forward a framework > to London that builds upon it (to be posted later this week), > Perhaps we can start to put these problems to bed a bit more > systematically.... > cheers > Dave > > ------_=_NextPart_001_01C10995.017C3960 Content-Type: text/html; charset="iso-8859-1" RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

The urgency to deploy a fix should not be confused with the necessity to fix it right.

Don


> -----Original Message-----
> From: Dave Cooper [mailto:dcooper@gblx.net]
> Sent: Tuesday, July 10, 2001 1:44 PM
> To: Allan, David [CAR:NS00:EXCH]; Ping Pan
> Cc: mpls-list; mpls-ops
> Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
>
>
> David,
> I think its up to the operators to ascertain
> usefulness and applicability.  We were motivated
> to submit this draft because of the urgency in
> detecting LSP integrity in MPLS TE networks.
> No, it doesnt address all of the requirements
> outlined in the OAM draft. But it attempts to
> address one of the most significant issues we face in
> today's MPLS networks.  Our goal is to keep it
> as simple as possible but accomplish this objective.
>
> Thanks,
> Dave
>
>
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> Of David Allan
> Sent: Tuesday, July 10, 2001 9:30 AM
> To: Ping Pan
> Cc: mpls-list; mpls-ops
> Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
>
>
> Ping:
> I am specifically concerned that although this tool may be
> percieved as useful, it really has very limited
> applicability, it assumes
> a specific MPLS payload and a specific control plane. How
> many of these mechanisms do we wish to support before we
> finally have a
> comprehensive toolkit?
> IMHO It would be a whole lot more useful if we just tackled
> the problem in its entirety instead of via the incremental approach we
> have seen to date.
> One group of authors (Neil Harrison and company) has a
> requirements draft posted already, and we'll be bringing
> forward a framework
> to London that builds upon it (to be posted later this week),
> Perhaps we can start to put these problems to bed a bit more
> systematically....
> cheers
> Dave
>
>

------_=_NextPart_001_01C10995.017C3960-- From owner-mpls@UU.NET Tue Jul 10 19:25: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 TAA29485 for ; Tue, 10 Jul 2001 19:25: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 QQkxdd16504; Tue, 10 Jul 2001 23:25:25 GMT Received: by mail-control.mail.uu.net id QQkxdd11593 for mpls-outgoing; Tue, 10 Jul 2001 23:24:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxdd11583 for ; Tue, 10 Jul 2001 23:24:48 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 QQkxdd12931 for ; Tue, 10 Jul 2001 23:22:38 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 QQkxdd10899 for ; Tue, 10 Jul 2001 23:22:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA28009 for mpls@uu.net; Tue, 10 Jul 2001 19:22:37 -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 QQkxdd11398 for ; Tue, 10 Jul 2001 23:22:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxdd06044 for ; Tue, 10 Jul 2001 23:20:44 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxdd06759 for ; Tue, 10 Jul 2001 23:20:44 GMT Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6ANKdH23585; Tue, 10 Jul 2001 16:20:39 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B4B8DC7.53D357D7@juniper.net> Date: Tue, 10 Jul 2001 16:20:39 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sanjay Wadhwa CC: Shahram Davari , "'mpls@uu.net'" Subject: Re: draft-pan-lsp-ping-00.txt References: <20010710193907.7037.qmail@web11402.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 Sanjay, Actually, the ping messages should use IP-TTL=1. You description on the problem makes a lot of sense. I will put it in the next version of the draft. Thanks! - Ping Sanjay Wadhwa wrote: > > Hi Shahram > I am not sure I understand your concern. Maybe I missed your point. > Since the rsvp control path (which is used for response) is alive i.e. > RESV w/o LSP_ECHO are being received fine (after sending the echo > request) by the ingress, but is not getting echo response in the RESV, > ingress can conclude that the lsp data plane is broken, which is what I > think the scheme is trying to achieve. The end result in this case > would be to consider the LSP as down. > However, if the wrong egress does ip forward the packet (u'r original > concern), the ingress has no way to figure that LSP data plane is > broken. > > -Sanjay > > --- Shahram Davari wrote: > > Hi Sanjay, > > > > Seems like a good solution. But the only problem is that the source > > won't find out why the LSP has connectivity problem, is it due to > > mis-routing or is it due to lower level failures. > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Sanjay Wadhwa [mailto:swadhwa01@yahoo.com] > > > Sent: Tuesday, July 10, 2001 11:37 AM > > > To: Shahram Davari; 'mpls@uu.net' > > > Subject: Re: draft-pan-lsp-ping-00.txt > > > > > > > > > The ingress could send this packet with IP ttl of 1 since the > > > intention > > > is to never ip forward this packet. The wrong egress in this > > > case would > > > drop it which is the desired behaviour. > > > > > > -Sanjay > > > > > > > > > --- Shahram Davari wrote: > > > > Hi, > > > > > > > > An observations/question: > > > > > > > > The draft says that the LSP ping packets are sent to the egress > > LSR > > > > with UDP encapsulation. I assume the IP address of the Ping > > packets > > > > are set to the IP address of the desired egress LSR. What happens > > if > > > > a ping packet is delivered to an undesired egress LSR? From the > > MPLS > > > > architecture point of view, it seems that the undesired egress > > LSR > > > > will probably try to forward the Ping packet to the desired > > > LSR using > > > > the IP address in the Ping packet, which eventually could send > > > > echo-reply back to source. Therefore although the LSP has a wrong > > > > path the source will never find out. > > > > > > > > Yours, > > > > Shahram Davari > > > > > > > > <> > > > > > > > > > > > ATTACHMENT part 2 application/octet-stream name=Shahram > > Davari.vcf > > > > > > > > > > > > __________________________________________________ > > > 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 Tue Jul 10 22:52: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 WAA06380 for ; Tue, 10 Jul 2001 22:52: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 QQkxdr25673; Wed, 11 Jul 2001 02:53:06 GMT Received: by mail-control.mail.uu.net id QQkxdr29187 for mpls-outgoing; Wed, 11 Jul 2001 02:52:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxdr29171 for ; Wed, 11 Jul 2001 02:52:18 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 QQkxdr21578 for ; Wed, 11 Jul 2001 02:51:16 GMT Received: from tju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver.tju.edu.cn [202.113.15.13]) id QQkxdr20988 for ; Wed, 11 Jul 2001 02:51:15 GMT Received: from rose.tju.edu.cn (rose.tju.edu.cn [202.113.0.9]) by tju.edu.cn (8.9.1b+Sun/8.9.1) with ESMTP id KAA27912 for ; Wed, 11 Jul 2001 10:43:36 +0800 (CST) Received: from eae ([202.113.4.43]) by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id KAA30300 for ; Wed, 11 Jul 2001 10:42:07 +0800 Message-Id: <200107110242.KAA30300@rose.tju.edu.cn> Date: Wed, 11 Jul 2001 10:50:27 +0800 From: STONE CHEN To: "mpls@UU.NET" Subject: Priority X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_Dragon421643457108_=====" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --=====_Dragon421643457108_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit In RFC2702, "Req'ts for TE with MPLS", could anyone clarify the concept of "traffic trunk" when explaining the concept of priority attribute? Is that priority set up when establishing a new LSP or pre-established for each link bandwidth before establishing any LSPs? And, more detailed explanation is needed for the "shared explicit reservation style" when you make a reroute path for any link congestion or failures. Rae. --=====_Dragon421643457108_===== Content-Type: text/html; name="unknown(1).HTM" Content-Disposition: attachment; filename="unknown(1).HTM" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkluIFJGQzI3 MDIsICJSZXEndHMgZm9yIFRFIHdpdGggTVBMUyIsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+Y291bGQgYW55b25lIGNsYXJpZnkgdGhlIGNvbmNlcHQgb2YgInRyYWZmaWMgDQp0cnVu ayImbmJzcDt3aGVuJm5ic3A7ZXhwbGFpbmluZyB0aGUgY29uY2VwdCBvZiBwcmlvcml0eSBhdHRy aWJ1dGU/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhhdCBwcmlvcml0eSBz ZXQgdXAmbmJzcDt3aGVuIGVzdGFibGlzaGluZyBhIG5ldyBMU1Agb3IgDQo8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5wcmUtZXN0YWJsaXNoZWQgZm9yJm5ic3A7ZWFjaCBsaW5rIGJh bmR3aWR0aCBiZWZvcmUgDQplc3RhYmxpc2hpbmcgYW55IExTUHM/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QW5k LCZuYnNwO21vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb24gaXMgbmVlZGVkIGZvciB0aGUgInNoYXJl ZCANCmV4cGxpY2l0IHJlc2VydmF0aW9uIHN0eWxlIjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPndoZW4geW91IG1ha2UgYSByZXJvdXRlIHBhdGggZm9yIGFueSBsaW5rIGNvbmdlc3Rp b24gb3IgDQpmYWlsdXJlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5SYWUuPC9GT05UPjwvRElWPjwvQk9EWT48 L0hUTUw+DQo= --=====_Dragon421643457108_=====-- From owner-mpls@UU.NET Tue Jul 10 22:54: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 WAA06396 for ; Tue, 10 Jul 2001 22:54: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 QQkxdr07951; Wed, 11 Jul 2001 02:54:40 GMT Received: by mail-control.mail.uu.net id QQkxdr29236 for mpls-outgoing; Wed, 11 Jul 2001 02:54: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 QQkxdr29209 for ; Wed, 11 Jul 2001 02:53: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 QQkxdr11109 for ; Wed, 11 Jul 2001 02:52:28 GMT Received: from tju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver.tju.edu.cn [202.113.15.13]) id QQkxdr23974 for ; Wed, 11 Jul 2001 02:52:26 GMT Received: from rose.tju.edu.cn (rose.tju.edu.cn [202.113.0.9]) by tju.edu.cn (8.9.1b+Sun/8.9.1) with ESMTP id KAA27919 for ; Wed, 11 Jul 2001 10:45:03 +0800 (CST) Received: from eae ([202.113.4.43]) by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id KAA30310 for ; Wed, 11 Jul 2001 10:43:35 +0800 Message-Id: <200107110243.KAA30310@rose.tju.edu.cn> Date: Wed, 11 Jul 2001 10:51:54 +0800 From: STONE CHEN To: "mpls@UU.NET" Subject: LSP Setup Algorithms X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_Dragon008080865247_=====" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --=====_Dragon008080865247_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Hello, Does anyone know the references to finding LSPs for a given traffic demands between (ingress, egress) pairs, where each LSP requires some value of link bandwidth? I think that those problems might be exactly same as the traditional ATM PVC setup. Is it true? Then, any starting points for that kind of problem will be helpful for my research. Thanks in advance. -Rae --=====_Dragon008080865247_===== Content-Type: text/html; name="unknown(2).HTM" Content-Disposition: attachment; filename="unknown(2).HTM" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj4N CjxESVY+SGVsbG8sPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Eb2VzJm5ic3A7YW55 b25lIGtub3cgdGhlIHJlZmVyZW5jZXMgdG8gZmluZGluZyBMU1BzIGZvciBhIGdpdmVuIHRyYWZm aWMgDQpkZW1hbmRzPC9ESVY+DQo8RElWPmJldHdlZW4gKGluZ3Jlc3MsIGVncmVzcykgcGFpcnMs IHdoZXJlIGVhY2ggTFNQIHJlcXVpcmVzIHNvbWUgdmFsdWUgb2YgbGluayANCmJhbmR3aWR0aD88 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgdGhpbmsgdGhhdCB0aG9zZSBwcm9ibGVt cyBtaWdodCBiZSBleGFjdGx5IHNhbWUgYXMgdGhlIHRyYWRpdGlvbmFsIEFUTSANClBWQyBzZXR1 cC48L0RJVj4NCjxESVY+SXMgaXQgdHJ1ZT8gVGhlbiwgYW55IHN0YXJ0aW5nIHBvaW50cyBmb3Ig dGhhdCBraW5kIG9mIHByb2JsZW0gd2lsbCBiZSANCmhlbHBmdWwgZm9yIG15IHJlc2VhcmNoLjwv RElWPg0KPERJVj5UaGFua3MgaW4gYWR2YW5jZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPi1SYWU8L0RJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====_Dragon008080865247_=====-- From owner-mpls@UU.NET Tue Jul 10 23:35: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 XAA07622 for ; Tue, 10 Jul 2001 23:35: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 QQkxdu17271; Wed, 11 Jul 2001 03:36:10 GMT Received: by mail-control.mail.uu.net id QQkxdu22007 for mpls-outgoing; Wed, 11 Jul 2001 03:35:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxdu21999 for ; Wed, 11 Jul 2001 03:35:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxdu20649 for ; Wed, 11 Jul 2001 03:35:21 GMT Received: from NOD.RESTON.MCI.NET by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nod.reston.mci.net [166.60.6.38]) id QQkxdu19523 for ; Wed, 11 Jul 2001 03:35:21 GMT Received: from rbonica ([166.60.14.236]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with SMTP id <01K5S8CSPDQ4A9L0KT@shoe.reston.mci.net> for mpls@UU.NET; Tue, 10 Jul 2001 23:35:20 -0500 (EST) Date: Tue, 10 Jul 2001 23:18:12 -0400 From: Ron Bonica Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: <200107102230.f6AMUmH20751@merlot.juniper.net> To: Yakov Rekhter , erosen@cisco.com Cc: Dave Cooper , mpls-list , mpls-ops 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 > > I think though that draft-bonica-icmp-mpls is also an attempt > to provide the > > testing function, along with some diagnostic capability, > but without a > > dependence on a particular control plane. Do you see > draft-pan-lsp-ping as > > being superior in some respect? > > yes. > > Yakov. > Eric, Yakov, Draft-pan-lsp-ping-00.txt and draft-bonica-tunproto-00 are not competitors to one another. One proposes an "ping", the other proposes a "traceroute". Ping, Shouldn't the mechanism be generalized? Possibly made independant of the signaling mechanism? Don't LSPs that are established by LDP (or foo) need this functionality, too? Also, wouldn't this functionality also be useful for non-MPLS tunnels? Ron From owner-mpls@UU.NET Wed Jul 11 01:18: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 BAA11581 for ; Wed, 11 Jul 2001 01:18: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 QQkxeb01408; Wed, 11 Jul 2001 05:18:42 GMT Received: by mail-control.mail.uu.net id QQkxeb09718 for mpls-outgoing; Wed, 11 Jul 2001 05:18: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 QQkxeb09710 for ; Wed, 11 Jul 2001 05:17: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 QQkxeb12861 for ; Wed, 11 Jul 2001 05:17:01 GMT Received: from inet-tsb.toshiba.co.jp by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQkxeb10934 for ; Wed, 11 Jul 2001 05:16:59 GMT Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id OAA10844; Wed, 11 Jul 2001 14:16:52 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA23239; Wed, 11 Jul 2001 14:16:52 +0900 (JST) Received: from chappy.isl.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id OAA10451; Wed, 11 Jul 2001 14:16:51 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by chappy.isl.rdc.toshiba.co.jp (8.11.3/8.11.3) with ESMTP id f6B5FhS08798; Wed, 11 Jul 2001 14:15:43 +0900 (JST) Date: Wed, 11 Jul 2001 14:15:40 +0900 Message-ID: From: Ken Nagami To: Ping Pan Cc: mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-Reply-To: <3B4B2080.B9BC992B@juniper.net> References: <200107091937.PAA11274@telescope.cisco.com> <3B4A61D5.2CD45413@juniper.net> <3B4B2080.B9BC992B@juniper.net> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) Organization: Toshiba MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 49 Sender: owner-mpls@UU.NET Precedence: bulk Hi Ping, Robert, Thank you for your explanation. I understand your point. A hop-by-hop control plane, which is a return path for the LSP-ping is needed on this mechanism. Ping, Do you think that the mechanism is generalized? I think a generalized mechanism for the LSP-ping is more useful. >> Ken Nagami wrote: >> >> Hi Ping, >> >> >> You don't give a message type for the LSP-ping. Were you thinking of >> >> a new message? Perhaps the Notify message could be used? >> >> >> >> >> For LSP-ping messages, the echo packets are encapsulated in UDP with a >> >> well-known port number. At the egress, the LSR picks up the echo by >> >> "listening" to the UDP port, and replies them back in Resv. I didn't >> >> consider the Notify message.... Let me think about it. >> >> Why do you use a RSVP RESV message for an LSP-ping reply? >> I think it is better to use an UDP packet which is the same as >> LSP-ping echo message. If you don't use an MPLS control >> message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for >> all kind of LSP, such as a static LSP and an LSP established by LDP. >> >> Ken, >> LSP-ping is used to probe the data path. There are cases where the data >> path goes wrong, and you have no idea where the problem is (forwarding >> LSP, reverse LSP, ...). Since the only operational path that you can >> count is the control path, so you reply via RSVP. >> If you use UDP to return the reply, what if the returning path is >> broken? Should the user assumes the forwarding LSP is bad, or the >> reverse? >> At the same time, if you can come up with a simple, scalable, backward >> compatible method to use for LDP (including the case where you can label >> merging) as well, please do let us know. :-) >> - Ping From owner-mpls@UU.NET Wed Jul 11 02:04: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 SMTP id CAA22953 for ; Wed, 11 Jul 2001 02:04: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 QQkxee03787; Wed, 11 Jul 2001 06:03:53 GMT Received: by mail-control.mail.uu.net id QQkxee23887 for mpls-outgoing; Wed, 11 Jul 2001 06:03: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 QQkxee23879 for ; Wed, 11 Jul 2001 06:03: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 QQkxee22322 for ; Wed, 11 Jul 2001 06:02:44 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 QQkxee01696 for ; Wed, 11 Jul 2001 06:02:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA17819 for mpls@uu.net; Wed, 11 Jul 2001 02:02:43 -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 QQkxee21100 for ; Wed, 11 Jul 2001 06:02:07 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 QQkxed19586 for ; Wed, 11 Jul 2001 05:59:52 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxed24560 for ; Wed, 11 Jul 2001 05:59:51 GMT Received: from juniper.net ([172.16.167.234]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6B5xhH40251; Tue, 10 Jul 2001 22:59:43 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B4BECAE.4D0B1C50@juniper.net> Date: Tue, 10 Jul 2001 23:05:34 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Bonica CC: Yakov Rekhter , erosen@cisco.com, Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ron, Ron Bonica wrote: > > Ping, > > Shouldn't the mechanism be generalized? It should. > Possibly made independant of the signaling mechanism? Agree, if we don't introduce more potential code bugs and network instability with the new approach. :-) > Don't LSPs that are established by LDP (or foo) need > this functionality, too? They do. Actually, we have thought about this for a while. Unfortunately, LDP and RSVP-TE are two very different protocols. Having a generic mechanism to cover both cases can make the whole thing complex, and hard to deploy, and hard to implement and debug. If you have ideas on this topic, let's talk. If you look at our proposal, when it is used, the existing MPLS operation inside the network is not disturbed at all. The processing overhead on the LSR's is very small. And the implementation won't be very difficult. > > Also, wouldn't this functionality also be useful for non-MPLS tunnels? > The lsp-ping proposal is to solve the problem where control-plane cannot detect data-plane failure. Would it happen to non-MPLS tunnels? Regards, - Ping From owner-mpls@UU.NET Wed Jul 11 02:29: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 CAA26152 for ; Wed, 11 Jul 2001 02:29: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 QQkxef20299; Wed, 11 Jul 2001 06:29:24 GMT Received: by mail-control.mail.uu.net id QQkxef04910 for mpls-outgoing; Wed, 11 Jul 2001 06:28: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 QQkxef04895 for ; Wed, 11 Jul 2001 06:28: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 QQkxef17259 for ; Wed, 11 Jul 2001 06:25:35 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 QQkxef19960 for ; Wed, 11 Jul 2001 06:25:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA19085 for mpls@uu.net; Wed, 11 Jul 2001 02:25: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 QQkxef04645 for ; Wed, 11 Jul 2001 06:24:54 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 QQkxef07564 for ; Wed, 11 Jul 2001 06:24:01 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxef05024 for ; Wed, 11 Jul 2001 06:24:01 GMT Received: from juniper.net ([172.16.167.234]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6B6NrH40744; Tue, 10 Jul 2001 23:23:53 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B4BF259.3D23FF3B@juniper.net> Date: Tue, 10 Jul 2001 23:29:45 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Nagami CC: mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107091937.PAA11274@telescope.cisco.com> <3B4A61D5.2CD45413@juniper.net> <3B4B2080.B9BC992B@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ken, Ken Nagami wrote: > > Ping, > > Do you think that the mechanism is generalized? > I think a generalized mechanism for the LSP-ping is more useful. > Say, one major advantage of having a generalized mechanism is to make the problem easier to handle. Instead of solving the problem for one protocol, it can solve the problem for other protocols as well. However, if the protocols are very different in nature, the generic solution can become quite complex. It may be complex to design, complex to develop, and complex to deploy. In this case, we may be better off to develop a separate and simple approach for each protocol. Back to RSVP-TE vs. LDP, both will work to setup LSP's, but they are very very different. If you look at other features in MPLS, such as fast-reroute and graceful restart, we have to design separate solutions for both protocols. At the end, it's all about to get things working on-time, instead of spending all the precious time to design a kitchen sink that can solve all the problem in the world, but late to market. 2 cents, - Ping From owner-mpls@UU.NET Wed Jul 11 05:23: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 FAA28875 for ; Wed, 11 Jul 2001 05:23: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 QQkxer01340; Wed, 11 Jul 2001 09:23:35 GMT Received: by mail-control.mail.uu.net id QQkxer21811 for mpls-outgoing; Wed, 11 Jul 2001 09: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 QQkxer21795 for ; Wed, 11 Jul 2001 09:22:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxer28847 for ; Wed, 11 Jul 2001 09:22:20 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 QQkxer08017 for ; Wed, 11 Jul 2001 09:22:19 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Wed, 11 Jul 2001 10:21:07 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 11 Jul 2001 10:21:19 +0100 Message-ID: To: pingpan@juniper.net Cc: mpls@UU.NET, mpls-ops@mplsrc.com Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Wed, 11 Jul 2001 10:21:20 +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 Ping Pan wrote 11 July 2001 07:30 > Ken Nagami wrote: > > > > Ping, > > > > Do you think that the mechanism is generalized? > > I think a generalized mechanism for the LSP-ping is more useful. > > > > Say, one major advantage of having a generalized mechanism is to make > the problem easier to handle. Instead of solving the problem for one > protocol, it can solve the problem for other protocols as > well. However, > if the protocols are very different in nature, the generic > solution can > become quite complex. It may be complex to design, complex to develop, > and complex to deploy. In this case, we may be better off to develop a > separate and simple approach for each protocol. NH=> Piecemeal solutions can come back to haunt you later. I believe the correct approach here is as I tried to define in my earlier mail.....which in summary is: - define the problem being addressed, eg identify all defects, agree their specification and consequent fault/alarm handling.....we need as much consistency of approach here as possible; - accept that data-plane and control-planes require independent OAM considerations......this way the data plane defect handling should work for all control-plane cases, and even the degenerate case of no control-plane. > > Back to RSVP-TE vs. LDP, both will work to setup LSP's, but they are > very very different. NH=> This is true. The former (like CR-LDP) is essentially aimed at a pt-pt mode of operation, whereas the latter is essentially aimed at a merging mpt-pt mode of operation. This is fundamentally different data plane behaviour. Indeed, I could argue that LDP does not create layer networks but is simply an adjunct process to enable more efficient plain cnls/hop-hop IGP-based routing; whereas RSVP-TE and CR-LDP do create layer networks since they create topological trails that are disjoint from the cnls/hop-hop IGP_based routing. So IMO RSVP-TE and CR-LDP modes should use the same OAM solution if possible (this would also make interworking easier)......LDP is a special case since it does not create pt-pt trails and needs its own solution. > If you look at other features in MPLS, such as > fast-reroute and graceful restart, we have to design separate > solutions > for both protocols. At the end, it's all about to get things working > on-time, instead of spending all the precious time to design a kitchen > sink that can solve all the problem in the world, but late to market. NH=> More haste can mean less real speed.....its no good rushing to market with solutions if you have not first checked with your customers that they will buy them. It would also be useful Ping if you explain what is wrong with the OAM work we have submitted.....we really tried to take a comprehensive and signalling protocol agnostic approach, and we don't think it is that complex. Thanks, Neil From owner-mpls@UU.NET Wed Jul 11 05:38:51 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 FAA29045 for ; Wed, 11 Jul 2001 05:38:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxes05375; Wed, 11 Jul 2001 09:39:14 GMT Received: by mail-control.mail.uu.net id QQkxes23378 for mpls-outgoing; Wed, 11 Jul 2001 09:38: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 QQkxes23347 for ; Wed, 11 Jul 2001 09:38:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxes16588 for ; Wed, 11 Jul 2001 09:38:14 GMT Received: from tju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver.tju.edu.cn [202.113.15.13]) id QQkxes03180 for ; Wed, 11 Jul 2001 09:38:13 GMT Received: from rose.tju.edu.cn (rose.tju.edu.cn [202.113.0.9]) by tju.edu.cn (8.9.1b+Sun/8.9.1) with ESMTP id RAA00038 for ; Wed, 11 Jul 2001 17:30:49 +0800 (CST) Received: from eae ([202.113.4.43]) by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id RAA01389 for ; Wed, 11 Jul 2001 17:29:20 +0800 Message-Id: <200107110929.RAA01389@rose.tju.edu.cn> Date: Wed, 11 Jul 2001 17:37:37 +0800 From: STONE CHEN To: "'mpls@uu.net'" Subject: Explicit null label ? X-Priority: 5 (Lowest) X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_Dragon441415466323_=====" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --=====_Dragon441415466323_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Hi All, In an MPLS network that supports TE, the constraint-based routing is done via CR-LDP or RSVP-TE signaling. My question is which one of the following methods have people adapted or is envisioned to be superior: 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet with label=0 (explicit null label). Thanks, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 <> --=====_Dragon441415466323_===== Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkRhdmFyaTtTaGFocmFtDQpGTjpTaGFocmFtIERh dmFyaQ0KT1JHOlBNQy1TaWVycmEsIEluYy47UiZEIFJlc2VhcmNoIE90dGF3YS0xMDkyMDMNClRJ VExFOlByb2R1Y3QgUmVzZWFyY2ggRW5naW5lZXINClRFTDtXT1JLO1ZPSUNFOisxIDYxMyAyNzEg NDAxOA0KQURSO1dPUks6O090dGF3YTtLYW5hdGEgUmVzZWFyY2ggUGFyaywgU3VpdGUgODM0LCBP ZmZpY2UgVG93ZXIgQiwgNTU1IExlZ2dldCBEcml2ZTtLYW5hdGE7T250YXJpbztLMksgMlgzO0Nh bmFkYQ0KTEFCRUw7V09SSztFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOk90dGF3YT0wRD0wQUth bmF0YSBSZXNlYXJjaCBQYXJrLCBTdWl0ZSA4MzQsIE9mZmljZSBUb3dlciBCLCA1NTUgTGVnZ2V0 IERyaXY9DQplPTBEPTBBS2FuYXRhLCBPbnRhcmlvIEsySyAyWDM9MEQ9MEFDYW5hZGENCkVNQUlM O1BSRUY7SU5URVJORVQ6U2hhaHJhbV9EYXZhcmlAcG1jLXNpZXJyYS5jb20NClJFVjoyMDAxMDEx MlQyMTM3MTdaDQpFTkQ6VkNBUkQNCg0K --=====_Dragon441415466323_=====-- From owner-mpls@UU.NET Wed Jul 11 09:20: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 JAA02632 for ; Wed, 11 Jul 2001 09:20: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 QQkxfh28596; Wed, 11 Jul 2001 13:19:43 GMT Received: by mail-control.mail.uu.net id QQkxfh08751 for mpls-outgoing; Wed, 11 Jul 2001 13:19: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 QQkxfh08743 for ; Wed, 11 Jul 2001 13:19: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 QQkxfh10185 for ; Wed, 11 Jul 2001 13:15:59 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxfh21521 for ; Wed, 11 Jul 2001 13:15:59 GMT Message-ID: <3B4C518E.F0859A1B@sandburst.com> Date: Wed, 11 Jul 2001 09:15:58 -0400 From: Eric Gray MIME-Version: 1.0 To: anouk@ureach.com Cc: mpls@UU.NET, David Charlap Subject: Re: Label Spaces and Uniqueness References: <200107102047.QAA11129@www22.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk, Support for PHP is not exactly required, but not supporting it will cause problems when trying to interwork with an implementation that wants to use it. However the egress LSR controls whether or not it is used. This is why I have been saying that it is possible, as a local matter, for the egress from an LSP to associate some context with that LSP and apply that context when considering a subsequent label. You asserted that there was no reason why an LSP signaling protocol might be forced to use a single label space and asked if you might have missed something. I was responding with the PHP scenario mostly for clarification. -- Eric Gray You wrote: > Eric, > > I am sorry I mis-wrote. You are absolutely right (and you did > answer my question except for the follow on below). > > I meant that the "outer" label is established by RSVP TE and the > inner by LDP. According to the martini drafts, the inner label > is usually associate with a layer 2 entity like frame-relay DLCI. > > I see your point about problems with independent label spaces > operating at different levels of the stack if PHP is used. > However, is it a MUST (in ietf terminology) to support PHP? > Ie if I have network which does not rely on PHP, is it otherwise > reasonable to allow independent label spaces - in the above example > one for the inside of a network (outer label, using rsvp-te) and > one for the edges (inner-label, using LDP). > > Thanks! > Anouk. > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > > ---- On Tue, 10 Jul 2001, Eric Gray (eric.gray@sandburst.com) wrote: > > > Anouk, > > > > I assume that David can answer for himself, however I would like to > > get some things clarified. Please see comments/questions below. > > > > Anouk Rocher wrote: > > > > > David, > > > > > > Let me clarify with a more specific example. Lets say we want > > > to deploy one of the l2 vpn mechanisms - say the one in > > draft-maritini-* > > > The inner label there is negotiated between the ingress and egress > > > LSRs via LDP (sort of multi-hop). The inner label is negotiated (say) > > > via RSVP-TE. > > > > I believe one of these should be 'outer label'. I assume you mean > > higher > > level, when you say 'outer' and lower level when you say 'inner' but, > > even > > so, I am not sure which should be which in your description above (just > > that they cannot both be the same). > > > > Would you recast your question somehow distinguishing which is which? > > > > > > > > > > > I don't see a reason why LDP and RSVP-TE be forced to use the same > > > label space in this case. (I am sure there are similar cases while > > > using wavelengths as labels.) > > > > > > Am I missing something obvious? > > > > So, one reason would be if PHP is used. In this case, the egress for > > the > > lower level label will not have received the higher level label and will > > not > > be able to distinguish it from other labels it receives from the > > penultimate > > hop. Give that this is the case, then the egress LSR must not > > distribute > > a label to be used by the remote LSR at the other end of the LSP tunnel > > with a different meaning then an identical label distributed to the > > local > > LSR that happens to be the punultimate hop for the LSP tunnel. > > > > This is an example of when the label space MUST be the same. Does this > > answer your question? From owner-mpls@UU.NET Wed Jul 11 09:48: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 JAA03261 for ; Wed, 11 Jul 2001 09:48: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 QQkxfj27178; Wed, 11 Jul 2001 13:47:11 GMT Received: by mail-control.mail.uu.net id QQkxfj10949 for mpls-outgoing; Wed, 11 Jul 2001 13:46:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxfj10939 for ; Wed, 11 Jul 2001 13:46:27 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 QQkxfj13526 for ; Wed, 11 Jul 2001 13:45:42 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 QQkxfj24780 for ; Wed, 11 Jul 2001 13:45:41 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA19071 for ; Wed, 11 Jul 2001 09:45:40 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07978 for mpls@uu.net; Wed, 11 Jul 2001 09:45:37 -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 QQkxff16022 for ; Wed, 11 Jul 2001 12:55: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 QQkxff18329 for ; Wed, 11 Jul 2001 12:53:19 GMT Received: from web14101.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14101.mail.yahoo.com [216.136.172.131]) id QQkxff01851 for ; Wed, 11 Jul 2001 12:53:19 GMT Message-ID: <20010711125318.75325.qmail@web14101.mail.yahoo.com> Received: from [192.11.221.117] by web14101.mail.yahoo.com via HTTP; Wed, 11 Jul 2001 05:53:18 PDT Date: Wed, 11 Jul 2001 05:53:18 -0700 (PDT) From: Jane Jiang Subject: rfc3035 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 have a question regarding a paragraph on page 2 of rfc3035, "This label distribution technique MUST be used by ATM-LSRs that are not capable of "VC merge", and is OPTIONAL for ATM-LSRs that are capable of VC merge.". I don't understand why the words "MUST" and "OPTIONAL" should be used respectively here. Regards, Jane D. Jiang __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 11 09:58: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 JAA03594 for ; Wed, 11 Jul 2001 09:58: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 QQkxfj09306; Wed, 11 Jul 2001 13:58:09 GMT Received: by mail-control.mail.uu.net id QQkxfj12202 for mpls-outgoing; Wed, 11 Jul 2001 13:57:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxfj12194 for ; Wed, 11 Jul 2001 13:57:18 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 QQkxfj02191 for ; Wed, 11 Jul 2001 13:55:24 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkxfj14036 for ; Wed, 11 Jul 2001 13:55:23 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA20190 for ; Wed, 11 Jul 2001 09:55:22 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08037 for mpls@uu.net; Wed, 11 Jul 2001 09:55: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 QQkxfj11316 for ; Wed, 11 Jul 2001 13:50: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 QQkxfi20415 for ; Wed, 11 Jul 2001 13:44:46 GMT Received: from web14108.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14108.mail.yahoo.com [216.136.172.138]) id QQkxfi23337 for ; Wed, 11 Jul 2001 13:44:45 GMT Message-ID: <20010711134445.32078.qmail@web14108.mail.yahoo.com> Received: from [192.11.221.117] by web14108.mail.yahoo.com via HTTP; Wed, 11 Jul 2001 06:44:45 PDT Date: Wed, 11 Jul 2001 06:44:45 -0700 (PDT) From: Jane Jiang Subject: Voice over 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, Would anyone please know what the related work is on VoMPLS? What is the status of the paper "Voice over MPLS Framework" by A. Kankkunen and so on? Thanks a lot. Regards, Jane D. Jiang __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 11 10:12:47 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 KAA04097 for ; Wed, 11 Jul 2001 10:12: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 QQkxfk04904; Wed, 11 Jul 2001 14:11:40 GMT Received: by mail-control.mail.uu.net id QQkxfk04846 for mpls-outgoing; Wed, 11 Jul 2001 14: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 QQkxfk04790 for ; Wed, 11 Jul 2001 14:10: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 QQkxfk07527 for ; Wed, 11 Jul 2001 14:10:33 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkxfk12001 for ; Wed, 11 Jul 2001 14:10:33 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA21777; Wed, 11 Jul 2001 10:10:24 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA08084; Wed, 11 Jul 2001 10:10:21 -0400 (EDT) Message-Id: <200107111410.KAA08084@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Ron Bonica , Yakov Rekhter cc: Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Tue, 10 Jul 2001 23:18:12 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Jul 2001 10:10:21 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Ron> Draft-pan-lsp-ping-00.txt and draft-bonica-tunproto-00 are not Ron> competitors to one another. One proposes an "ping", the other proposes Ron> a "traceroute". I don't see this. Generally you use ping to detect (or verify) that there's a problem, and traceroute to get diagnostic info. Ordinary ICMP ping will detect that there's a problem, you don't need LSP-ping for this. LSP-ping may tell you that the fault is not due to particular LSP, but I think the tunproto stuff would tell you that as well. So I don't see that LSP-ping provides an additional capability. Yakov, your message seems to have been truncated by the mailing system. I didn't get the part where you explain why the LSP-ping mechanism is superior to the tunproto mechanism. Please resend. I guess I'm also having some trouble understanding why the LSP-ping mechanism needs to be specific to a particular control protocol. Why not just use a UDP packet to send the response back to the tunnel head? It won't necessarily travel back along the control path, but does that really matter? From owner-mpls@UU.NET Wed Jul 11 10:16: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 KAA04209 for ; Wed, 11 Jul 2001 10:16: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 QQkxfl21312; Wed, 11 Jul 2001 14:16:17 GMT Received: by mail-control.mail.uu.net id QQkxfl05873 for mpls-outgoing; Wed, 11 Jul 2001 14:15: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 QQkxfl05864 for ; Wed, 11 Jul 2001 14:15: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 QQkxfk10984 for ; Wed, 11 Jul 2001 14:14:54 GMT Received: from drawbridge.ascend.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: drawbridge.ascend.com [198.4.92.1]) id QQkxfk12148 for ; Wed, 11 Jul 2001 14:14:53 GMT Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id HAA26101 for ; Wed, 11 Jul 2001 07:14:08 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 11 Jul 2001 14:14:52 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA14499 for ; Wed, 11 Jul 2001 07:13:39 -0700 (PDT) Received: from medoc.eng.ascend.com (medoc.eng.ascend.com [135.87.47.20]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id HAA25714 for ; Wed, 11 Jul 2001 07:14:50 -0700 (PDT) Received: from FR0016LTSHARES (emea-eng-dhcp-004.eng.ascend.com [135.87.47.204]) by medoc.eng.ascend.com (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with SMTP id <0GGB00DGRBOKWP@medoc.eng.ascend.com> for mpls@UU.NET; Wed, 11 Jul 2001 16:17:08 +0200 (MET DST) Date: Wed, 11 Jul 2001 16:14:49 +0200 From: Steve Hares Subject: RSVP-TE and monitoring links To: "'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="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Trying hard to find anything in all the RSVP-TE specs that defines away to monitor available bandwidth on a path between two LSR's. I'm looking for a way to tell that a link anywhere in an LSP could not reserve a certain amount of bandwidth. This would be used to tell a switch to stop sending anymore VoIP calls to the edge device since any attempt to allocate resources in the LSP would fail. Any help would be greatly appreciated. Steve ================================ Steve Hares Senior Software Manager Lucent Technologies - INS 400 Avenue Roumanille 06910 Sophia Antipolis France +33 4 92 38 63 08 (office) +33 4 92 38 62 70 (fax) +33 6 12 49 85 44 (mobile) From owner-mpls@UU.NET Wed Jul 11 13:03: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 SMTP id NAA11470 for ; Wed, 11 Jul 2001 13:03: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 QQkxfw10445; Wed, 11 Jul 2001 17:03:19 GMT Received: by mail-control.mail.uu.net id QQkxfw06426 for mpls-outgoing; Wed, 11 Jul 2001 17:02: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 QQkxfw05961 for ; Wed, 11 Jul 2001 17:02: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 QQkxfw00235 for ; Wed, 11 Jul 2001 17:01:48 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 QQkxfw16255 for ; Wed, 11 Jul 2001 17:01:47 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA23888 for mpls@uu.net; Wed, 11 Jul 2001 13:01:45 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxfv00094 for ; Wed, 11 Jul 2001 16:57: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 QQkxfv12692 for ; Wed, 11 Jul 2001 16:56:55 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 QQkxfv21232 for ; Wed, 11 Jul 2001 16:56:54 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6BGT3l02798; Wed, 11 Jul 2001 09:52:54 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp31.cisco.com [10.50.0.30]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAA10793 (AUTH rraszuk); Wed, 11 Jul 2001 09:28:42 -0700 (PDT) Message-ID: <3B4C7E42.964AE872@cisco.com> Date: Wed, 11 Jul 2001 09:26:42 -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: erosen@cisco.com CC: Ron Bonica , Yakov Rekhter , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107111410.KAA08084@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, > I guess I'm also having some trouble understanding why the LSP-ping > mechanism needs to be specific to a particular control protocol. Why not > just use a UDP packet to send the response back to the tunnel head? It > won't necessarily travel back along the control path, but does that really > matter? It may disappear the same way as the original icmp test so the head will assume that LSP is down while it is in fact up. R. From owner-mpls@UU.NET Wed Jul 11 13:16: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 NAA12035 for ; Wed, 11 Jul 2001 13:16: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 QQkxfx13708; Wed, 11 Jul 2001 17:15:41 GMT Received: by mail-control.mail.uu.net id QQkxfw21567 for mpls-outgoing; Wed, 11 Jul 2001 17:14: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 QQkxfw21550 for ; Wed, 11 Jul 2001 17:14:48 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 QQkxfw10618 for ; Wed, 11 Jul 2001 17:11:57 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 QQkxfw25266 for ; Wed, 11 Jul 2001 17:11:56 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA13680; Wed, 11 Jul 2001 13:11:48 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA08742; Wed, 11 Jul 2001 13:11:45 -0400 (EDT) Message-Id: <200107111711.NAA08742@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: raszuk@cisco.com cc: Ron Bonica , Yakov Rekhter , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Wed, 11 Jul 2001 09:26:42 -0700. <3B4C7E42.964AE872@cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Jul 2001 13:11:44 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> I guess I'm also having some trouble understanding why the LSP-ping Eric> mechanism needs to be specific to a particular control protocol. Why Eric> not just use a UDP packet to send the response back to the tunnel Eric> head? It won't necessarily travel back along the control path, but Eric> does that really matter? Robert> It may disappear the same way as the original icmp test so the head Robert> will assume that LSP is down while it is in fact up. We just need to invent a way to ensure that the UDP packet follows the IP hop-by-hop path, rather than being sent through an LSP. That would eliminate the worry about MPLS data plane problems in the reverse direction. It does leave a hole in the situation where the RSVP-TE control plane is working although there is no IP connectivity from the tail to the head, but that doesn't seem like too big of a hole. From owner-mpls@UU.NET Wed Jul 11 14:00: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 OAA13714 for ; Wed, 11 Jul 2001 14:00: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 QQkxga18696; Wed, 11 Jul 2001 18:00:06 GMT Received: by mail-control.mail.uu.net id QQkxfz26936 for mpls-outgoing; Wed, 11 Jul 2001 17:59: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 QQkxfz26919 for ; Wed, 11 Jul 2001 17:59: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 QQkxfz25361 for ; Wed, 11 Jul 2001 17:53:57 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 QQkxfz08276 for ; Wed, 11 Jul 2001 17:53:56 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA20629 for ; Wed, 11 Jul 2001 13:53:54 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA08938 for mpls@uu.net; Wed, 11 Jul 2001 13:53: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 QQkxfs09405 for ; Wed, 11 Jul 2001 16:01: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 QQkxfr28057 for ; Wed, 11 Jul 2001 15:58:41 GMT Received: from mailweb26.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [203.199.83.30]) id QQkxfr26243 for ; Wed, 11 Jul 2001 15:58:40 GMT Received: (qmail 8500 invoked by uid 510); 11 Jul 2001 16:04:04 -0000 Date: 11 Jul 2001 16:04:04 -0000 Message-ID: <20010711160404.8499.qmail@mailweb26.rediffmail.com> Received: from unknown (164.164.56.2) by rediffmail.com via HTTP; 11 Jul 2001 16:04:04 -0000 MIME-Version: 1.0 To: "mpls@UU.NET" Subject: Help Please CC: "mpls-ops@mplsrc.com" From: "john p p" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi I am student working on MPLS project. I downloaded the source code of MPLS linux patch form source fourge site. I wanted to know how and where this code in patch, communicates with the Layer-2 and layer-3. Please help me. Thanks in advance. John. ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm From owner-mpls@UU.NET Wed Jul 11 14:02:34 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 OAA13808 for ; Wed, 11 Jul 2001 14:02:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxga22705; Wed, 11 Jul 2001 18:01:39 GMT Received: by mail-control.mail.uu.net id QQkxga00862 for mpls-outgoing; Wed, 11 Jul 2001 18:01: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 QQkxga00534 for ; Wed, 11 Jul 2001 18:00:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxga02171 for ; Wed, 11 Jul 2001 18:00:17 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxga19054 for ; Wed, 11 Jul 2001 18:00:17 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6BI07H61594; Wed, 11 Jul 2001 11:00:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200107111800.f6BI07H61594@merlot.juniper.net> To: erosen@cisco.com cc: raszuk@cisco.com, Ron Bonica , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-Reply-To: Your message of "Wed, 11 Jul 2001 13:11:44 EDT." <200107111711.NAA08742@erosen-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <57018.994874404.1@juniper.net> Date: Wed, 11 Jul 2001 11:00:06 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Eric, > Eric> I guess I'm also having some trouble understanding why the LSP-ping > Eric> mechanism needs to be specific to a particular control protocol. Why > Eric> not just use a UDP packet to send the response back to the tunnel > Eric> head? It won't necessarily travel back along the control path, but > Eric> does that really matter? > > Robert> It may disappear the same way as the original icmp test so the head > Robert> will assume that LSP is down while it is in fact up. > > We just need to invent a way to ensure that the UDP packet follows the IP > hop-by-hop path, rather than being sent through an LSP. or just use what is described in draft-pan-lsp-ping-00.txt. Yakov. From owner-mpls@UU.NET Wed Jul 11 14:26: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 OAA14719 for ; Wed, 11 Jul 2001 14:26: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 QQkxgb05674; Wed, 11 Jul 2001 18:25:23 GMT Received: by mail-control.mail.uu.net id QQkxgb19477 for mpls-outgoing; Wed, 11 Jul 2001 18:24: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 QQkxgb19459 for ; Wed, 11 Jul 2001 18:24: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 QQkxgb20806 for ; Wed, 11 Jul 2001 18:18:34 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 QQkxgb12306 for ; Wed, 11 Jul 2001 18:18:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA01383 for mpls@uu.net; Wed, 11 Jul 2001 14:18:33 -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 QQkxgb18926 for ; Wed, 11 Jul 2001 18:17:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxgb17479 for ; Wed, 11 Jul 2001 18:17:06 GMT Received: from malone.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malone.cisco.com [171.70.157.157]) id QQkxgb09305 for ; Wed, 11 Jul 2001 18:17:05 GMT Received: from kehong1-w2k.cisco.com (ch2-dhcp134-174.cisco.com [161.44.134.174]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA26147; Wed, 11 Jul 2001 11:17:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711131512.03edfde8@malone.cisco.com> X-Sender: kehong@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 13:17:01 -0500 To: mpls@UU.NET From: Kenny Hong Subject: draft-ietf-mpls-diff-ext-09.txt Cc: kehong@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is draft-ietf-mpls-diff-ext-09.txt close to being submitted? If so which WG? Thanks, Ken ______________________________________________________________ Cisco Systems Voice: (469) 737-1541 Kenny Hong Mobil: (214) 616-8504 Consulting SE - Wcom Ops Pager: (800) 365-4578 18581 N. Dallas Pkwy, Suite 100 Fax: (469) 737-1599 Dallas, Tx 75287 Email: kehong@cisco.com ______________________________________________________________ From owner-mpls@UU.NET Wed Jul 11 14:43: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 OAA15460 for ; Wed, 11 Jul 2001 14:43: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 QQkxgc02411; Wed, 11 Jul 2001 18:42:15 GMT Received: by mail-control.mail.uu.net id QQkxgc21211 for mpls-outgoing; Wed, 11 Jul 2001 18:41: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 QQkxgc21119 for ; Wed, 11 Jul 2001 18:41: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 QQkxgc02066 for ; Wed, 11 Jul 2001 18:40:58 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 QQkxgc21288 for ; Wed, 11 Jul 2001 18:40:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA03396 for mpls@uu.net; Wed, 11 Jul 2001 14:40:56 -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 QQkxgc20903 for ; Wed, 11 Jul 2001 18:40:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxgc27510 for ; Wed, 11 Jul 2001 18:38:39 GMT Received: from nero.doit.wisc.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQkxgc17776 for ; Wed, 11 Jul 2001 18:38:39 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id NAA32176; Wed, 11 Jul 2001 13:14:31 -0500 Date: Wed, 11 Jul 2001 13:14:30 -0500 From: "James R. Leu" To: john p p Cc: "mpls@UU.NET" , "mpls-ops@mplsrc.com" Subject: Re: Help Please Message-ID: <20010711131430.E32031@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com References: <20010711160404.8499.qmail@mailweb26.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010711160404.8499.qmail@mailweb26.rediffmail.com>; from johnp2@rediffmail.com on Wed, Jul 11, 2001 at 04:04:04PM -0000 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Start out by joining the 'MPLS for Linux' mailing list and post there :-) http://lists.sourceforge.net/lists/listinfo/mpls-linux-general Jim On Wed, Jul 11, 2001 at 04:04:04PM -0000, john p p wrote: > Hi > I am student working on MPLS project. > I downloaded the source code of MPLS linux patch form source fourge site. I wanted to know how and where this code in patch, communicates with the Layer-2 and layer-3. > Please help me. > > Thanks in advance. > > John. > > > ____________________________________________________ > Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm > -- James R. Leu From owner-mpls@UU.NET Wed Jul 11 15:06: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 PAA16388 for ; Wed, 11 Jul 2001 15:06: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 QQkxge16275; Wed, 11 Jul 2001 19:05:47 GMT Received: by mail-control.mail.uu.net id QQkxge02574 for mpls-outgoing; Wed, 11 Jul 2001 19:05: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 QQkxge02456 for ; Wed, 11 Jul 2001 19:05:09 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 QQkxge07591 for ; Wed, 11 Jul 2001 19:03:27 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 QQkxge01518 for ; Wed, 11 Jul 2001 19:03:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA05426 for mpls@uu.net; Wed, 11 Jul 2001 15:03:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxge26842 for ; Wed, 11 Jul 2001 19:01: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 QQkxge11896 for ; Wed, 11 Jul 2001 19:01:12 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkxge06454 for ; Wed, 11 Jul 2001 19:01:12 GMT Received: (qmail 20275 invoked by uid 104); 11 Jul 2001 19:01:11 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.401472 secs); 11/07/2001 12:01:10 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 11 Jul 2001 19:01:10 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6BJ1BP15473; Wed, 11 Jul 2001 12:01:11 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jul 2001 12:06:22 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D6E@BBY1EXM01> From: Shahram Davari To: "'Kenny Hong'" , mpls@UU.NET Subject: RE: draft-ietf-mpls-diff-ext-09.txt Date: Wed, 11 Jul 2001 12:06:18 -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 draft has already passes MPLS and Diffserv WG last calls, and is already submitted to IESG. -Shahram > -----Original Message----- > From: Kenny Hong [mailto:kehong@cisco.com] > Sent: Wednesday, July 11, 2001 2:17 PM > To: mpls@UU.NET > Cc: kehong@cisco.com > Subject: draft-ietf-mpls-diff-ext-09.txt > > > Hi, > > Is draft-ietf-mpls-diff-ext-09.txt close to being submitted? > If so which WG? > > > Thanks, > > Ken > ______________________________________________________________ > Cisco Systems Voice: (469) 737-1541 > Kenny Hong Mobil: (214) 616-8504 > Consulting SE - Wcom Ops Pager: (800) 365-4578 > 18581 N. Dallas Pkwy, Suite 100 Fax: (469) 737-1599 > Dallas, Tx 75287 Email: kehong@cisco.com > ______________________________________________________________ > From owner-mpls@UU.NET Wed Jul 11 15:19:26 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 PAA16804 for ; Wed, 11 Jul 2001 15:19: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 QQkxgf07522; Wed, 11 Jul 2001 19:19:04 GMT Received: by mail-control.mail.uu.net id QQkxgf15320 for mpls-outgoing; Wed, 11 Jul 2001 19:18: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 QQkxgf15295 for ; Wed, 11 Jul 2001 19:18:09 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 QQkxgf20893 for ; Wed, 11 Jul 2001 19:18:04 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 QQkxgf26550 for ; Wed, 11 Jul 2001 19:18:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA07429 for mpls@uu.net; Wed, 11 Jul 2001 15:18:02 -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 QQkxge11941 for ; Wed, 11 Jul 2001 19:12:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxge29942 for ; Wed, 11 Jul 2001 19:11:03 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 QQkxge23995 for ; Wed, 11 Jul 2001 19:11:01 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6BJA3l24867; Wed, 11 Jul 2001 12:10:05 -0700 (PDT) Received: from cisco.com ([144.254.47.1]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAF04055 (AUTH rraszuk); Wed, 11 Jul 2001 12:09:41 -0700 (PDT) Message-ID: <3B4CA3FA.97A8A4F8@cisco.com> Date: Wed, 11 Jul 2001 12:07:38 -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: erosen@cisco.com CC: Ron Bonica , Yakov Rekhter , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107111711.NAA08742@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, > We just need to invent a way to ensure that the UDP packet follows the IP > hop-by-hop path, rather than being sent through an LSP. Well I am afraid this is not easy. What you need to invent is a way not just for tail not to send the proposed UDP reply the same way as they send ICMP one but also to make sure each subsequent node does the same. If a network would be managed by some offline tool yes the tool's notification by the tail would be enough. If this is attractive solution I don't know - could be an easy LSP-ping reply option. I understand that there is great benefit to eliminate the control plane usage but I am afraid nothing will be as realiable as either RSVP RESV (the assumption is that the LSP is up) or IGP flooding (again control plane). I also fail to come up with anything more simpler then just load this msg on the RSVP RESV. I was watching the thread closely as it addresses one of the most popular recently customer demand in some extent and would say that not going forward with this proposal would hurt live deployed networks or make implementations not interoperable. R. From owner-mpls@UU.NET Wed Jul 11 15:37:53 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 PAA17346 for ; Wed, 11 Jul 2001 15:37: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 QQkxgg10234; Wed, 11 Jul 2001 19:37:38 GMT Received: by mail-control.mail.uu.net id QQkxgg17533 for mpls-outgoing; Wed, 11 Jul 2001 19: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 QQkxgg17493 for ; Wed, 11 Jul 2001 19:36:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxgg13698 for ; Wed, 11 Jul 2001 19:34:56 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxgg08519 for ; Wed, 11 Jul 2001 19:34:56 GMT Message-ID: <3B4CAA5F.148D3D2E@sandburst.com> Date: Wed, 11 Jul 2001 15:34:55 -0400 From: Eric Gray MIME-Version: 1.0 To: Jane Jiang Cc: mpls@UU.NET Subject: Re: rfc3035 References: <20010711125318.75325.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 Jane, Short answer - because it makes sense that way. In general, the combination of non-merging and downstream unsolicited label distribution is difficult to make work. However, the bulk of the work on RFC 3035 was already done before specific support for non-merging was added to LDP and - among label distribution protocols - LDP is the only one which offers a choice between DU and DoD. MPLS BGP only supports DU distribution (merging implied), but would only apply to lower level labels (in the shim layer label stack) in conjunction with ATM LSRs. RSVP-TE and CR-LDP only support DoD distribution. Since the merge capability of an LSR is not part of the information a a peer can reliably determine from label distribution, this statement has little value except to establish a basic set of assumptions used throughout the remainder of the specification; but this might be a huge value. If the statement you point out (also stated in section 8 of the RFC) is complied with exactly, then the fact that an LSR announces it would prefer to use downstream unsolicited label distribution (during LDP session establishment) can be construed to mean that it is merge capable (and this would be likely to be true even if not specified) - but the reverse is not true (asserting DoD does not necessarily mean that an LSR is not merge capable). So it is difficult to see why it might be important, for interoperation with a peer, that this behavior is strictly adhered to - but it might be. Because the base LDP specification supports requesting additional labels for a given FEC irrespective of the merge capability of the LSR, it might be possible for an ATM LSR to pretend to be merge capable even though it is not. But then the implementation would be cheating on the specification and it would fall on the implementer to make sure that the implementation interoperates with specificationally correct implementations. This would require extensive analysis of procedures specified in section 8 of the RFC to ensure that the 'cheat' is not detectable by (i.e. - it would not trip up) a compliant LSR peer. I am not sure what advantage an implementer would expect to achieve through this particular cheat, and the cost might be very high. -- Eric Gray You wrote: > Hi, all, > > I have a question regarding a paragraph on page 2 of > rfc3035, "This label distribution technique MUST be > used by ATM-LSRs that are not capable of "VC merge", > and is OPTIONAL for ATM-LSRs that are capable of VC > merge.". > > I don't understand why the words "MUST" and "OPTIONAL" > should be used respectively here. > > Regards, > Jane D. Jiang > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 11 16:14:26 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 QAA18645 for ; Wed, 11 Jul 2001 16:14: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 QQkxgi16566; Wed, 11 Jul 2001 20:14:37 GMT Received: by mail-control.mail.uu.net id QQkxgi11768 for mpls-outgoing; Wed, 11 Jul 2001 20:14:00 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 QQkxgi11717 for ; Wed, 11 Jul 2001 20:13: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 QQkxgi10239 for ; Wed, 11 Jul 2001 20:10:15 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f23.law11.hotmail.com [64.4.17.23]) id QQkxgi15039 for ; Wed, 11 Jul 2001 20:10:15 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Jul 2001 13:10:15 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 11 Jul 2001 20:10:14 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: erosen@cisco.com, raszuk@cisco.com Cc: rbonica@MCI.NET, yakov@juniper.net, dcooper@gblx.net, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Wed, 11 Jul 2001 16:10:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jul 2001 20:10:15.0042 (UTC) FILETIME=[7F741620:01C10A45] Sender: owner-mpls@UU.NET Precedence: bulk Robert, See my comment below. Irfan Lateef > >Eric> I guess I'm also having some trouble understanding why the >LSP-ping >Eric> mechanism needs to be specific to a particular control protocol. >Why >Eric> not just use a UDP packet to send the response back to the >tunnel >Eric> head? It won't necessarily travel back along the control path, >but >Eric> does that really matter? > >Robert> It may disappear the same way as the original icmp test so the >head >Robert> will assume that LSP is down while it is in fact up. > IF this UDP packet cannot be delivered to the head end, will it not generate an ICMP packet to the tail end? And if it does one can send a message to the NMS. Secondly, if UDP is a concern then why cant we use TCP, open a socket and send the message, so the tail end can be sure that the message will indeed be delivered. >We just need to invent a way to ensure that the UDP packet follows the >IP >hop-by-hop path, rather than being sent through an LSP. That >would >eliminate the worry about MPLS data plane problems in the >reverse >direction. It does leave a hole in the situation where the RSVP-TE >control >plane is working although there is no IP connectivity from the tail to >the >head, but that doesn't seem like too big of a hole. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Jul 11 16:16: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 QAA18707 for ; Wed, 11 Jul 2001 16:16: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 QQkxgj26022; Wed, 11 Jul 2001 20:16:21 GMT Received: by mail-control.mail.uu.net id QQkxgj12174 for mpls-outgoing; Wed, 11 Jul 2001 20:15: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 QQkxgi11821 for ; Wed, 11 Jul 2001 20:14:27 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 QQkxgi15735 for ; Wed, 11 Jul 2001 20:14:09 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 QQkxgi21540 for ; Wed, 11 Jul 2001 20:14:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA22185; Wed, 11 Jul 2001 16:13:55 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA09237; Wed, 11 Jul 2001 16:13:52 -0400 (EDT) Message-Id: <200107112013.QAA09237@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Yakov Rekhter cc: raszuk@cisco.com, Ron Bonica , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Wed, 11 Jul 2001 11:00:06 -0700. <200107111800.f6BI07H61594@merlot.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Jul 2001 16:13:52 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> We just need to invent a way to ensure that the UDP packet follows the Eric> IP hop-by-hop path, rather than being sent through an LSP. Yakov> or just use what is described in draft-pan-lsp-ping-00.txt. The point is to find a simple mechanism that does not depend on a particular control plane. From owner-mpls@UU.NET Wed Jul 11 16:17: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 QAA18733 for ; Wed, 11 Jul 2001 16:17: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 QQkxgj28824; Wed, 11 Jul 2001 20:17:36 GMT Received: by mail-control.mail.uu.net id QQkxgj12183 for mpls-outgoing; Wed, 11 Jul 2001 20:15:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxgi11853 for ; Wed, 11 Jul 2001 20:14:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxgi28877 for ; Wed, 11 Jul 2001 20:13:46 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f173.law11.hotmail.com [64.4.17.173]) id QQkxgi20641 for ; Wed, 11 Jul 2001 20:13:45 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Jul 2001 13:13:45 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 11 Jul 2001 20:13:44 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: raszuk@cisco.com, erosen@cisco.com Cc: rbonica@MCI.NET, yakov@juniper.net, dcooper@gblx.net, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Wed, 11 Jul 2001 16:13:44 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jul 2001 20:13:45.0117 (UTC) FILETIME=[FCAAFCD0:01C10A45] Sender: owner-mpls@UU.NET Precedence: bulk Hi all, The draft-pan-lsp-ping-00.txt address just the detection of errors in the dataplane where as ping is also being used to measure the round-trip-delays. So I would suggest that this draft be extended to atleast the full capability of the IP version of the ping. Namely if the ping packet reached the destination and if there exists an LSP in the reverse direction then it should send the return through that LSP. This will allow the host to measure the round-trip-delays when the LSP is a good bidirectional LSP.( which happen to be one of my requirements!) In fact, taking the idea to the next level, there should be a complete proposal of ICMP over MPLS which may implement all the messages in RFC 792 and come up with a general response from the tail end which is signalling protocol independent. The tunproto-00 draft can be good starting point for this. Dave Allen mentioned earlier in this thread that they are coming out with a draft framework. I agree that there should be one comprehensive solution to all the ICMP related issue. But I want to wait and see if they address these issues. My 2 cents. Irfan Lateef >From: Robert Raszuk >Reply-To: raszuk@cisco.com >To: erosen@cisco.com >CC: Ron Bonica , Yakov Rekhter , >Dave Cooper , mpls-list , mpls-ops > >Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] >Date: Wed, 11 Jul 2001 12:07:38 -0700 > >Eric, > > > We just need to invent a way to ensure that the UDP packet follows >the IP > > hop-by-hop path, rather than being sent through an LSP. > >Well I am afraid this is not easy. What you need to invent is a way not >just for tail not to send the proposed UDP reply the same way as they >send ICMP one but also to make sure each subsequent node does the same. >If a network would be managed by some offline tool yes the tool's >notification by the tail would be enough. If this is attractive solution >I don't know - could be an easy LSP-ping reply option. > >I understand that there is great benefit to eliminate the control plane >usage but I am afraid nothing will be as realiable as either RSVP RESV >(the assumption is that the LSP is up) or IGP flooding (again control >plane). I also fail to come up with anything more simpler then just load >this msg on the RSVP RESV. > >I was watching the thread closely as it addresses one of the most >popular recently customer demand in some extent and would say that not >going forward with this proposal would hurt live deployed networks or >make implementations not interoperable. > >R. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Jul 11 16:22: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 QAA19033 for ; Wed, 11 Jul 2001 16:22: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 QQkxgj28932; Wed, 11 Jul 2001 20:22:19 GMT Received: by mail-control.mail.uu.net id QQkxgj13259 for mpls-outgoing; Wed, 11 Jul 2001 20:21:26 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 QQkxgj13236 for ; Wed, 11 Jul 2001 20:21: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 QQkxgj25180 for ; Wed, 11 Jul 2001 20:19:45 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 QQkxgj02817 for ; Wed, 11 Jul 2001 20:19:44 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA22887; Wed, 11 Jul 2001 16:19:37 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA09259; Wed, 11 Jul 2001 16:19:34 -0400 (EDT) Message-Id: <200107112019.QAA09259@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: raszuk@cisco.com cc: Ron Bonica , Yakov Rekhter , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Wed, 11 Jul 2001 12:07:38 -0700. <3B4CA3FA.97A8A4F8@cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Jul 2001 16:19:33 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Robert> What you need to invent is a way not just for tail not to send the Robert> proposed UDP reply the same way as they send ICMP one but also to Robert> make sure each subsequent node does the same. Why is it necessary that the UDP reply "go the same way" as anything else? It just has to follow a hop-by-hop IP path, so that LSP failure in the reverse direction cannot cause it to be lost. From owner-mpls@UU.NET Wed Jul 11 18:30: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 SAA23042 for ; Wed, 11 Jul 2001 18:30: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 QQkxgp19341; Wed, 11 Jul 2001 21:51:14 GMT Received: by mail-control.mail.uu.net id QQkxgp12633 for mpls-outgoing; Wed, 11 Jul 2001 21:50:38 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 QQkxgp12615 for ; Wed, 11 Jul 2001 21:50: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 QQkxgp01737 for ; Wed, 11 Jul 2001 21:47:33 GMT Received: from server.stmi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailout.stmi.com [63.250.132.131]) id QQkxgp12485 for ; Wed, 11 Jul 2001 21:47:32 GMT Received: from irvexch.stmi.com (irvexch [10.1.2.7]) by server.stmi.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f6BLod106963; Wed, 11 Jul 2001 14:50:39 -0700 (PDT) Received: by irvexch.stmi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jul 2001 14:48:31 -0700 Message-ID: <319ACC82D7A6DA45B7024D4D340EC1DB0B317F@irvexchsv> From: Dzung Nguyen To: "'Irfan Lateef'" , raszuk@cisco.com, erosen@cisco.com Cc: rbonica@MCI.NET, yakov@juniper.net, dcooper@gblx.net, mpls@UU.NET, mpls-ops@mplsrc.com Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Wed, 11 Jul 2001 14:47:24 -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 Please remove my email from the list. Thanks -----Original Message----- From: Irfan Lateef [mailto:irfanlateef@hotmail.com] Sent: Wednesday, July 11, 2001 1:14 PM To: raszuk@cisco.com; erosen@cisco.com Cc: rbonica@MCI.NET; yakov@juniper.net; dcooper@gblx.net; mpls@UU.NET; mpls-ops@mplsrc.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Hi all, The draft-pan-lsp-ping-00.txt address just the detection of errors in the dataplane where as ping is also being used to measure the round-trip-delays. So I would suggest that this draft be extended to atleast the full capability of the IP version of the ping. Namely if the ping packet reached the destination and if there exists an LSP in the reverse direction then it should send the return through that LSP. This will allow the host to measure the round-trip-delays when the LSP is a good bidirectional LSP.( which happen to be one of my requirements!) In fact, taking the idea to the next level, there should be a complete proposal of ICMP over MPLS which may implement all the messages in RFC 792 and come up with a general response from the tail end which is signalling protocol independent. The tunproto-00 draft can be good starting point for this. Dave Allen mentioned earlier in this thread that they are coming out with a draft framework. I agree that there should be one comprehensive solution to all the ICMP related issue. But I want to wait and see if they address these issues. My 2 cents. Irfan Lateef >From: Robert Raszuk >Reply-To: raszuk@cisco.com >To: erosen@cisco.com >CC: Ron Bonica , Yakov Rekhter , >Dave Cooper , mpls-list , mpls-ops > >Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] >Date: Wed, 11 Jul 2001 12:07:38 -0700 > >Eric, > > > We just need to invent a way to ensure that the UDP packet follows >the IP > > hop-by-hop path, rather than being sent through an LSP. > >Well I am afraid this is not easy. What you need to invent is a way not >just for tail not to send the proposed UDP reply the same way as they >send ICMP one but also to make sure each subsequent node does the same. >If a network would be managed by some offline tool yes the tool's >notification by the tail would be enough. If this is attractive solution >I don't know - could be an easy LSP-ping reply option. > >I understand that there is great benefit to eliminate the control plane >usage but I am afraid nothing will be as realiable as either RSVP RESV >(the assumption is that the LSP is up) or IGP flooding (again control >plane). I also fail to come up with anything more simpler then just load >this msg on the RSVP RESV. > >I was watching the thread closely as it addresses one of the most >popular recently customer demand in some extent and would say that not >going forward with this proposal would hurt live deployed networks or >make implementations not interoperable. > >R. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Jul 11 23:09:00 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 XAA29841 for ; Wed, 11 Jul 2001 23:09:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxhk11022; Thu, 12 Jul 2001 03:09:06 GMT Received: by mail-control.mail.uu.net id QQkxhk13903 for mpls-outgoing; Thu, 12 Jul 2001 03:08: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 QQkxhk13861 for ; Thu, 12 Jul 2001 03:08:09 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 QQkxhk22380 for ; Thu, 12 Jul 2001 03:07:37 GMT Received: from squid.squirehome.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu163-42-132.nc.rr.com [24.163.42.132]) id QQkxhk10557 for ; Thu, 12 Jul 2001 03:07:37 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6C37Jt02405; Wed, 11 Jul 2001 23:07:19 -0400 Message-ID: <3B4D1466.F172DAD8@acm.org> Date: Wed, 11 Jul 2001 23:07:18 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com CC: Yakov Rekhter , raszuk@cisco.com, Ron Bonica , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107112013.QAA09237@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > Eric> We just need to invent a way to ensure that the UDP packet follows the > Eric> IP hop-by-hop path, rather than being sent through an LSP. > > Yakov> or just use what is described in draft-pan-lsp-ping-00.txt. > > The point is to find a simple mechanism that does not depend on a particular > control plane. To jump on an already crowded bandwagon... Having an LSP ping that is signalling protocol dependent does suck. But I agree that if they only thing you're sure about in the reverse direction is the reverse control path, then it might have to be used. To this end, it would seem simple enough to compartmentalize the signalling aspects of the proposed LSP ping that it has some header stuff and then some signalling protocol specific TLV. The RSVP TLV could be as described in this draft, and a CR-LDP TLV could be just as easily defined (maybe just the LSP ID?). So at least the methodology would be consistent as well as the main packet format and port numbers, etc., with signalling specific junk tacked onto the end. - Matt From owner-mpls@UU.NET Wed Jul 11 23:10: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 XAA29868 for ; Wed, 11 Jul 2001 23:10: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 QQkxhk23213; Thu, 12 Jul 2001 03:10:30 GMT Received: by mail-control.mail.uu.net id QQkxhk14085 for mpls-outgoing; Thu, 12 Jul 2001 03:09: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 QQkxhk14036 for ; Thu, 12 Jul 2001 03:09: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 QQkxhk21643 for ; Thu, 12 Jul 2001 03:06:46 GMT Received: from ureach.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxhk06933 for ; Thu, 12 Jul 2001 03:06:46 GMT Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49]) by ureach.com (8.9.1/8.8.5) with ESMTP id XAA32164 for ; Wed, 11 Jul 2001 23:06:46 -0400 Received: (from nobody@localhost) by www21.ureach.com (8.9.3/8.9.1) id XAA05826; Wed, 11 Jul 2001 23:06:46 -0400 Date: Wed, 11 Jul 2001 23:06:46 -0400 Message-Id: <200107120306.XAA05826@www21.ureach.com> To: mpls@UU.NET From: Anouk Rocher Reply-to: Subject: RSVP Qos Objects - how does MPLS/TE use them Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Running through many MPLS RFCs/drafts and trying to co-relate them with the base RSVP spec in RFC 2205 (and 2210), I can 't seem to find a clear statement anywhere on how RSVP objects are used for the purposes of MPLS based Traffic Engineering. Is it the case that the ingress node trying to set-up an LSP encodes the bandwidth it needs for that LSP, INTSERV style by filling out the Sender Tspec? Are all the fields "Token Bucket Rate", "Token Bucket Size", "Peak Data Rate", "Minimum Policed Unit" and "Maximum Packet Size" needed? Or is it safe to just specify the bandwith needed as "Peak Data Rate". Are any of the other objects like ADSPEC and RSPEC needed for Traffic engineering (beyond basic conformance needs for RSVP to function properly)? Can one of the authors of draft-ietf-mpls-rsvp-lsp-tunnel (Vijay, Lou, ??) clarify this? Many thanks. Anouk ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-mpls@UU.NET Wed Jul 11 23:15:51 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 XAA29944 for ; Wed, 11 Jul 2001 23:15: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 QQkxhl24506; Thu, 12 Jul 2001 03:15:56 GMT Received: by mail-control.mail.uu.net id QQkxhl14964 for mpls-outgoing; Thu, 12 Jul 2001 03:15: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 QQkxhl14793 for ; Thu, 12 Jul 2001 03:15:01 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 QQkxhk04474 for ; Thu, 12 Jul 2001 03:13:56 GMT Received: from squid.squirehome.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu163-42-132.nc.rr.com [24.163.42.132]) id QQkxhk19216 for ; Thu, 12 Jul 2001 03:13:55 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6C3Dot02478; Wed, 11 Jul 2001 23:13:50 -0400 Message-ID: <3B4D15EE.38260E20@acm.org> Date: Wed, 11 Jul 2001 23:13:50 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com, Yakov Rekhter , raszuk@cisco.com, Ron Bonica , Dave Cooper , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107112013.QAA09237@erosen-u10.cisco.com> <3B4D1466.F172DAD8@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Matt Squire wrote: > > Eric Rosen wrote: > > > > Eric> We just need to invent a way to ensure that the UDP packet follows the > > Eric> IP hop-by-hop path, rather than being sent through an LSP. > > > > Yakov> or just use what is described in draft-pan-lsp-ping-00.txt. > > > > The point is to find a simple mechanism that does not depend on a particular > > control plane. > > To jump on an already crowded bandwagon... > > Having an LSP ping that is signalling protocol dependent does suck. But > I agree that if they only thing you're sure about in the reverse > direction is the reverse control path, then it might have to be used. > > To this end, it would seem simple enough to compartmentalize the > signalling aspects of the proposed LSP ping that it has some header > stuff and then some signalling protocol specific TLV. The RSVP TLV > could be as described in this draft, and a CR-LDP TLV could be just as > easily defined (maybe just the LSP ID?). So at least the methodology > would be consistent as well as the main packet format and port numbers, > etc., with signalling specific junk tacked onto the end. > It would also be nice if the signalling protocls behaved similarly, maybe using some type of notification message with a PING_OK status or something, but thats doesn't seem like as big a deal. - Matt From owner-mpls@UU.NET Thu Jul 12 07:10: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 HAA02444 for ; Thu, 12 Jul 2001 07:10: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 QQkxiq02844; Thu, 12 Jul 2001 11:10:08 GMT Received: by mail-control.mail.uu.net id QQkxiq29481 for mpls-outgoing; Thu, 12 Jul 2001 11:09: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 QQkxiq29441 for ; Thu, 12 Jul 2001 11:09: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 QQkxiq04145 for ; Thu, 12 Jul 2001 11:08:11 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 QQkxiq29622 for ; Thu, 12 Jul 2001 11:08:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA25082 for mpls@uu.net; Thu, 12 Jul 2001 07:08: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 QQkxiq29262 for ; Thu, 12 Jul 2001 11:07: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 QQkxiq11743 for ; Thu, 12 Jul 2001 11:06:06 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkxiq17860 for ; Thu, 12 Jul 2001 11:06:06 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01346; Thu, 12 Jul 2001 07:05:16 -0400 (EDT) Message-Id: <200107121105.HAA01346@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shandilya-fault-tolerant-lsp-00.txt Date: Thu, 12 Jul 2001 07:05:15 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fault Tolerant LSP establishment in an MPLS network Author(s) : V. Shandilya Filename : draft-shandilya-fault-tolerant-lsp-00.txt Pages : 9 Date : 11-Jul-01 One of the fundamental requirements of traffic engineering is rerouting the path of an established LSP tunnel. It could be because of an administrative policy or, a link or node failure. Its the latter requirement that is focussed in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shandilya-fault-tolerant-lsp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shandilya-fault-tolerant-lsp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shandilya-fault-tolerant-lsp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010711155616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shandilya-fault-tolerant-lsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shandilya-fault-tolerant-lsp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010711155616.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 12 08:53: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 IAA15308 for ; Thu, 12 Jul 2001 08:53: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 QQkxix07954; Thu, 12 Jul 2001 12:53:32 GMT Received: by mail-control.mail.uu.net id QQkxix27899 for mpls-outgoing; Thu, 12 Jul 2001 12:52: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 QQkxix27881 for ; Thu, 12 Jul 2001 12:52: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 QQkxix26095 for ; Thu, 12 Jul 2001 12:52:32 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 QQkxix15494 for ; Thu, 12 Jul 2001 12:52:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA00352 for mpls@uu.net; Thu, 12 Jul 2001 08:52:30 -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 QQkxix27778 for ; Thu, 12 Jul 2001 12:51:44 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 QQkxix28851 for ; Thu, 12 Jul 2001 12:51:27 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 QQkxix14041 for ; Thu, 12 Jul 2001 12:51:27 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 IAA20535; Thu, 12 Jul 2001 08:51:25 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id IAA26591; Thu, 12 Jul 2001 08:51:24 -0400 (EDT) Message-Id: <200107121251.IAA26591@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: vijay@cosinecom.com Subject: Time to set the MPLS agenda Date: Thu, 12 Jul 2001 08:51:24 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Please send your agenda request to Vijay & me. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 12 09:21: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 JAA18726 for ; Thu, 12 Jul 2001 09:21: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 QQkxiz27924; Thu, 12 Jul 2001 13:20:22 GMT Received: by mail-control.mail.uu.net id QQkxiz19902 for mpls-outgoing; Thu, 12 Jul 2001 13:20: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 QQkxiz19882 for ; Thu, 12 Jul 2001 13:19: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 QQkxiz11864 for ; Thu, 12 Jul 2001 13:17:56 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 QQkxiz27932 for ; Thu, 12 Jul 2001 13:17:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA02204 for mpls@uu.net; Thu, 12 Jul 2001 09:17: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 QQkxiz19791 for ; Thu, 12 Jul 2001 13:17:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxiz00378 for ; Thu, 12 Jul 2001 13:15:30 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 QQkxiz22704 for ; Thu, 12 Jul 2001 13:15:29 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 JAA22494; Thu, 12 Jul 2001 09:15:22 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA27078; Thu, 12 Jul 2001 09:15:21 -0400 (EDT) Message-Id: <200107121315.JAA27078@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Ron Bonica cc: mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of "Tue, 10 Jul 2001 23:18:12 EDT." Date: Thu, 12 Jul 2001 09:15:21 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Shouldn't the mechanism be generalized? Possibly made independant of the > signaling mechanism? I don't think so. The mechanism is intentionally tied to the control plane to ensure that the source is properly informed even if the reverse data path may be broken. I wouldn't want to propose a general mechanism for this. > Don't LSPs that are established by LDP (or foo) need > this functionality, too? Yes. But one size may not fit all. > Also, wouldn't this functionality also be useful for non-MPLS tunnels? Ditto. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 12 10:27: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 KAA27654 for ; Thu, 12 Jul 2001 10:27: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 QQkxjd18697; Thu, 12 Jul 2001 14:26:49 GMT Received: by mail-control.mail.uu.net id QQkxjd15597 for mpls-outgoing; Thu, 12 Jul 2001 14:26: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 QQkxjd15582 for ; Thu, 12 Jul 2001 14:26: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 QQkxjd09323 for ; Thu, 12 Jul 2001 14:25:49 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 QQkxjd13956 for ; Thu, 12 Jul 2001 14:25:48 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29840; Thu, 12 Jul 2001 10:25:36 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA12531; Thu, 12 Jul 2001 10:25:32 -0400 (EDT) Message-Id: <200107121425.KAA12531@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: George Swallow cc: Ron Bonica , mpls-list , mpls-ops Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Thu, 12 Jul 2001 09:15:21 -0400. <200107121315.JAA27078@telescope.cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 12 Jul 2001 10:25:32 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk George> The mechanism is intentionally tied to the control plane to ensure George> that the source is properly informed even if the reverse data path George> may be broken. If the reply is encapsulated in a UDP packet which is addressed to the tunnel head and has router alert set, isn't this just as effective, without the dependence on the control plane? From owner-mpls@UU.NET Thu Jul 12 11:19: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 LAA05029 for ; Thu, 12 Jul 2001 11:19: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 QQkxjh28085; Thu, 12 Jul 2001 15:19:18 GMT Received: by mail-control.mail.uu.net id QQkxjh11329 for mpls-outgoing; Thu, 12 Jul 2001 15:18: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 QQkxjh11306 for ; Thu, 12 Jul 2001 15:18:25 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 QQkxjg25221 for ; Thu, 12 Jul 2001 15:14:00 GMT Received: from vill.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: t17.villagenetworks.com [65.112.106.17]) id QQkxjg16893 for ; Thu, 12 Jul 2001 15:14:00 GMT Received: from ALLAN (alan.vill.com [192.168.1.66] (may be forged)) by vill.com (8.8.8+Sun/8.8.8) with SMTP id LAA21819 for ; Thu, 12 Jul 2001 11:13:59 -0400 (EDT) From: "Allan Silverstein" To: Subject: Packet Analyzer for MPLS,etc Date: Thu, 12 Jul 2001 11:13:56 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can anyone please recommend a sniffer/packet-decoder that will decode all (if not all then most??) of the following: MPLS OSPF-TE ISIS-TE RSVP-TE LDP CR-LDP Thanks al silverstein From owner-mpls@UU.NET Thu Jul 12 11:21: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 LAA05296 for ; Thu, 12 Jul 2001 11:21: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 QQkxjh01965; Thu, 12 Jul 2001 15:20:52 GMT Received: by mail-control.mail.uu.net id QQkxjh11537 for mpls-outgoing; Thu, 12 Jul 2001 15:20: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 QQkxjh11452 for ; Thu, 12 Jul 2001 15:20: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 QQkxjh00642 for ; Thu, 12 Jul 2001 15:16:43 GMT Received: from ext1.ics.forth.gr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQkxjh17980 for ; Thu, 12 Jul 2001 15:16:42 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 SAA04904; Thu, 12 Jul 2001 18:16:29 +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 SAA11466; Thu, 12 Jul 2001 18:16:35 +0300 (EET DST) Posted-Date: Thu, 12 Jul 2001 18:16:35 +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 SAA29569; Thu, 12 Jul 2001 18:16:35 +0300 (EEST) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Date: Thu, 12 Jul 2001 18:16:34 +0300 (EEST) From: Chrysostomos Tziouvaras To: mpls@UU.NET, IP-Optical@lists.bell-labs.com, gmpls-ops@mplsrc.com Subject: A question about the models of IP optical interaction In-Reply-To: <012301c0f246$5bd21120$8001a8c0@oleane.com> 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 how signalling is performed according to the integrated model: does it include UNI or it's straightforward as in the peer model? Regards Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Thu Jul 12 11:29: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 LAA06443 for ; Thu, 12 Jul 2001 11:29: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 QQkxjh08195; Thu, 12 Jul 2001 15:29:24 GMT Received: by mail-control.mail.uu.net id QQkxjh12621 for mpls-outgoing; Thu, 12 Jul 2001 15:28:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxjh12614 for ; Thu, 12 Jul 2001 15:28: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 QQkxjh17310 for ; Thu, 12 Jul 2001 15:28:07 GMT Received: from squid.squirehome.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu163-42-132.nc.rr.com [24.163.42.132]) id QQkxjh29042 for ; Thu, 12 Jul 2001 15:28:06 GMT Received: from acm.org (sc-f100-01.extremenetworks.com [63.251.106.30]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6CFS0t03022; Thu, 12 Jul 2001 11:28:00 -0400 Message-ID: <3B4DC1F9.7B035EA8@acm.org> Date: Thu, 12 Jul 2001 11:27:53 -0400 From: Matt Squire X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: George Swallow , Ron Bonica , mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107121425.KAA12531@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit What prevents a packet with a router alert flag set from being sent over an LSP? I don't recall anything in the specs that specifies router alter packets can't be LSP'd. Eric Rosen wrote: > George> The mechanism is intentionally tied to the control plane to ensure > George> that the source is properly informed even if the reverse data path > George> may be broken. > > If the reply is encapsulated in a UDP packet which is addressed to the > tunnel head and has router alert set, isn't this just as effective, without > the dependence on the control plane? From owner-mpls@UU.NET Thu Jul 12 11:31:53 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 LAA06745 for ; Thu, 12 Jul 2001 11:31: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 QQkxji04886; Thu, 12 Jul 2001 15:31:10 GMT Received: by mail-control.mail.uu.net id QQkxji12792 for mpls-outgoing; Thu, 12 Jul 2001 15:30: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 QQkxji12786 for ; Thu, 12 Jul 2001 15:30:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxji13487 for ; Thu, 12 Jul 2001 15:30:25 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 QQkxji10277 for ; Thu, 12 Jul 2001 15:30:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA12567 for mpls@uu.net; Thu, 12 Jul 2001 11:30: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 QQkxjh12620 for ; Thu, 12 Jul 2001 15:28: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 QQkxjh09743 for ; Thu, 12 Jul 2001 15:27:02 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkxjh15071 for ; Thu, 12 Jul 2001 15:27:01 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 LAA24959; Thu, 12 Jul 2001 11:26:47 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA15085; Thu, 12 Jul 2001 11:26:46 -0400 (EDT) Message-Id: <200107121526.LAA15085@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: erosen@cisco.com cc: George Swallow , Ron Bonica , mpls-list , mpls-ops , swallow@cisco.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of "Thu, 12 Jul 2001 10:25:32 EDT." <200107121425.KAA12531@erosen-u10.cisco.com> Date: Thu, 12 Jul 2001 11:26:46 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > George> The mechanism is intentionally tied to the control plane to ensure > George> that the source is properly informed even if the reverse data path > George> may be broken. > > If the reply is encapsulated in a UDP packet which is addressed to the > tunnel head and has router alert set, isn't this just as effective, without > the dependence on the control plane? Interesting idea. We should explore this. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 12 12:07: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 MAA12216 for ; Thu, 12 Jul 2001 12:07: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 QQkxjk22202; Thu, 12 Jul 2001 16:07:39 GMT Received: by mail-control.mail.uu.net id QQkxjk00828 for mpls-outgoing; Thu, 12 Jul 2001 16:07: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 QQkxjk29530 for ; Thu, 12 Jul 2001 16:06: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 QQkxjk15934 for ; Thu, 12 Jul 2001 16:04:56 GMT Received: from uniwest1.redstonecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.194.140.130]) id QQkxjk21047 for ; Thu, 12 Jul 2001 16:04:56 GMT Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <3VN5GMD2>; Thu, 12 Jul 2001 12:04:50 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C0210F5DC@mailwest.unispherenetworks.com> From: "Shekhar, Ravi" To: "'erosen@cisco.com'" , George Swallow Cc: Ron Bonica , mpls-list , mpls-ops Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Thu, 12 Jul 2001 12:04:49 -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 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, July 12, 2001 10:26 AM > To: George Swallow > Cc: Ron Bonica; mpls-list; mpls-ops > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] > > > > George> The mechanism is intentionally tied to the control > plane to ensure > George> that the source is properly informed even if the > reverse data path > George> may be broken. > > If the reply is encapsulated in a UDP packet which is > addressed to the > tunnel head and has router alert set, isn't this just as > effective, without > the dependence on the control plane? In a pathological case, there might not even be vanilla IP hop-by-hop (non-LSP) connectivity either in the reverse direction. So IP routing these replies to tunnel head might not work. Perhaps sending replies in the reverse direction of the way the request for LSP came in by looking at the reservation state in the router (i.e. the way current draft suggests for RSVP and something similar for LDP) but sending it as UDP packet as you suggest will achieve both the goals - signalling protocol independence and bypassing any IP hop-by-hop failure in reverse direction. Besides, if (ever) LSPs are set up across LDP/RSVP domain, this mechanism would still work. - Ravi Shekhar. From owner-mpls@UU.NET Thu Jul 12 12:28: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 MAA15365 for ; Thu, 12 Jul 2001 12:28: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 QQkxjl27110; Thu, 12 Jul 2001 16:28:09 GMT Received: by mail-control.mail.uu.net id QQkxjl10708 for mpls-outgoing; Thu, 12 Jul 2001 16:27: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 QQkxjl10659 for ; Thu, 12 Jul 2001 16:27: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 QQkxjl17856 for ; Thu, 12 Jul 2001 16:23:10 GMT Received: from ureach.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxjl02466 for ; Thu, 12 Jul 2001 16:23:10 GMT Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49]) by ureach.com (8.9.1/8.8.5) with ESMTP id MAA29926 for ; Thu, 12 Jul 2001 12:23:09 -0400 Received: (from nobody@localhost) by www21.ureach.com (8.9.3/8.9.1) id MAA14295; Thu, 12 Jul 2001 12:23:10 -0400 Date: Thu, 12 Jul 2001 12:23:10 -0400 Message-Id: <200107121623.MAA14295@www21.ureach.com> To: mpls@UU.NET From: Anouk Rocher Reply-to: Subject: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This didn't seem to get posted even though I mailed it several hours ago. So here it is again - Can one of the draft authors comment. Further can such a clarification be added to the draft for reference. ------------------------------------------------------------------- Hi, Running through many MPLS RFCs/drafts and trying to co-relate them with the base RSVP spec in RFC 2205 (and 2210), I can 't seem to find a clear statement anywhere on how RSVP objects are used for the purposes of MPLS based Traffic Engineering. Is it the case that the ingress node trying to set-up an LSP encodes the bandwidth it needs for that LSP, INTSERV style by filling out the Sender Tspec? Are all the fields "Token Bucket Rate", "Token Bucket Size", "Peak Data Rate", "Minimum Policed Unit" and "Maximum Packet Size" needed? Or is it safe to just specify the bandwith needed as "Peak Data Rate". Are any of the other objects like ADSPEC and RSPEC needed for Traffic engineering (beyond basic conformance needs for RSVP to function properly)? Can one of the authors of draft-ietf-mpls-rsvp-lsp-tunnel (Vijay, Lou, ??) clarify this? Many thanks. Anouk ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-mpls@UU.NET Thu Jul 12 12:34: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 MAA16254 for ; Thu, 12 Jul 2001 12:34: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 QQkxjm21084; Thu, 12 Jul 2001 16:34:18 GMT Received: by mail-control.mail.uu.net id QQkxjm11669 for mpls-outgoing; Thu, 12 Jul 2001 16:33: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 QQkxjm11641 for ; Thu, 12 Jul 2001 16:33: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 QQkxjm02123 for ; Thu, 12 Jul 2001 16:32: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 QQkxjm09752 for ; Thu, 12 Jul 2001 16:32:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA17951 for mpls@uu.net; Thu, 12 Jul 2001 12:32: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 QQkxjl10649 for ; Thu, 12 Jul 2001 16:27: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 QQkxjl15605 for ; Thu, 12 Jul 2001 16:21:36 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 QQkxjl00249 for ; Thu, 12 Jul 2001 16:21:36 GMT Received: (qmail 9628 invoked by uid 104); 12 Jul 2001 16:21:35 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.389447 secs); 12/07/2001 09:21:35 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 12 Jul 2001 16:21:35 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6CGLbP08966 for ; Thu, 12 Jul 2001 09:21:37 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jul 2001 09:26:51 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D71@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Thu, 12 Jul 2001 09:26:43 -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, How can the LSP-Ping work if the LSP is setup to carry non-IP traffic? In an egress LSR there is a binding between an LSP and the L3 protocol that it is supposed to carry. If anything other than IP is carried in an LSP, and we inject ping packets in to that LSP, the egress LSR has no means of parsing that packet. How is this addressed in this draft? Yours, -Shahram From owner-mpls@UU.NET Thu Jul 12 12:47: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 MAA18076 for ; Thu, 12 Jul 2001 12:47: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 QQkxjn27412; Thu, 12 Jul 2001 16:47:23 GMT Received: by mail-control.mail.uu.net id QQkxjn14126 for mpls-outgoing; Thu, 12 Jul 2001 16:46: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 QQkxjn14109 for ; Thu, 12 Jul 2001 16:46:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxjn07650 for ; Thu, 12 Jul 2001 16:45:15 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 QQkxjn02783 for ; Thu, 12 Jul 2001 16:45:15 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 MAA17131 for ; Thu, 12 Jul 2001 12:45:12 -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 MAA01406 for ; Thu, 12 Jul 2001 12:45:15 -0400 (EDT) Message-ID: <3B4DD40D.614FB613@marconi.com> Date: Thu, 12 Jul 2001 12:45:01 -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: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt References: <200107121623.MAA14295@www21.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk Rocher wrote: > > Running through many MPLS RFCs/drafts and trying to co-relate them > with the base RSVP spec in RFC 2205 (and 2210), I can 't seem to find > a clear statement anywhere on how RSVP objects are used for the > purposes of MPLS based Traffic Engineering. > > Is it the case that the ingress node trying to set-up an LSP > encodes the bandwidth it needs for that LSP, INTSERV style by > filling out the Sender Tspec? Are all the fields > "Token Bucket Rate", "Token Bucket Size", "Peak Data Rate", > "Minimum Policed Unit" and "Maximum Packet Size" needed? Or is it > safe to just specify the bandwith needed as "Peak Data Rate". The resources reserved are in the FLOWSPEC sent from the egress router to the ingress router. This FLOWSPEC may be one of three kinds of intserv classes: Null (meaning best-effort), Controlled-Load, or Guaranteed Service. The TSPEC in the Path message is used by the ingress router to inform the egress router of what it wants to reserve. Under most MPLS implementations, the egress router will try to reserve this amount, although it is possible for policy decisions to choose a lower amount. The ADSPEC in the Path message, if used, serves two purposes. It gathers information about the network along the path so that the egress router will have an idea of what resources are available, and it may be used to request a particular kind of intserv class for the FLOWSPEC. This is all straight RSVP and has nothing to do with traffic engineering. Traffic engineering is made possible via the new objects introduced in RSVP-TE. Specifically, SESSION_ATTRIBUTES and EXPLICIT_ROUTE. -- David From owner-mpls@UU.NET Thu Jul 12 13:50:33 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 NAA26324 for ; Thu, 12 Jul 2001 13:50:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxjr07509; Thu, 12 Jul 2001 17:50:28 GMT Received: by mail-control.mail.uu.net id QQkxjr10986 for mpls-outgoing; Thu, 12 Jul 2001 17:49: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 QQkxjr10951 for ; Thu, 12 Jul 2001 17:49: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 QQkxjr29798 for ; Thu, 12 Jul 2001 17:45:45 GMT Received: from ureach.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxjr03431 for ; Thu, 12 Jul 2001 17:45:45 GMT Received: from www22.ureach.com (IDENT:root@www22.ureach.com [172.16.2.50]) by ureach.com (8.9.1/8.8.5) with ESMTP id NAA24805; Thu, 12 Jul 2001 13:45:45 -0400 Received: (from nobody@localhost) by www22.ureach.com (8.9.3/8.9.1) id NAA31016; Thu, 12 Jul 2001 13:45:45 -0400 Date: Thu, 12 Jul 2001 13:45:45 -0400 Message-Id: <200107121745.NAA31016@www22.ureach.com> To: david.charlap@marconi.com, mpls@UU.NET, senthil@caip.rutgers.edu From: Anouk Rocher Reply-to: Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Senthil First, thanks for your replies. Comments inline. >The resources reserved are in the FLOWSPEC sent from the egress router >to the ingress router. This FLOWSPEC may be one of three kinds of >intserv classes: Null (meaning best-effort), Controlled-Load, or >Guaranteed Service. While trying to do vanilla Traffic Engineering which for quite a few people seems to finding a path which guarantees a certain bandwidth for an LSP while reducing hopcount (and I do realize there are many other possibilities), clearly Null intserv class is not interesting. Is there an expectation from Network Operators and Service Providers that they would use one of "Controlled Load" or "Guaranteed Service" over the other? > >The TSPEC in the Path message is used by the ingress router to inform >the egress router of what it wants to reserve. Under most MPLS >implementations, the egress router will try to reserve this amount, >although it is possible for policy decisions to choose a lower amount. >The ADSPEC in the Path message, if used, serves two purposes. It >gathers information about the network along the path so that the egress >router will have an idea of what resources are available, and it may be >used to request a particular kind of intserv class for the FLOWSPEC. This definitely helps me some. The question I have here is that while ADSPEC is used for regular RSVP, is it still used in MPLS networks which are using RSVP only for traffic engineering? Or more generally, since several RSVP features are not relevant to MPLS/TE is there some conventional-wisdom/informational-document out there which specifies what RSVP features can be safely turned off or not implemented when doing MPLS/TE. > >This is all straight RSVP and has nothing to do with traffic >engineering. > >Traffic engineering is made possible via the new objects introduced in >RSVP-TE. Specifically, SESSION_ATTRIBUTES and EXPLICIT_ROUTE. I understand this. However the LSP constraints may included bandwidth as well as other things which come via RSVP. Which is why I was asking the question. > >-- David Anouk ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-mpls@UU.NET Thu Jul 12 14:14: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 OAA29314 for ; Thu, 12 Jul 2001 14:14: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 QQkxjs08086; Thu, 12 Jul 2001 18:14:07 GMT Received: by mail-control.mail.uu.net id QQkxjs04053 for mpls-outgoing; Thu, 12 Jul 2001 18:13:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxjs04036 for ; Thu, 12 Jul 2001 18:13: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 QQkxjs07585 for ; Thu, 12 Jul 2001 18:12:09 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 QQkxjs11529 for ; Thu, 12 Jul 2001 18:12:09 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 OAA26796 for ; Thu, 12 Jul 2001 14:12:06 -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 OAA29245 for ; Thu, 12 Jul 2001 14:12:09 -0400 (EDT) Message-ID: <3B4DE862.45440BF9@marconi.com> Date: Thu, 12 Jul 2001 14:11:46 -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: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt References: <200107121745.NAA31016@www22.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk Rocher wrote: > > Is there an expectation from Network Operators and Service > Providers that they would use one of "Controlled Load" or > "Guaranteed Service" over the other? Not that I know of. Both are useful, but for different kinds of applications. IMO, any router vendor implementing MPLS with RSVP-TE must be prepared to handle both classes. > This definitely helps me some. The question I have here is that > while ADSPEC is used for regular RSVP, is it still used in MPLS > networks which are using RSVP only for traffic engineering? It is an optional object. LSRs that receive it should process it according to RFC 2205. As for its usefulness, that depends on the nature if the LERs. The classes used in the ADSPEC object tell the egress router which class to reserve resources with. If the ingress router has a preference (controlled-load or guaranteed), it must signal that preference by including the appropriate service in the ADSPEC, and by explicitly not including any others. The actual values in the ADSPEC may not be of much use, because an egress router will probably base its reservations on what's in the TSPEC. But it is perfectly reasonably for an "application aware" LER to use local policy or other information beyond the scope of RSVP to decide on a different size reservation. If it does, the inforation carried in the ADSPEC may be very useful. > Or more generally, since several RSVP features are not relevant to > MPLS/TE is there some conventional-wisdom/informational-document out > there which specifies what RSVP features can be safely turned off or > not implemented when doing MPLS/TE. I don't know of such a document, but several obvious things come to mind: - WF style reservations - sessions that are not of ctype LSP_TUNNEL_IPV4 or LSP_TUNNEL_IPV6 - sender templates and filterspecs that are not of an LSP ctype - multicast addresses for tunnel endpoint addresses - features that don't make sense in the absence of multicast endpoints, like some Resv merging rules and blockade states. >> This is all straight RSVP and has nothing to do with traffic >> engineering. >> >> Traffic engineering is made possible via the new objects >> introduced in RSVP-TE. Specifically, SESSION_ATTRIBUTES and >> EXPLICIT_ROUTE. > > I understand this. However the LSP constraints may included bandwidth > as well as other things which come via RSVP. Which is why I was > asking the question. These constraints all serve to generate an explicit route. This ERO may be computed by the router, by manual configuration, or by some standalone management server. Once the ERO is computed, RSVP doesn't have to care about the constraints that were used to compute it. -- David From owner-mpls@UU.NET Thu Jul 12 14:21: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 OAA00308 for ; Thu, 12 Jul 2001 14:21: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 QQkxjt22970; Thu, 12 Jul 2001 18:21:02 GMT Received: by mail-control.mail.uu.net id QQkxjt04726 for mpls-outgoing; Thu, 12 Jul 2001 18:20: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 QQkxjt04717 for ; Thu, 12 Jul 2001 18:20: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 QQkxjt17898 for ; Thu, 12 Jul 2001 18:19:54 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gt.ipinfusion.com [209.11.132.18] (may be forged)) id QQkxjt23510 for ; Thu, 12 Jul 2001 18:19:54 GMT Received: from ipinfusion.com (IDENT:root@[10.10.0.38]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id f6CIK3b11171 for ; Thu, 12 Jul 2001 11:20:03 -0700 Message-ID: <3B4DEB8E.5CA03879@ipinfusion.com> Date: Thu, 12 Jul 2001 11:25:18 -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: Installing Labels for Switching !! 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, the algorithm for handling newly recognized FECs does not install the labels (in its forwarding tables) sent to its peers (FEC.1). Is there any special reason for this behaviour ? thanks in advance manoj From owner-mpls@UU.NET Thu Jul 12 16:42: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 QAA21151 for ; Thu, 12 Jul 2001 16:42: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 QQkxkc01426; Thu, 12 Jul 2001 20:41:43 GMT Received: by mail-control.mail.uu.net id QQkxkc26950 for mpls-outgoing; Thu, 12 Jul 2001 20:41:07 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 QQkxkc26935 for ; Thu, 12 Jul 2001 20:40:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxkc13009 for ; Thu, 12 Jul 2001 20:36:56 GMT Received: from ureach.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxkc23175 for ; Thu, 12 Jul 2001 20:36:56 GMT Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49]) by ureach.com (8.9.1/8.8.5) with ESMTP id QAA03497; Thu, 12 Jul 2001 16:36:52 -0400 Received: (from nobody@localhost) by www21.ureach.com (8.9.3/8.9.1) id QAA12287; Thu, 12 Jul 2001 16:36:52 -0400 Date: Thu, 12 Jul 2001 16:36:52 -0400 Message-Id: <200107122036.QAA12287@www21.ureach.com> To: david.charlap@marconi.com, mpls@UU.NET From: Anouk Rocher Reply-to: Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Once again thanks for your very helpful email [cut] >These constraints all serve to generate an explicit route. This ERO may >be computed by the router, by manual configuration, or by some >standalone management server. Once the ERO is computed, RSVP doesn't >have to care about the constraints that were used to compute it. > >-- David I didn't state it clearly enough in either of my messages - yes I do understand that typically paths based on costraints are calculated at the LERs (not considering the management station case here) and the path along with the path requirements fed into a signalling protocol - either RSVP/TE or CRLDP. I was mostly trying to figure out how the calculate requirements are mapped into the various RSVP objects . Specifically if the ingress LER calculates (say) a 10Mbps path through a network and specified all the hops to pass through via ERO, what else should it do to tell the nodes along the path that 10Mpbs should be given to the LSP being set up. From your explanation, I understand that first the ingress LER sends out a TSPEC saying that 10Mps is requested along with an ADSPEC specifiying the type of service (say controlled load). The Egress LER returns a FLOWSPEC. Each node on the return path then begins to use the parameters in the FLOWSPEC to provide the service originally requested by the ingress and confirmed by the egress. First, Derived from a re-glance at the documents and your email again, is this flow of events in the ballpark even if not exact? Second, is it legal to for an intermediate LSR to use the TSPEC and ADSPEC parameters on the forward path rather than the reverse path? I was thinking of this in order to not lose available resources during the forward path which may not be around when the messages start coming back from the egress. Anouk ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-mpls@UU.NET Thu Jul 12 16:54:25 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 QAA22848 for ; Thu, 12 Jul 2001 16:54: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 QQkxkd12894; Thu, 12 Jul 2001 20:54:09 GMT Received: by mail-control.mail.uu.net id QQkxkd28123 for mpls-outgoing; Thu, 12 Jul 2001 20:53:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxkd28099 for ; Thu, 12 Jul 2001 20:53: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 QQkxkd15692 for ; Thu, 12 Jul 2001 20:48:24 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 QQkxkd12684 for ; Thu, 12 Jul 2001 20:48:24 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 QAA13603 for ; Thu, 12 Jul 2001 16:48:21 -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 QAA17018 for ; Thu, 12 Jul 2001 16:48:25 -0400 (EDT) Message-ID: <3B4E0D0B.1D0B6AFD@marconi.com> Date: Thu, 12 Jul 2001 16:48:11 -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: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt References: <200107122036.QAA12287@www21.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anouk Rocher wrote: > > I was mostly trying to figure out how the calculate requirements are > mapped into the various RSVP objects . Specifically if the ingress > LER calculates (say) a 10Mbps path through a network and specified > all the hops to pass through via ERO, what else should it do to tell > the nodes along the path that 10Mpbs should be given to the LSP > being set up. > > From your explanation, I understand that first the ingress LER sends > out a TSPEC saying that 10Mps is requested along with an ADSPEC > specifiying the type of service (say controlled load). The Egress > LER returns a FLOWSPEC. Each node on the return path then begins to > use the parameters in the FLOWSPEC to provide the service originally > requested by the ingress and confirmed by the egress. > > First, Derived from a re-glance at the documents and your email > again, is this flow of events in the ballpark even if not exact? Yes, your description is correct. > Second, is it legal to for an intermediate LSR to use the TSPEC and > ADSPEC parameters on the forward path rather than the reverse path? > I was thinking of this in order to not lose available resources > during the forward path which may not be around when the messages > start coming back from the egress. It isn't forbidden to do so, but it changes the dynamics of the protocol. It may solve some kinds of problems, but it will create other problems. There was a rather long discussion on this not too long ago, which I'd rather not repeat. If you search the mailing list archive, you shouldn't have any problem finding it. -- David From owner-mpls@UU.NET Thu Jul 12 17:21:32 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 RAA26287 for ; Thu, 12 Jul 2001 17:21:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxkf26362; Thu, 12 Jul 2001 21:21:42 GMT Received: by mail-control.mail.uu.net id QQkxkf20403 for mpls-outgoing; Thu, 12 Jul 2001 21:21: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 QQkxkf20385 for ; Thu, 12 Jul 2001 21:20:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxke15987 for ; Thu, 12 Jul 2001 21:12:29 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 QQkxke28481 for ; Thu, 12 Jul 2001 21:12:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA10890 for mpls@uu.net; Thu, 12 Jul 2001 17:12:28 -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 QQkxke19419 for ; Thu, 12 Jul 2001 21:12:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxke24093 for ; Thu, 12 Jul 2001 21:04:10 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkxke01345 for ; Thu, 12 Jul 2001 21:04:09 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 RAA08784; Thu, 12 Jul 2001 17:04:07 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA24800; Thu, 12 Jul 2001 17:04:06 -0400 (EDT) Message-Id: <200107122104.RAA24800@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: anouk@ureach.com cc: david.charlap@marconi.com, mpls@UU.NET, swallow@cisco.com Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt In-reply-to: Your message of "Thu, 12 Jul 2001 16:36:52 EDT." <200107122036.QAA12287@www21.ureach.com> Date: Thu, 12 Jul 2001 17:04:06 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Second, is it legal to for an intermediate LSR to use the TSPEC and ADSPEC > parameters on the forward path rather than the reverse path? I was thinking > of this in order to not lose available resources during the forward path > which may not be around when the messages start coming back from the > egress. That what our implementation does. We consider it a matter of policy not to forward a Path message if the T-SPEC can't be met. We also set the resources aside until either the Path times out or a RESV message makes the formal reservation. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 12 17:52: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 RAA00657 for ; Thu, 12 Jul 2001 17:52: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 QQkxkh02432; Thu, 12 Jul 2001 21:52:50 GMT Received: by mail-control.mail.uu.net id QQkxkh23136 for mpls-outgoing; Thu, 12 Jul 2001 21:52: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 QQkxkh23076 for ; Thu, 12 Jul 2001 21:51:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxkh20522 for ; Thu, 12 Jul 2001 21:49:50 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 QQkxkh25785 for ; Thu, 12 Jul 2001 21:49:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA13765 for mpls@uu.net; Thu, 12 Jul 2001 17:49: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 QQkxkh22799 for ; Thu, 12 Jul 2001 21:49: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 QQkxkh03766 for ; Thu, 12 Jul 2001 21:46:21 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 QQkxkh01357 for ; Thu, 12 Jul 2001 21:46: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 RAA24623; Thu, 12 Jul 2001 17:46:10 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ADC08621; Thu, 12 Jul 2001 17:46:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20010712174207.017ac6a8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Jul 2001 17:50:35 -0400 To: Koling Chang , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: mplsTunnelEntry index Cc: cheenu@alphion.com, arun@force10networks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I think that if you think about the indexes a little differently as we have done in our implementation, you will find that they are quite suitable in the order in which they are specified. If you assign the tunnel index, ingress and egress lsr ids according to the way they normally should be, and each signaled LSP for the tunnel uses a non-0 index, then use the convention that the 0th instance is the tunnel head, you will be able to sort the tunnel heads and the signaled LSPs nicely. Doing this will produce a MIB walk similar to: tunnelEntry.10.0.*.* (tunnel head interface) tunnelEntry.10.1.*.* (signaled LSP) tunnelEntry.10.2.*.* (pre-signaled backup LSP) etc... Then, to find the LSPs that originate at a specific LSR, you can just search for the 0th instances, since heads will only exist on the LSR where the tunnel originates. From that you will also know that any LSP signaled for that head will also originate at that LSR. You can alternatively use the mplsTunnelRole object and test if it is head/non-head to determine origin, since midpoint LSPs will not show up with a role of "head". --Tom >The latest MPLS TE-MIB (draft-ietf-mpls-te-mib-06.txt, >http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt) >indicates that the index for the mplsTunnelTable are the following >four things: > > mplsTunnelIndex, > mplsTunnelInstance, > mplsTunnelIngressLSRId, > mplsTunnelEgressLSRId. > >Although this index set is sufficient to global-uniquely identify an >LSP, it is not very convenient to use when walking through the MIB table >using GetNext. Finding a list of LSPs originated at a specific LSR >requires going through the entire table and do index matches. > >Since the tunnel index and instance are picked at the ingress, I suggest >to change the significance of the indexes to the following >order: > >mplsTunnelIngressLSRId, >mplsTunnelIndex, >mplsTunnelInstance, >mplsTunnelEgressLSRId. > > > >Koling Chang, Ph.D. >Principal Software Engineer >Axiowave Networks, Inc. From owner-mpls@UU.NET Thu Jul 12 22:29: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 WAA04256 for ; Thu, 12 Jul 2001 22:29: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 QQkxla22950; Fri, 13 Jul 2001 02:30:13 GMT Received: by mail-control.mail.uu.net id QQkxkz24092 for mpls-outgoing; Fri, 13 Jul 2001 02:29: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 QQkxkz24081 for ; Fri, 13 Jul 2001 02:29:26 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 QQkxkz21878 for ; Fri, 13 Jul 2001 02:23:18 GMT Received: from ureach.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ureach.com [63.150.151.36]) id QQkxkz04180 for ; Fri, 13 Jul 2001 02:23:18 GMT Received: from www22.ureach.com (IDENT:root@www22.ureach.com [172.16.2.50]) by ureach.com (8.9.1/8.8.5) with ESMTP id WAA28177; Thu, 12 Jul 2001 22:23:17 -0400 Received: (from nobody@localhost) by www22.ureach.com (8.9.3/8.9.1) id WAA03379; Thu, 12 Jul 2001 22:23:17 -0400 Date: Thu, 12 Jul 2001 22:23:17 -0400 Message-Id: <200107130223.WAA03379@www22.ureach.com> To: "George Swallow" From: Anouk Rocher Reply-to: Subject: Re: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt cc: david.charlap@marconi.com, mpls@UU.NET, swallow@cisco.com Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George, Thanks for the data-point. Would you be able to comment on the other point I was trying to understand - that of the "vanilla" way of supporting a bandwidth guarantee. Earlier in the thread David suggested that both controlled-load and guaranteed-service need to be supported by a node. But clearly, for web-traffic, the pre-dominant portion of the traffic in public networks, one most work better than the other (or atleast be easier for a network operator to use). Anouk. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Thu, 12 Jul 2001, George Swallow (swallow@cisco.com) wrote: > > Second, is it legal to for an intermediate LSR to use the TSPEC and > ADSPEC > > parameters on the forward path rather than the reverse path? I was > thinking > > of this in order to not lose available resources during the forward > path > > which may not be around when the messages start coming back from the > > egress. > > That what our implementation does. We consider it a matter of policy > not to forward a Path message if the T-SPEC can't be met. We also set > the resources aside until either the Path times out or a RESV message > makes the formal reservation. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 13 01:12:47 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 BAA24450 for ; Fri, 13 Jul 2001 01:12: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 QQkxlk08971; Fri, 13 Jul 2001 05:13:03 GMT Received: by mail-control.mail.uu.net id QQkxlk06180 for mpls-outgoing; Fri, 13 Jul 2001 05:12:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxlk06168 for ; Fri, 13 Jul 2001 05:12: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 QQkxlk23384 for ; Fri, 13 Jul 2001 05:10:09 GMT Received: from satoru.prism by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.135.195]) id QQkxlk12426 for ; Fri, 13 Jul 2001 05:10:07 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.3/8.11.3) with ESMTP id f6D58FX00518; Fri, 13 Jul 2001 14:08:16 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: mpls@UU.NET Cc: swallow@cisco.com, erosen@cisco.com, rbonica@mci.net, mpls-ops@mplsrc.com Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-Reply-To: <200107121526.LAA15085@telescope.cisco.com> References: <200107121425.KAA12531@erosen-u10.cisco.com> <200107121526.LAA15085@telescope.cisco.com> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010713140815Z.satoru@japan-telecom.co.jp> Date: Fri, 13 Jul 2001 14:08:15 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I'm glad that mpls guys think LSP condition check and failure detect is neccesary feature. Because, I'v described it as LSP-keepalive in draft-satoru-mpls-1hop-lsp-00.txt. Keepalive is a proactive failure detecting method for some data-link, routing-protocol and session. It is also needed for LSP because of the LSR can feedback LSP condition to routing/forwarding autonomic decision. I think it is need to consider in this working group. -- Satoru Matsushima From: George Swallow Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Thu, 12 Jul 2001 11:26:46 -0400 > > George> The mechanism is intentionally tied to the control plane to ensure > > George> that the source is properly informed even if the reverse data path > > George> may be broken. > > > > If the reply is encapsulated in a UDP packet which is addressed to the > > tunnel head and has router alert set, isn't this just as effective, without > > the dependence on the control plane? > > Interesting idea. We should explore this. > > ...George > > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Jul 13 01:18: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 BAA25782 for ; Fri, 13 Jul 2001 01:18: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 QQkxll14384; Fri, 13 Jul 2001 05:18:17 GMT Received: by mail-control.mail.uu.net id QQkxll06767 for mpls-outgoing; Fri, 13 Jul 2001 05:17: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 QQkxll06757 for ; Fri, 13 Jul 2001 05:17:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxll00112 for ; Fri, 13 Jul 2001 05:15:27 GMT Received: from satoru.prism by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.135.195]) id QQkxll19544 for ; Fri, 13 Jul 2001 05:15:26 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.3/8.11.3) with ESMTP id f6D5D5X00535; Fri, 13 Jul 2001 14:13:05 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) In-Reply-To: <200107121526.LAA15085@telescope.cisco.com> References: <200107121425.KAA12531@erosen-u10.cisco.com> <200107121526.LAA15085@telescope.cisco.com> Subject: LSP-ping and Keepalive [was Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] ] To: mpls@UU.NET Cc: swallow@cisco.com, erosen@cisco.com, rbonica@mci.net, mpls-ops@mplsrc.com X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010713141305S.satoru@japan-telecom.co.jp> Date: Fri, 13 Jul 2001 14:13:05 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I'm glad that mpls guys think LSP condition check and failure detect is neccesary feature. Because, I'v described it as LSP-keepalive in draft-satoru-mpls-1hop-lsp-00.txt. Keepalive is a proactive failure detecting method for some data-link, routing-protocol and session. It is also needed for LSP because of the LSR can feedback LSP condition to routing/forwarding autonomic decision. I think it is need to consider in this working group. -- Satoru Matsushima From: George Swallow Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Thu, 12 Jul 2001 11:26:46 -0400 > > George> The mechanism is intentionally tied to the control plane to ensure > > George> that the source is properly informed even if the reverse data path > > George> may be broken. > > > > If the reply is encapsulated in a UDP packet which is addressed to the > > tunnel head and has router alert set, isn't this just as effective, without > > the dependence on the control plane? > > Interesting idea. We should explore this. > > ...George > > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Jul 13 03:05: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 DAA21541 for ; Fri, 13 Jul 2001 03:05: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 QQkxls10194; Fri, 13 Jul 2001 07:05:31 GMT Received: by mail-control.mail.uu.net id QQkxls23356 for mpls-outgoing; Fri, 13 Jul 2001 07:04: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 QQkxls23286 for ; Fri, 13 Jul 2001 07:04:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxls22156 for ; Fri, 13 Jul 2001 07:01:10 GMT Received: from samar.sasken.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkxls02219 for ; Fri, 13 Jul 2001 07:01:07 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f6D705g27082 for ; Fri, 13 Jul 2001 12:30:54 +0530 (IST) Received: from sasken.com (pckb171.sasi.com [10.0.83.171]) by sunk3.sasi.com (8.9.3/8.9.3) with ESMTP id MAA25003 for ; Fri, 13 Jul 2001 12:30:00 +0530 (IST) Message-ID: <3B4E9BF5.247F724D@sasken.com> Date: Fri, 13 Jul 2001 12:27:57 +0530 From: Adithya Bhat Reply-To: adithya@sasken.com Organization: Sasken X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "mpls@UU.NET" Subject: Some Doubts Content-Type: multipart/mixed; boundary="------------3BD0EF4862528503FDD5F134" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------3BD0EF4862528503FDD5F134 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
  --------------3BD0EF4862528503FDD5F134 Content-Type: text/x-vcard; charset=us-ascii; name="adithya.vcf" Content-Description: Card for Adithya Bhat Content-Disposition: attachment; filename="adithya.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bhat;Adithya tel;fax:5560045 tel;home:6782112 tel;work:5578300-8251 x-mozilla-html:FALSE url:www.sasken.com org:Sasken Communication Technologies Limited;R&D version:2.1 email;internet:adithya@sasken.com adr;quoted-printable:;;21, Brigade Square, Cambridge Road, Ulsoor,=0D=0A;Bangalore;Karnataka;560008;India fn:Adithya end:vcard --------------3BD0EF4862528503FDD5F134-- From owner-mpls@UU.NET Fri Jul 13 05:04: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 FAA04233 for ; Fri, 13 Jul 2001 05:04: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 QQkxma24092; Fri, 13 Jul 2001 09:05:03 GMT Received: by mail-control.mail.uu.net id QQkxma05261 for mpls-outgoing; Fri, 13 Jul 2001 09:04:29 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 QQkxma04913 for ; Fri, 13 Jul 2001 09:04: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 QQkxma13217 for ; Fri, 13 Jul 2001 09:01:12 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 QQkxma02781 for ; Fri, 13 Jul 2001 09:01:11 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Fri, 13 Jul 2001 09:45:11 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <3X244WFG>; Fri, 13 Jul 2001 09:45:21 +0100 Message-ID: To: satoru@japan-telecom.co.jp, mpls@UU.NET Cc: swallow@cisco.com, erosen@cisco.com, rbonica@mci.net, mpls-ops@mplsrc.com Subject: RE: LSP-ping and Keepalive [was Re: [Fwd: I-D ACTION:draft-pan-ls p-ping-00.txt] ] Date: Fri, 13 Jul 2001 09:45:26 +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 S.Matsushima wrote 13 July 2001 06:13 > Hi All, > > I'm glad that mpls guys think LSP condition check and failure detect > is neccesary feature. Because, I'v described it as LSP-keepalive in > draft-satoru-mpls-1hop-lsp-00.txt. NH=> MPLS LSPs create new layer networks by definition, ie a new data-plane structure is defined. This is therefore subject to new failure modes that are not relevant to any other technology. Further, there should not be (i) any assumptions about the higher layer client layer technology supported (see Shaharm Davari's last posting on this) or (ii) reliance on some other layers data-plane OAM mechanisms to detect/diagnose/handle MPLS layer failures or (iii) reliance on a specific control-plane protocol (in this case RSVP-TE signalling). MPLS data-plane OAM should be able to stand alone without any cross-layer or cross-plane assumptions. > > Keepalive is a proactive failure detecting method for some data-link, > routing-protocol and session. NH=> I agree any solution needs to be proactive, ie its no good relying on the customer to act as the detection device.......but before we can evaluate any solution we have to agree on what requirements it should meet, and this is just one of them. We, along with several other operators and vendors, have posted a 'requirements' ID (draft-harrison-mpls-oam-req-00.txt) that any MPLS OAM solution should meet. If this work is not suitable/appropriate then fine.....but I feel the authors of the Ping draft should explain what is wrong with these requirements, what the requirements should be, and then how their solution meets these requirements. From owner-mpls@UU.NET Fri Jul 13 06:51: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 GAA16169 for ; Fri, 13 Jul 2001 06:51: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 QQkxmh01141; Fri, 13 Jul 2001 10:51:09 GMT Received: by mail-control.mail.uu.net id QQkxmh11534 for mpls-outgoing; Fri, 13 Jul 2001 10:50:36 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 QQkxmh11526 for ; Fri, 13 Jul 2001 10:50:25 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 QQkxmh29318 for ; Fri, 13 Jul 2001 10:50:10 GMT Received: from satoru.prism by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.135.195]) id QQkxmh29584 for ; Fri, 13 Jul 2001 10:50:08 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.3/8.11.3) with ESMTP id f6DAm2X00971; Fri, 13 Jul 2001 19:48:03 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: neil.2.harrison@bt.com Cc: satoru@japan-telecom.co.jp, mpls@UU.NET, swallow@cisco.com, erosen@cisco.com, rbonica@mci.net, mpls-ops@mplsrc.com Subject: RE: LSP-ping and Keepalive [was Re: [Fwd: I-D ACTION:draft-pan-ls p-ping-00.txt] ] In-Reply-To: References: X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010713194802X.satoru@japan-telecom.co.jp> Date: Fri, 13 Jul 2001 19:48:02 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 45 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, I think you right and necessary things generally, but is there anyone who want to all of the thing you said? Right now, you know even IP based MPLS network does not have any LSP-ping or Keepalive mechanism! Thus, first of all, I think we should make it for IP based MPLS. -- Satoru Matsushima From: neil.2.harrison@bt.com Subject: RE: LSP-ping and Keepalive [was Re: [Fwd: I-D ACTION:draft-pan-ls p-ping-00.txt] ] Date: Fri, 13 Jul 2001 09:45:26 +0100 > S.Matsushima wrote 13 July 2001 06:13 > > Hi All, > > > > I'm glad that mpls guys think LSP condition check and failure detect > > is neccesary feature. Because, I'v described it as LSP-keepalive in > > draft-satoru-mpls-1hop-lsp-00.txt. > NH=> MPLS LSPs create new layer networks by definition, ie a new data-plane > structure is defined. This is therefore subject to new failure modes that > are not relevant to any other technology. Further, there should not be (i) > any assumptions about the higher layer client layer technology supported > (see Shaharm Davari's last posting on this) or (ii) reliance on some other > layers data-plane OAM mechanisms to detect/diagnose/handle MPLS layer > failures or (iii) reliance on a specific control-plane protocol (in this > case RSVP-TE signalling). MPLS data-plane OAM should be able to stand alone > without any cross-layer or cross-plane assumptions. > > > Keepalive is a proactive failure detecting method for some data-link, > > routing-protocol and session. > NH=> I agree any solution needs to be proactive, ie its no good relying on > the customer to act as the detection device.......but before we can evaluate > any solution we have to agree on what requirements it should meet, and this > is just one of them. We, along with several other operators and vendors, > have posted a 'requirements' ID (draft-harrison-mpls-oam-req-00.txt) that > any MPLS OAM solution should meet. If this work is not suitable/appropriate > then fine.....but I feel the authors of the Ping draft should explain what > is wrong with these requirements, what the requirements should be, and then > how their solution meets these requirements. > > From owner-mpls@UU.NET Fri Jul 13 09: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 SMTP id JAA03232 for ; Fri, 13 Jul 2001 09: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 QQkxmq06089; Fri, 13 Jul 2001 13:05:02 GMT Received: by mail-control.mail.uu.net id QQkxmq12964 for mpls-outgoing; Fri, 13 Jul 2001 13: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 QQkxmq12669 for ; Fri, 13 Jul 2001 13:04:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxmq05218 for ; Fri, 13 Jul 2001 13:03:15 GMT Received: from web11401.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11401.mail.yahoo.com [216.136.131.231]) id QQkxmq05389 for ; Fri, 13 Jul 2001 13:03:15 GMT Message-ID: <20010713130315.29558.qmail@web11401.mail.yahoo.com> Received: from [172.173.137.99] by web11401.mail.yahoo.com via HTTP; Fri, 13 Jul 2001 06:03:15 PDT Date: Fri, 13 Jul 2001 06:03:15 -0700 (PDT) From: Sanjay Wadhwa Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: "Shekhar, Ravi" , "'erosen@cisco.com'" , George Swallow Cc: Ron Bonica , mpls-list , mpls-ops In-Reply-To: <49FF5C6DDBD8D311BBBD009027DE980C0210F5DC@mailwest.unispherenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk See below: > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Thursday, July 12, 2001 10:26 AM > > To: George Swallow > > Cc: Ron Bonica; mpls-list; mpls-ops > > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] > > > > > > > > George> The mechanism is intentionally tied to the control > > plane to ensure > > George> that the source is properly informed even if the > > reverse data path > > George> may be broken. > > > > If the reply is encapsulated in a UDP packet which is > > addressed to the > > tunnel head and has router alert set, isn't this just as > > effective, without > > the dependence on the control plane? > > In a pathological case, there might not even be vanilla IP > hop-by-hop > (non-LSP) connectivity either in the reverse direction. So IP > routing > these replies to tunnel head might not work. > Perhaps sending replies in the reverse direction of the way the > request > for LSP came in by looking at the reservation state in the router > (i.e. > the way current draft suggests for RSVP and something similar for > LDP) > but sending it as UDP packet as you suggest will achieve both the > goals - > signalling protocol independence and bypassing any IP hop-by-hop > failure > in reverse direction. Besides, if (ever) LSPs are set up across > LDP/RSVP > domain, this mechanism would still work. > > - Ravi Shekhar. Above seems like a good signalling independent solution. Couple of points to note though. The echo response will need to carry some signalling specific information. And this will not work if all LSRs on the path do not implement the application that listens on a UDP port, and consults the appropriate signalling state to decide upon the next hop towards the ingress. OTOH, I think that one of the pros of the draft propasal is that the LSRs on the path do not have to necessarily implement this. The echo-response will be transparently passed along in the RESV (as an unrecongnized object). Only LERs need to implement this. This might be easier to deploy in the near term. Just a thought. -Sanjay __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 13 09:06: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 JAA03447 for ; Fri, 13 Jul 2001 09:06: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 QQkxmq01157; Fri, 13 Jul 2001 13:06:35 GMT Received: by mail-control.mail.uu.net id QQkxmq15730 for mpls-outgoing; Fri, 13 Jul 2001 13:06: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 QQkxmq14249 for ; Fri, 13 Jul 2001 13:05:16 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 QQkxmq18163 for ; Fri, 13 Jul 2001 13:04:55 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 QQkxmq27845 for ; Fri, 13 Jul 2001 13:04:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA26031 for mpls@uu.net; Fri, 13 Jul 2001 09:04: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 QQkxmq12927 for ; Fri, 13 Jul 2001 13:04:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxmq05074 for ; Fri, 13 Jul 2001 13:03:07 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 QQkxmq05195 for ; Fri, 13 Jul 2001 13:03:06 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6DD36T06197; Fri, 13 Jul 2001 06:03:07 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f6DD2tR21168; Fri, 13 Jul 2001 06:02:55 -0700 (PDT) Received: from mkohno-w2k.cisco.com (dhcp-fuji-9fn-64-104-4-129.cisco.com [64.104.4.129]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA15410; Fri, 13 Jul 2001 06:02:52 -0700 (PDT) Message-Id: <4.3.2-J.20010713213800.03418f08@mailman.cisco.com> X-Sender: mkohno@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Fri, 13 Jul 2001 21:53:13 +0900 To: "S.Matsushima" , pingpan@juniper.net From: Miya Kohno Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Cc: ken.nagami@toshiba.co.jp, swallow@cisco.com, mpls@UU.NET, mpls-ops@mplsrc.com, nsheth@juniper.net, dcooper@gblx.net In-Reply-To: <20010711021407M.satoru@japan-telecom.co.jp> References: <3B4B2080.B9BC992B@juniper.net> <3B4A61D5.2CD45413@juniper.net> <3B4B2080.B9BC992B@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Satoru, The draft proposes how to validate the data plane of RSVP-TE LSPs. As for LDP LSPs, we need to discuss separately. It might be ideal if there's a generalized method, but it seems difficult because we will have to depend on the control plane anyway. Miya At 02:14 01/07/11 +0900, S.Matsushima wrote: >From: Ping Pan >Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] >Date: Tue, 10 Jul 2001 08:34:24 -0700 > > > Ken, > > > > LSP-ping is used to probe the data path. There are cases where the data > > path goes wrong, and you have no idea where the problem is (forwarding > > LSP, reverse LSP, ...). Since the only operational path that you can > > count is the control path, so you reply via RSVP. > > > > If you use UDP to return the reply, what if the returning path is > > broken? Should the user assumes the forwarding LSP is bad, or the > > reverse? > >Ping, > >I can't understand why do you use RSVP msg for reply LSP-ping. >It is only way to LSP using RSVP or other DoD/Orderd label >distribution mode. >Isn't it same thing that simply IP reachability from egress to >ingress for other label distribution mode? >(For example, DU/Independent label distribution) > >LSP is unidirectional path besically. Thus, I suppose LSP-ping reply >scheme will be done by only have to simply IP reachability from egress >to ingress. > > > > > At the same time, if you can come up with a simple, scalable, backward > > compatible method to use for LDP (including the case where you can label > > merging) as well, please do let us know. :-) > > > > - Ping > >How about Section.4 in draft-satoru-mpls-1hop-lsp-00.txt? >It can use not only "KeepAlive" purpose but also LSP-ping. > > > > 4. The Possible to LSP "KeepAlive" using 1-hop LSP > > > > 4.1 Background > > > > This "LSP KeepAlive" ability is extremely important for the > > applications which use LSP but cannot know the state of LSP itself > > (for instance, consider the situation where BGP / MPLS VPNs are > > used; they will recognise the network as "available" only if the > > possibility of the IP accessibility to the PE exits, whatever the > > state of the LSP). > > > > 4.2 Method of "LSP KeepAlive" process > > > > The "KeepAlive" of LSP is possible by the use of IP Packet > > transmission to FEC from the ingress LER with the minimum IP TTL > > (minimum value=1) through 1-hop LSP. This is because if there is a > > cut within LSP then there will be no reply. > > > > In order to carry out "KeepAlive" of LSP, the expansion process is > > also require for the core LSR such that IP TTL will not be replaced > > by MPLS TTL, just like in the egress LER. This is because, if there > > is a cut within LSP the core LSR will "pop" the label. This means > > that the original core LSR will be made to act as an egress LER. > > > > The reply can be expected from the entire installed, if, such as > > ICMP ECHO is used for setting of the IP Packet in this situation. > > > > The TTL does not have to, or more precisely, should not have a value > > of 1 for reply. In case of TTL value on the reply message being 1, > > it will go to the opposite side of LSP "KeepAlive" since the LSP is > > a one-way path. This LSP "KeepAlive" cannot be "KeepAlive" for each > > LSP. > > > > The TTL value on the LSP KeepAlive's reply message should have large > > enough value. Also, if there is no route for the reply message to > > return, it will look as though the healthy LSP does not exit. > > >-- >Satoru Matsushima ---------------------------------------------------------- Miya Kohno, Sr. Consulting Engineer Service Providers Market Developments, Cisco Systems Japan Phone: +81-3-5219-6234, Email: mkohno@cisco.com From owner-mpls@UU.NET Fri Jul 13 10:11:16 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 KAA12033 for ; Fri, 13 Jul 2001 10:11:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxmu14130; Fri, 13 Jul 2001 14:11:28 GMT Received: by mail-control.mail.uu.net id QQkxmu21575 for mpls-outgoing; Fri, 13 Jul 2001 14:10: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 QQkxmu20926 for ; Fri, 13 Jul 2001 14:10:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxmu11271 for ; Fri, 13 Jul 2001 14:10:23 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 QQkxmu12441 for ; Fri, 13 Jul 2001 14:10:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA00811 for mpls@uu.net; Fri, 13 Jul 2001 10:10:21 -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 QQkxmu18982 for ; Fri, 13 Jul 2001 14:09:42 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 QQkxmu09332 for ; Fri, 13 Jul 2001 14:08:59 GMT Received: from alpo.casc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpo.casc.com [152.148.10.6]) id QQkxmu25865 for ; Fri, 13 Jul 2001 14:08:58 GMT Received: from lucent.com ([152.148.116.77]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id KAA07796; Fri, 13 Jul 2001 10:08:27 -0400 (EDT) Message-ID: <3B4F028E.AA565CF9@lucent.com> Date: Fri, 13 Jul 2001 10:15:42 -0400 From: Karthik Muthukrishnan Organization: Lucent Technologies: InterNetworking Systems X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: anouk@ureach.com CC: mpls@UU.NET, chandrasekar kathirvelu , Andy Malis Subject: Re: Label Spaces and Uniqueness References: <200107100045.UAA19689@www21.ureach.com> Content-Type: multipart/mixed; boundary="------------546CA3EEF6D83C492DBF58AE" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------546CA3EEF6D83C492DBF58AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anouk: I agree with your concerns.. These concerns are the basis of the draft: http://search.ietf.org/internet-drafts/draft-kathirvelu-hiervpn-corevpn-00.txt. A complication is that with penultimate hop popping, every two consecutive labels starting with the first one have to be from the same space. For example, are the labels with L1 being the highest on the stack. L1 and L2 are from the same space [say space1] and L3 and L4 are from the same space [say space2] where space1 and space 2 may or not be equal. The choice of whether space1 and space2 are the same and the action when L2 is popped off is left to the implementation; in other words, no wordsmithing in the standard docs is necessary.. -karthik Anouk Rocher wrote: > > Eric, Arun, Ross > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > "In MPLS, there is no notion of > having a different label space for different levels of the hierarchy; > when interpreting a label, the level of the label is irrelevant." > > Does this mean that while doing label stacking, it is neccessary to > allocate labels from a single label space? Isn't this a bit too > restrictive for the cases where the inner label represents > customer traffic transiting a provider and the outer label represents > a path through the provider? > > In other ways, I think it is appropriate in some situations for labels > at different levels of the label-stack to be from different label spaces. > > Comments? > > Anouk > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag --------------546CA3EEF6D83C492DBF58AE Content-Type: text/x-vcard; charset=us-ascii; name="mkarthik.vcf" Content-Description: Card for Karthik Muthukrishnan Content-Disposition: attachment; filename="mkarthik.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Muthukrishnan;Karthik tel;pager:1587321@skytel.com tel;fax:(978)-692-1509 tel;work:(978)-952-1368 x-mozilla-html:TRUE org:Core Switching Division adr:;;;;;; version:2.1 email;internet:mkarthik@lucent.com title:Senior Consulting Engineer end:vcard --------------546CA3EEF6D83C492DBF58AE-- From owner-mpls@UU.NET Fri Jul 13 10:43: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 SMTP id KAA16567 for ; Fri, 13 Jul 2001 10:43: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 QQkxmw10525; Fri, 13 Jul 2001 14:44:14 GMT Received: by mail-control.mail.uu.net id QQkxmw01324 for mpls-outgoing; Fri, 13 Jul 2001 14:43: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 QQkxmw01315 for ; Fri, 13 Jul 2001 14:43: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 QQkxmw18348 for ; Fri, 13 Jul 2001 14:40:30 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxmw26015 for ; Fri, 13 Jul 2001 14:40:30 GMT Message-ID: <3B4F085C.F035967F@sandburst.com> Date: Fri, 13 Jul 2001 10:40:28 -0400 From: Eric Gray MIME-Version: 1.0 To: Shahram Davari Cc: "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D71@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, A non-IP LSP would presumably use a non-IP/ICMP based path integrity check, wouldn't it? Also, such an LSP would be established (most likely) using an explicit route mechanism - which would tend to ensure that the end-points would know of the path integrity (or lack thereof) via signaling behavior. -- Eric Gray You wrote: > Hi All, > > How can the LSP-Ping work if the LSP is setup to carry non-IP traffic? > > In an egress LSR there is a binding between an LSP and the L3 protocol that it is supposed to carry. If anything other than IP is carried in an LSP, and we inject ping packets in to that LSP, the egress LSR has no means of parsing that packet. How is this addressed in this draft? > > Yours, > -Shahram From owner-mpls@UU.NET Fri Jul 13 10:50: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 KAA17641 for ; Fri, 13 Jul 2001 10:50: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 QQkxmx15244; Fri, 13 Jul 2001 14:50:48 GMT Received: by mail-control.mail.uu.net id QQkxmx02245 for mpls-outgoing; Fri, 13 Jul 2001 14:50: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 QQkxmx02200 for ; Fri, 13 Jul 2001 14:49: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 QQkxmx02826 for ; Fri, 13 Jul 2001 14:46:10 GMT Received: from gorilla.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQkxmx13840 for ; Fri, 13 Jul 2001 14:46:10 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 QAA12722; Fri, 13 Jul 2001 16:45:58 +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 QAA23245; Fri, 13 Jul 2001 16:45:58 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 16:45:59 +0200 Message-ID: From: Hummel Heinrich To: "'Karthik Muthukrishnan'" , anouk@ureach.com Cc: mpls@UU.NET, chandrasekar kathirvelu , Andy Malis Subject: AW: Label Spaces and Uniqueness Date: Fri, 13 Jul 2001 16:45:59 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17641 1)For some while I also thought about separate label spaces, but not one space per hierarchy level (there are no well-defined hierarchical levels and at least for now I don't think they are needed). Instead, I thought about one label space which is owned by the respective tunnel edge router, and another which is owned by a different entity like a domain-related server. However meanwhile I think none of these label spaces are required. 2) I don't like penultimate label popping. The gain is not worth the trouble to deal with two alternatives. However, though mostly penultimate label popping looks like a borne trouble-maker there will be solutions that will bypass the problem, like solutions which do not depend on hierarchical label spaces. Heinrich -----Ursprüngliche Nachricht----- Von: Karthik Muthukrishnan [mailto:mkarthik@lucent.com] Gesendet: Freitag, 13. Juli 2001 16:16 An: anouk@ureach.com Cc: mpls@UU.NET; chandrasekar kathirvelu; Andy Malis Betreff: Re: Label Spaces and Uniqueness Anouk: I agree with your concerns.. These concerns are the basis of the draft: http://search.ietf.org/internet-drafts/draft-kathirvelu-hiervpn-corevpn-00.txt. A complication is that with penultimate hop popping, every two consecutive labels starting with the first one have to be from the same space. For example, are the labels with L1 being the highest on the stack. L1 and L2 are from the same space [say space1] and L3 and L4 are from the same space [say space2] where space1 and space 2 may or not be equal. The choice of whether space1 and space2 are the same and the action when L2 is popped off is left to the implementation; in other words, no wordsmithing in the standard docs is necessary.. -karthik Anouk Rocher wrote: > > Eric, Arun, Ross > > RFC 3031 in section 3.14 says (in the penultimate paragraph) > > "In MPLS, there is no notion of > having a different label space for different levels of the hierarchy; > when interpreting a label, the level of the label is irrelevant." > > Does this mean that while doing label stacking, it is neccessary to > allocate labels from a single label space? Isn't this a bit too > restrictive for the cases where the inner label represents > customer traffic transiting a provider and the outer label represents > a path through the provider? > > In other ways, I think it is appropriate in some situations for labels > at different levels of the label-stack to be from different label spaces. > > Comments? > > Anouk > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag From owner-mpls@UU.NET Fri Jul 13 10:55: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 KAA18246 for ; Fri, 13 Jul 2001 10:55: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 QQkxmx28511; Fri, 13 Jul 2001 14:55:42 GMT Received: by mail-control.mail.uu.net id QQkxmx02787 for mpls-outgoing; Fri, 13 Jul 2001 14:55:07 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 QQkxmx02746 for ; Fri, 13 Jul 2001 14:54:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxmx15241 for ; Fri, 13 Jul 2001 14:53:34 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 QQkxmx25400 for ; Fri, 13 Jul 2001 14:53:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA04475 for mpls@uu.net; Fri, 13 Jul 2001 10:53:33 -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 QQkxmx02558 for ; Fri, 13 Jul 2001 14:53: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 QQkxmx05668 for ; Fri, 13 Jul 2001 14:49:03 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 QQkxmx11646 for ; Fri, 13 Jul 2001 14:49:02 GMT Received: (qmail 22510 invoked by uid 104); 13 Jul 2001 14:49:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.405983 secs); 13/07/2001 07:49:01 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 13 Jul 2001 14:49:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6DEn4P15398; Fri, 13 Jul 2001 07:49:04 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 07:54:21 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D74@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" Cc: "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Fri, 13 Jul 2001 07:54:20 -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 Eric, > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Friday, July 13, 2001 10:40 AM > To: Shahram Davari > Cc: 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > A non-IP LSP would presumably use a non-IP/ICMP based > path integrity check, wouldn't it? But there is no method for non-IP LSPs. So isn't it better to have a more general Ping which also applies to those LSPs? > Also, such an LSP would be > established (most likely) using an explicit route mechanism - > which would tend to ensure that the end-points would know of > the path integrity (or lack thereof) via signaling behavior. > As I presented in the Last IETF, the RSVP-TE/CR-LDP may take a different path than the actual user-plane data, because they are hop-by-hop routed. -Shahram > -- > Eric Gray > > You wrote: > > > Hi All, > > > > How can the LSP-Ping work if the LSP is setup to carry > non-IP traffic? > > > > In an egress LSR there is a binding between an LSP and the > L3 protocol that it is supposed to carry. If anything other > than IP is carried in an LSP, and we inject ping packets in > to that LSP, the egress LSR has no means of parsing that > packet. How is this addressed in this draft? > > > > Yours, > > -Shahram > From owner-mpls@UU.NET Fri Jul 13 11:18: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 LAA21702 for ; Fri, 13 Jul 2001 11:18: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 QQkxmz08613; Fri, 13 Jul 2001 15:18:24 GMT Received: by mail-control.mail.uu.net id QQkxmz25736 for mpls-outgoing; Fri, 13 Jul 2001 15:17:50 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 QQkxmz25710 for ; Fri, 13 Jul 2001 15:17:42 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 QQkxmy25592 for ; Fri, 13 Jul 2001 15:12:32 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkxmy14721 for ; Fri, 13 Jul 2001 15:12:28 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA27379 for ; Fri, 13 Jul 2001 11:12:27 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17131 for mpls@uu.net; Fri, 13 Jul 2001 11:12:23 -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 QQkxke19414 for ; Thu, 12 Jul 2001 21:11:59 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 QQkxke24601 for ; Thu, 12 Jul 2001 21:05:07 GMT Received: from yuanchun.kchang.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: yuanchunhsd.ne.mediaone.net [24.147.237.184]) id QQkxke02767 for ; Thu, 12 Jul 2001 21:05:07 GMT Received: from localhost (koling@localhost) by yuanchun.kchang.net (8.9.3/8.8.8) with SMTP id RAA19583; Thu, 12 Jul 2001 17:07:49 -0400 (EDT) (envelope-from koling@yuanchun.kchang.net) Date: Thu, 12 Jul 2001 17:07:49 -0400 (EDT) From: Koling Chang To: mpls@UU.NET cc: cheenu@tachion.com, arun@force10networks.com, tnadeau@cisco.com Subject: mplsTunnelEntry index Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi! The latest MPLS TE-MIB (draft-ietf-mpls-te-mib-06.txt, http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt) indicates that the index for the mplsTunnelTable are the following four things: mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId. Although this index set is sufficient to global-uniquely identify an LSP, it is not very convenient to use when walking through the MIB table using GetNext. Finding a list of LSPs originated at a specific LSR requires going through the entire table and do index matches. Since the tunnel index and instance are picked at the ingress, I suggest to change the significance of the indexes to the following order: mplsTunnelIngressLSRId, mplsTunnelIndex, mplsTunnelInstance, mplsTunnelEgressLSRId. Koling Chang, Ph.D. Principal Software Engineer Axiowave Networks, Inc. From owner-mpls@UU.NET Fri Jul 13 13:32: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 NAA11410 for ; Fri, 13 Jul 2001 13:32: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 QQkxni10929; Fri, 13 Jul 2001 17:32:52 GMT Received: by mail-control.mail.uu.net id QQkxni20781 for mpls-outgoing; Fri, 13 Jul 2001 17:32: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 QQkxni20769 for ; Fri, 13 Jul 2001 17:32:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxni03373 for ; Fri, 13 Jul 2001 17:31:32 GMT Received: from hypnos.cps.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hypnos.cps.intel.com [192.198.165.17]) id QQkxni18320 for ; Fri, 13 Jul 2001 17:31:32 GMT Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA19045; Fri, 13 Jul 2001 17:31:25 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Jul 2001 17:30:57 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1QC4BV>; Fri, 13 Jul 2001 10:30:56 -0700 Message-ID: From: "Feng, Mark" To: "'adithya@sasken.com'" , mpls@UU.NET Subject: RE: Some Doubts Date: Fri, 13 Jul 2001 10:30:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10BC1.8CB5E890" 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_01C10BC1.8CB5E890 Content-Type: text/plain; charset="ISO-8859-1" The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established? On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so. I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path. "MPLS being negotiated, but a non-RSVP capable router stands in the path." means just that, there is a non-RSVP capable router on the intended path. Hope this helps. Mark -----Original Message----- From: Adithya Bhat [mailto:adithya@sasken.com] Sent: Thursday, July 12, 2001 11:58 PM To: mpls@UU.NET Subject: Some Doubts Hi *, In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." 1. Why should a PathErr be sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back. 2. If the above is not true does it mean that all the routers (from the sender to the reciever ) should be rsvp-te capable ( should support labels) routers ? 3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in the path." Please throw some light on this, Thanks in advance Adithya ------_=_NextPart_001_01C10BC1.8CB5E890 Content-Type: text/html; charset="ISO-8859-1"

The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?
 
On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.
 
I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path.
 
"MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.
 
Hope this helps.
 
Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts

Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

------_=_NextPart_001_01C10BC1.8CB5E890-- From owner-mpls@UU.NET Fri Jul 13 14:14: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 OAA17379 for ; Fri, 13 Jul 2001 14:14:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxnl14419; Fri, 13 Jul 2001 18:15:08 GMT Received: by mail-control.mail.uu.net id QQkxnk15294 for mpls-outgoing; Fri, 13 Jul 2001 18:14:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxnk15271 for ; Fri, 13 Jul 2001 18:14:28 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 QQkxnk12340 for ; Fri, 13 Jul 2001 18:12:27 GMT Received: from thalia.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQkxnk04881 for ; Fri, 13 Jul 2001 18:12:26 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA17794 for ; Fri, 13 Jul 2001 18:12:25 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Jul 2001 18:12:25 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3ZBJFMVT>; Fri, 13 Jul 2001 11:12:23 -0700 Message-ID: From: "Feng, Mark" To: mpls@UU.NET Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Date: Fri, 13 Jul 2001 11:12:20 -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 have some doubts regarding the usage of SE style within MPLS. My question is, with SE style, besides doing make-before-break, is it used for other purpose? Consider the following LSP setups (with each sender potentially having different traffic requirements) using SE style, by using explicit routing. ______ | | +---| |---+ | |______| | | | |s1,s3 |s1,s3 s1,s2 ______ | | ______ -----| |-+ +-| | s1,s2,s3,s4 -----| |-+ +-| |------ s3,s4|______| | | |______| |s2,s4_____ |s2,s4 | | | | +---| |---+ |______| Is this possible in RSVP-TE? Thanks in advance. Mark From owner-mpls@UU.NET Fri Jul 13 20: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 SMTP id UAA03159 for ; Fri, 13 Jul 2001 20: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 QQkxoi23737; Sat, 14 Jul 2001 00:05:06 GMT Received: by mail-control.mail.uu.net id QQkxoi13043 for mpls-outgoing; Sat, 14 Jul 2001 00:04:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxoi10711 for ; Sat, 14 Jul 2001 00:04: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 QQkxoi09701 for ; Sat, 14 Jul 2001 00:03:39 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 QQkxoi01485 for ; Sat, 14 Jul 2001 00:03:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA09327 for mpls@uu.net; Fri, 13 Jul 2001 20:03:38 -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 QQkxoi08916 for ; Sat, 14 Jul 2001 00:02: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 QQkxoi06113 for ; Sat, 14 Jul 2001 00:00:22 GMT Received: from rly-ip01.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip01.mx.aol.com [205.188.156.49]) id QQkxoi24372 for ; Sat, 14 Jul 2001 00:00:22 GMT Received: from tot-mtc-te.proxy.aol.com (tot-mtc-te.proxy.aol.com [64.12.103.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id TAA03906; Fri, 13 Jul 2001 19:59:39 -0400 (EDT) Received: from juniper.net (ACA367D5.ipt.aol.com [172.163.103.213]) by tot-mtc-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f6DNxcn19535; Fri, 13 Jul 2001 19:59:38 -0400 (EDT) Message-ID: <3B4F8C8F.62A00848@juniper.net> Date: Fri, 13 Jul 2001 17:04:31 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D71@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: Pingpan999@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > Hi All, > > How can the LSP-Ping work if the LSP is setup to carry non-IP traffic? > > In an egress LSR there is a binding between an LSP and the L3 protocol that it is supposed to carry. > If anything other than IP is carried in an LSP, and we inject ping packets in to that LSP, the egress > LSR has no means of parsing that packet. How is this addressed in this draft? > Shahram, If the LSP (IP or non-IP) is initiated via RSVP-TE, then draft-pan-lsp-ping-00.txt can be used to check the LSP. In this case, the egress can parse the echo-requests. You are right, it won't work in a non-IP network. - Ping From owner-mpls@UU.NET Sat Jul 14 01: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 BAA19231 for ; Sat, 14 Jul 2001 01:48:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxpf28074; Sat, 14 Jul 2001 05:48:45 GMT Received: by mail-control.mail.uu.net id QQkxpf23679 for mpls-outgoing; Sat, 14 Jul 2001 05:48:00 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 QQkxpf23534 for ; Sat, 14 Jul 2001 05:47:57 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 QQkxpf25468 for ; Sat, 14 Jul 2001 05:46:46 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 QQkxpf25704 for ; Sat, 14 Jul 2001 05:46:46 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Sat, 14 Jul 2001 06:44:09 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Sat, 14 Jul 2001 06:43:58 +0100 Message-ID: To: pingpan@juniper.net, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Sat, 14 Jul 2001 06:43:59 +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 Ping Pan wrote 14 July 2001 01:05 > > How can the LSP-Ping work if the LSP is setup to carry > non-IP traffic? > > > > In an egress LSR there is a binding between an LSP and the > L3 protocol that it is supposed to carry. > > If anything other than IP is carried in an LSP, and we > inject ping packets in to that LSP, the egress > > LSR has no means of parsing that packet. How is this > addressed in this draft? > > > > Shahram, > > If the LSP (IP or non-IP) is initiated via RSVP-TE, then > draft-pan-lsp-ping-00.txt can be used to check the LSP. In this case, > the egress can parse the echo-requests. You are right, it > won't work in > a non-IP network. > > - Ping NH=> Ping......You do realise that what you are saying here is effectively the same as 'Layer X is only allowed to carry layer Y clients and nothing else'. If our industry had allowed this expedient way of doing things from the outset please consider just what a mess we would be in now. It would lead to multiple overlay server layer networks for each client layer network, with serious inflexibility/inefficiency of usage, and major interworking and evolution problems (since layer networks and protocols could not be added/developed/removed largely independently). It is my opinion that the expedient advantage you are seeking to achieve with this solution will be at a higher downstream cost to our industry, and I don't see it as healthy for the development of MPLS per se. I really think we ought to get some basic architectural ground rules in place....and the obvious ones here are: - the data-plane of a given layer network in technology X SHOULD not be expected to rely on the OAM of the data-plane of any client or server networks for its defect handling; - the OAM of the data-plane of a given layer network which carries (external) customer traffic SHOULD be decoupled from the (internal) data-plane of the network control-plane (and the protocols used thereon); I would not want to stop you doing what you are proposing, but I think that any proposals which break such basic architectural rules should be clearly marked as proprietary and not put on any standards track. regards, Neil From owner-mpls@UU.NET Sat Jul 14 14:22:30 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 OAA18283 for ; Sat, 14 Jul 2001 14:22:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxrd19215; Sat, 14 Jul 2001 18:22:40 GMT Received: by mail-control.mail.uu.net id QQkxrd01666 for mpls-outgoing; Sat, 14 Jul 2001 18:22:06 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 QQkxrd01658 for ; Sat, 14 Jul 2001 18: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 QQkxrd15767 for ; Sat, 14 Jul 2001 18:18:10 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 QQkxrd26024 for ; Sat, 14 Jul 2001 18:18:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA17109 for mpls@uu.net; Sat, 14 Jul 2001 14:18: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 QQkxrd01344 for ; Sat, 14 Jul 2001 18:17: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 QQkxrc12700 for ; Sat, 14 Jul 2001 18:13:35 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 QQkxrc03435 for ; Sat, 14 Jul 2001 18:13:35 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 OAA27992; Sat, 14 Jul 2001 14:13:34 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ADH04560; Sat, 14 Jul 2001 14:13:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20010714141750.026e2c20@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 Jul 2001 14:17:58 -0400 To: Koling Chang From: "Thomas D. Nadeau" Subject: Re: mplsTunnelEntry index Cc: cheenu@alphion.com, arun@force10networks.com, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Thanks for your response. First let me try to completely understand >what you described: > >When you say tunnelEntry.10.0.*.* > Do you mean the following? > mplsTunnelIndex = 10 > mplsTunnelInstance = 0 > mplsTunnelIngressLSRId = * > mplsTunnelEgressLSRId = * > >If yes, please consider the case below: > >If operator is createing 10 LSPs on Node A towards Node B, with tunnel >index 1 to 10, assuming these are what "mplsTunnelIndexNext" returns on >Node A after each lsp creation. If your convention is followed that >instances are not zero for non-head LSPs, then in Node B's >mplsTunnelTable, we will see the following: > >tunnelEntry.1.1.A.B >tunnelEntry.2.1.A.B >... >tunnelEntry.10.1.A.B > >If 11 tunnels are then be setup on Node B towards Node A, >the table on Node B will look like this: > >tunnelEntry.1.0.B.A >tunnelEntry.1.1.A.B >tunnelEntry.2.0.B.A >tunnelEntry.2.1.A.B >... >tunnelEntry.10.0.B.A >tunnelEntry.10.1.A.B >tunnelEntry.11.0.B.A This looks correct assuming that the same primary tunnel index is used. >On Node B, don't you need to walk through the entire 21 entries to collect >all the tunnels that have heads on node B? If tunnel 1 to 10, originaled >on Node B are deleted, then the table becomes: > >tunnelEntry.1.1.A.B >tunnelEntry.2.1.A.B >... >tunnelEntry.10.1.A.B >tunnelEntry.11.0.B.A <-- > >Don't you need to walk through the entire table to >find the first tunnel that is locally configured? Yes, and as I mentioned, you can quickly note which are heads and which are not by using the indexing convention I outlined. Remember, there are many ways to skin a cat, and the indexing scheme chosen was what agreed to early on is the one which we are using today. I understand that there are alternate methods for indexing this table, and in some instances they might be arguably better, but again the indexing scheme that exists is the one that was agreed upon by the working group early on and during the working group's last call. >My point is, tunnelEntry.1.0.B.A and tunnelEntry.1.1.A.B may be totally >irrelevant due to the fact that tunnelIndex is only significant to the >head (source) end. Why do we put them together in the table? >By the way, you implied that the TunnelInstance is "designated to" >non-zero at the tail end. Do you mean that the same LSP have different >index (mplsTunnelInstance) on head and tail nodes? The same LSP id cannot be used to identify different tunnels, so the instance ID will be different. >Is the >mplsTunnelInstance value carried by signalling protocols at all? Yes. I believe that RSVP carries it directly. CD-LDP has no notion of instance, so the convention I outlined will need to be modified if you happen to be using CR-LDP. --Tom From owner-mpls@UU.NET Mon Jul 16 00:22: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 AAA24411 for ; Mon, 16 Jul 2001 00:22: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 QQkxwj00993; Mon, 16 Jul 2001 04:21:33 GMT Received: by mail-control.mail.uu.net id QQkxwj23973 for mpls-outgoing; Mon, 16 Jul 2001 04:21: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 QQkxwj23949 for ; Mon, 16 Jul 2001 04:20:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxwj22057 for ; Mon, 16 Jul 2001 04:18:20 GMT Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkxwj25567 for ; Mon, 16 Jul 2001 04:18:17 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6G4Fws07882; Mon, 16 Jul 2001 09:45:59 +0530 Message-ID: <3B526BC0.BC4D89E4@multitech.co.in> Date: Mon, 16 Jul 2001 09:51:20 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: Koling Chang , mpls@UU.NET, cheenu@alphion.com, arun@force10networks.com Subject: Re: mplsTunnelEntry index References: <4.3.2.7.2.20010712174207.017ac6a8@bucket.cisco.com> Content-Type: multipart/alternative; boundary="------------A2153D3E99F902F283155656" Sender: owner-mpls@UU.NET Precedence: bulk --------------A2153D3E99F902F283155656 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, There are two sides of the coin here.Walking through the T.E MIB requires Chang's indexing idea But to have a LSP Management with the T.E MIB we can have the original order of indices as mentioned by the authors.One way to achieve this is by actually having Ingress Based Pointers to the original Tunnel Table Entries in the MIB.In this way,we can get the specified management functionality and also satisfy the indices rules in the MIB. Moreover,the RSVP / CR-LDP Signaling protocols have a small difference,the difference being the tunnel instance.So,if one is having both CR-LDP and RSVP operating in a disjoint manner ,we may not consider how we have the Tunnel head configuration. As I understand that Cisco's implementation has a source address NULL or zero to identify tunnel head configurations. Hope this helps. Happy MIB Walking.. Regards, Abhay "Thomas D. Nadeau" wrote: > Hi, > > I think that if you think about the > indexes a little differently as we have done in > our implementation, you will find that they are > quite suitable in the order in which they are > specified. If you assign the tunnel index, > ingress and egress lsr ids according to the way > they normally should be, and each signaled LSP for > the tunnel uses a non-0 index, then use the convention > that the 0th instance is the tunnel head, you > will be able to sort the tunnel heads and the > signaled LSPs nicely. Doing this will produce a > MIB walk similar to: > > tunnelEntry.10.0.*.* (tunnel head interface) > tunnelEntry.10.1.*.* (signaled LSP) > tunnelEntry.10.2.*.* (pre-signaled backup LSP) > etc... > > Then, to find the LSPs that originate at > a specific LSR, you can just search for the 0th instances, > since heads will only exist on the LSR where the tunnel > originates. From that you will also know that any LSP > signaled for that head will also originate at that > LSR. You can alternatively use the mplsTunnelRole > object and test if it is head/non-head to determine > origin, since midpoint LSPs will not show up with > a role of "head". > > --Tom > > >The latest MPLS TE-MIB (draft-ietf-mpls-te-mib-06.txt, > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt) > >indicates that the index for the mplsTunnelTable are the following > >four things: > > > > mplsTunnelIndex, > > mplsTunnelInstance, > > mplsTunnelIngressLSRId, > > mplsTunnelEgressLSRId. > > > >Although this index set is sufficient to global-uniquely identify an > >LSP, it is not very convenient to use when walking through the MIB table > >using GetNext. Finding a list of LSPs originated at a specific LSR > >requires going through the entire table and do index matches. > > > >Since the tunnel index and instance are picked at the ingress, I suggest > >to change the significance of the indexes to the following > >order: > > > >mplsTunnelIngressLSRId, > >mplsTunnelIndex, > >mplsTunnelInstance, > >mplsTunnelEgressLSRId. > > > > > > > >Koling Chang, Ph.D. > >Principal Software Engineer > >Axiowave Networks, Inc. --------------A2153D3E99F902F283155656 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi,
  There are two sides of the coin here.Walking through the T.E MIB requires Chang's indexing idea
  But to have a LSP Management with the T.E MIB we can have the original order of indices as mentioned
  by the authors.One way to achieve this is  by actually having Ingress Based Pointers to the original
  Tunnel Table Entries in the  MIB.In this way,we can get the specified management functionality and also
  satisfy the indices rules in the MIB.
  Moreover,the RSVP / CR-LDP Signaling protocols have a small difference,the difference being the
  tunnel instance.So,if one is having both CR-LDP and RSVP operating in a disjoint manner ,we may not
  consider how we have the Tunnel head configuration.
  As I understand that Cisco's implementation has a source address NULL or zero to identify tunnel
  head configurations.
  Hope this helps.
  Happy MIB Walking..
  Regards,
  Abhay


"Thomas D. Nadeau" wrote:

         Hi,

         I think that if you think about the
indexes a little differently as we have done in
our implementation, you will find that they are
quite suitable in the order in which they are
specified. If you assign the tunnel index,
ingress and egress lsr ids according to the way
they normally should be, and each signaled LSP for
the tunnel uses a non-0 index, then use the convention
that the 0th instance is the tunnel head, you
will be able to sort the tunnel heads and the
signaled LSPs nicely. Doing this will produce a
MIB walk similar to:

         tunnelEntry.10.0.*.*  (tunnel head interface)
         tunnelEntry.10.1.*.*  (signaled LSP)
         tunnelEntry.10.2.*.*  (pre-signaled backup LSP)
         etc...

         Then, to find the LSPs that originate at
a specific LSR, you can just search for the 0th instances,
since heads will only exist on the LSR where the tunnel
originates. From that you will also know that any LSP
signaled for that head will also originate at that
LSR. You can alternatively use the mplsTunnelRole
object and test if it is head/non-head to determine
origin, since midpoint LSPs will not show up with
a role of "head".

         --Tom

>The latest MPLS TE-MIB (draft-ietf-mpls-te-mib-06.txt,
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt)
>indicates that the index for the mplsTunnelTable are the following
>four things:
>
>  mplsTunnelIndex,
>  mplsTunnelInstance,
>  mplsTunnelIngressLSRId,
>  mplsTunnelEgressLSRId.
>
>Although this index set is sufficient to global-uniquely identify an
>LSP, it is not very convenient to use when walking through the MIB table
>using GetNext. Finding a list of LSPs originated at a specific LSR
>requires going through the entire table and do index matches.
>
>Since the tunnel index and instance are picked at the ingress, I suggest
>to change the significance of the indexes to the following
>order:
>
>mplsTunnelIngressLSRId,
>mplsTunnelIndex,
>mplsTunnelInstance,
>mplsTunnelEgressLSRId.
>
>
>
>Koling Chang, Ph.D.
>Principal Software Engineer
>Axiowave Networks, Inc.

--------------A2153D3E99F902F283155656-- From owner-mpls@UU.NET Mon Jul 16 05:32: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 FAA00484 for ; Mon, 16 Jul 2001 05:32: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 QQkxxe15992; Mon, 16 Jul 2001 09:33:09 GMT Received: by mail-control.mail.uu.net id QQkxxe26606 for mpls-outgoing; Mon, 16 Jul 2001 09:32: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 QQkxxe26595 for ; Mon, 16 Jul 2001 09:32: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 QQkxxe18656 for ; Mon, 16 Jul 2001 09:32:07 GMT Received: from samar.sasken.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkxxe16232 for ; Mon, 16 Jul 2001 09:30:02 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f6G9Rgg29230; Mon, 16 Jul 2001 14:57:42 +0530 (IST) Received: from sasken.com (pckb171.sasi.com [10.0.83.171]) by sunk3.sasi.com (8.9.3/8.9.3) with ESMTP id OAA09935; Mon, 16 Jul 2001 14:57:39 +0530 (IST) Message-ID: <3B52B311.D2FA1B45@sasken.com> Date: Mon, 16 Jul 2001 14:55:37 +0530 From: Adithya Bhat Reply-To: adithya@sasken.com Organization: Sasken X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: "Feng, Mark" , sridhar@samsung.co.kr Subject: Re: Some Doubts References: Content-Type: multipart/mixed; boundary="------------05FA533E844DBEAD2D8E052A" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------05FA533E844DBEAD2D8E052A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

 The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts
 
Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

--------------05FA533E844DBEAD2D8E052A Content-Type: text/x-vcard; charset=us-ascii; name="adithya.vcf" Content-Description: Card for Adithya Bhat Content-Disposition: attachment; filename="adithya.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bhat;Adithya tel;fax:5560045 tel;home:6782112 tel;work:5578300-8251 x-mozilla-html:FALSE url:www.sasken.com org:Sasken Communication Technologies Limited;R&D version:2.1 email;internet:adithya@sasken.com adr;quoted-printable:;;21, Brigade Square, Cambridge Road, Ulsoor,=0D=0A;Bangalore;Karnataka;560008;India fn:Adithya end:vcard --------------05FA533E844DBEAD2D8E052A-- From owner-mpls@UU.NET Mon Jul 16 09:00:32 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 JAA01797 for ; Mon, 16 Jul 2001 09:00:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxxs02797; Mon, 16 Jul 2001 13:00:25 GMT Received: by mail-control.mail.uu.net id QQkxxr12285 for mpls-outgoing; Mon, 16 Jul 2001 12:59:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxxr12254 for ; Mon, 16 Jul 2001 12: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 QQkxxr21006 for ; Mon, 16 Jul 2001 12:59:06 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 QQkxxr00983 for ; Mon, 16 Jul 2001 12:59:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA20574 for mpls@uu.net; Mon, 16 Jul 2001 08:59: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 QQkxxr12167 for ; Mon, 16 Jul 2001 12:57: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 QQkxxr26240 for ; Mon, 16 Jul 2001 12:57:29 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 QQkxxr07335 for ; Mon, 16 Jul 2001 12:57:29 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 IAA16016; Mon, 16 Jul 2001 08:57:12 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ADK00513; Mon, 16 Jul 2001 08:57:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20010716090041.017b5180@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 16 Jul 2001 09:01:29 -0400 To: abhay From: "Thomas D. Nadeau" Subject: Re: mplsTunnelEntry index Cc: Koling Chang , mpls@UU.NET, cheenu@alphion.com, arun@force10networks.com In-Reply-To: <3B526BC0.BC4D89E4@multitech.co.in> References: <4.3.2.7.2.20010712174207.017ac6a8@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:51 AM 7/16/2001 +0530, abhay wrote: >Hi, > > There are two sides of the coin here.Walking through the T.E MIB > requires Chang's indexing idea > > But to have a LSP Management with the T.E MIB we can have the original > order of indices as mentioned > > by the authors.One way to achieve this is by actually having Ingress > Based Pointers to the original > > Tunnel Table Entries in the MIB.In this way,we can get the specified > management functionality and also > > satisfy the indices rules in the MIB. > > Moreover,the RSVP / CR-LDP Signaling protocols have a small > difference,the difference being the > > tunnel instance.So,if one is having both CR-LDP and RSVP operating in a > disjoint manner ,we may not > > consider how we have the Tunnel head configuration. > > As I understand that Cisco's implementation has a source address NULL > or zero to identify tunnel > > head configurations. No, we follow the paradigm I described earlier where the tunnelInstance set to 0 to signify the head interface. --Tom From owner-mpls@UU.NET Mon Jul 16 09:09: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 JAA03966 for ; Mon, 16 Jul 2001 09:09: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 QQkxxs13949; Mon, 16 Jul 2001 13:10:00 GMT Received: by mail-control.mail.uu.net id QQkxxs02710 for mpls-outgoing; Mon, 16 Jul 2001 13:09:26 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 QQkxxs02686 for ; Mon, 16 Jul 2001 13:09:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxxs07439 for ; Mon, 16 Jul 2001 13:08:50 GMT Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkxxs12682 for ; Mon, 16 Jul 2001 13:08:47 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6GD4Mk20463; Mon, 16 Jul 2001 18:34:22 +0530 Message-ID: <3B52E828.9F075617@multitech.co.in> Date: Mon, 16 Jul 2001 18:42:08 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: Koling Chang , mpls@UU.NET, cheenu@alphion.com, arun@force10networks.com Subject: Re: mplsTunnelEntry index References: <4.3.2.7.2.20010712174207.017ac6a8@bucket.cisco.com> <4.3.2.7.2.20010716090041.017b5180@bucket.cisco.com> Content-Type: multipart/alternative; boundary="------------C4484A87980F4F2298F6A972" Sender: owner-mpls@UU.NET Precedence: bulk --------------C4484A87980F4F2298F6A972 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Tom I see what you mean,implementations keep changing for the better,;). Regards, Abhay "Thomas D. Nadeau" wrote: > At 09:51 AM 7/16/2001 +0530, abhay wrote: > > >Hi, > > > > There are two sides of the coin here.Walking through the T.E MIB > > requires Chang's indexing idea > > > > But to have a LSP Management with the T.E MIB we can have the original > > order of indices as mentioned > > > > by the authors.One way to achieve this is by actually having Ingress > > Based Pointers to the original > > > > Tunnel Table Entries in the MIB.In this way,we can get the specified > > management functionality and also > > > > satisfy the indices rules in the MIB. > > > > Moreover,the RSVP / CR-LDP Signaling protocols have a small > > difference,the difference being the > > > > tunnel instance.So,if one is having both CR-LDP and RSVP operating in a > > disjoint manner ,we may not > > > > consider how we have the Tunnel head configuration. > > > > As I understand that Cisco's implementation has a source address NULL > > or zero to identify tunnel > > > > head configurations. > > No, we follow the paradigm I described earlier where the > tunnelInstance set to 0 to signify the head interface. > > --Tom --------------C4484A87980F4F2298F6A972 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi Tom
   I see what you mean,implementations keep changing for the better,;).
   Regards,
   Abhay


"Thomas D. Nadeau" wrote:

At 09:51 AM 7/16/2001 +0530, abhay wrote:

>Hi,
>
>   There are two sides of the coin here.Walking through the T.E MIB
> requires Chang's indexing idea
>
>   But to have a LSP Management with the T.E MIB we can have the original
> order of indices as mentioned
>
>   by the authors.One way to achieve this is  by actually having Ingress
> Based Pointers to the original
>
>   Tunnel Table Entries in the  MIB.In this way,we can get the specified
> management functionality and also
>
>   satisfy the indices rules in the MIB.
>
>   Moreover,the RSVP / CR-LDP Signaling protocols have a small
> difference,the difference being the
>
>   tunnel instance.So,if one is having both CR-LDP and RSVP operating in a
> disjoint manner ,we may not
>
>   consider how we have the Tunnel head configuration.
>
>   As I understand that Cisco's implementation has a source address NULL
> or zero to identify tunnel
>
>   head configurations.

         No, we follow the paradigm I described earlier where the
tunnelInstance set to 0 to signify the head interface.

         --Tom

--------------C4484A87980F4F2298F6A972-- From owner-mpls@UU.NET Mon Jul 16 09:22: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 JAA06821 for ; Mon, 16 Jul 2001 09: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 QQkxxt27568; Mon, 16 Jul 2001 13:22:03 GMT Received: by mail-control.mail.uu.net id QQkxxt04068 for mpls-outgoing; Mon, 16 Jul 2001 13:21:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxxt04058 for ; Mon, 16 Jul 2001 13:21: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 QQkxxt14825 for ; Mon, 16 Jul 2001 13:19:57 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 QQkxxt25340 for ; Mon, 16 Jul 2001 13:19:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA22615 for mpls@uu.net; Mon, 16 Jul 2001 09:19:56 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxxt03969 for ; Mon, 16 Jul 2001 13:19: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 QQkxxt16224 for ; Mon, 16 Jul 2001 13:18:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkxxt20575 for ; Mon, 16 Jul 2001 13:18:06 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 JAA17849; Mon, 16 Jul 2001 09:17:59 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ADL00172; Mon, 16 Jul 2001 09:17:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20010716092212.0274ad80@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 16 Jul 2001 09:22:21 -0400 To: abhay From: "Thomas D. Nadeau" Subject: Re: mplsTunnelEntry index Cc: Koling Chang , mpls@UU.NET, cheenu@alphion.com, arun@force10networks.com In-Reply-To: <3B52E828.9F075617@multitech.co.in> References: <4.3.2.7.2.20010712174207.017ac6a8@bucket.cisco.com> <4.3.2.7.2.20010716090041.017b5180@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I hope so. 8) --Tom > I see what you mean,implementations keep changing for the better,;). > > Regards, > > Abhay > > >"Thomas D. Nadeau" wrote: >>At 09:51 AM 7/16/2001 +0530, abhay wrote: >> >> >Hi, >> > >> > There are two sides of the coin here.Walking through the T.E MIB >> > requires Chang's indexing idea >> > >> > But to have a LSP Management with the T.E MIB we can have the original >> > order of indices as mentioned >> > >> > by the authors.One way to achieve this is by actually having Ingress >> > Based Pointers to the original >> > >> > Tunnel Table Entries in the MIB.In this way,we can get the specified >> > management functionality and also >> > >> > satisfy the indices rules in the MIB. >> > >> > Moreover,the RSVP / CR-LDP Signaling protocols have a small >> > difference,the difference being the >> > >> > tunnel instance.So,if one is having both CR-LDP and RSVP operating in a >> > disjoint manner ,we may not >> > >> > consider how we have the Tunnel head configuration. >> > >> > As I understand that Cisco's implementation has a source address NULL >> > or zero to identify tunnel >> > >> > head configurations. >> >> No, we follow the paradigm I described earlier where the >>tunnelInstance set to 0 to signify the head interface. >> >> --Tom From owner-mpls@UU.NET Mon Jul 16 09:32: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 SMTP id JAA08299 for ; Mon, 16 Jul 2001 09:32: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 QQkxxu11728; Mon, 16 Jul 2001 13:32:44 GMT Received: by mail-control.mail.uu.net id QQkxxu04976 for mpls-outgoing; Mon, 16 Jul 2001 13:32: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 QQkxxu04971 for ; Mon, 16 Jul 2001 13:32: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 QQkxxu08941 for ; Mon, 16 Jul 2001 13:30:34 GMT Received: from mailFA1.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.146]) id QQkxxu08882 for ; Mon, 16 Jul 2001 13:30:33 GMT Received: (qmail 7675 invoked by uid 510); 16 Jul 2001 13:35:47 -0000 Date: 16 Jul 2001 13:35:47 -0000 Message-ID: <20010716133547.7674.qmail@mailFA1.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 16 Jul 2001 13:35:47 -0000 MIME-Version: 1.0 To: "mpls@uu.net" Subject: doubt related to draft-ietf-mpls-cr-ldp-05.txt From: "George Thomas" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I just started reading the CR-LDP draft. Its mentioned in the CR-LDP Label-request message that the ER-TLV is optional. Without ER-Hops how explicit tunnels will be established? Is should be a mandatory object right. Could you please tell me, in which scenario it can be an optional object. Thanks and Regards, George ____________________________________________________ http://www.monsterindia.com - The Best Jobs. For the Best Minds. From owner-mpls@UU.NET Mon Jul 16 09:34: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 JAA08531 for ; Mon, 16 Jul 2001 09:34: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 QQkxxu18053; Mon, 16 Jul 2001 13:34:18 GMT Received: by mail-control.mail.uu.net id QQkxxu05046 for mpls-outgoing; Mon, 16 Jul 2001 13:33: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 QQkxxu04995 for ; Mon, 16 Jul 2001 13:32: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 QQkxxt00484 for ; Mon, 16 Jul 2001 13:29:37 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 QQkxxt07533 for ; Mon, 16 Jul 2001 13:29:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA23596 for mpls@uu.net; Mon, 16 Jul 2001 09:29:36 -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 QQkxxt04626 for ; Mon, 16 Jul 2001 13:29: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 QQkxxt06827 for ; Mon, 16 Jul 2001 13:29:01 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 QQkxxt06741 for ; Mon, 16 Jul 2001 13:29:00 GMT Received: (qmail 29057 invoked by uid 104); 16 Jul 2001 13:29:00 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.403549 secs); 16/07/2001 06:28:59 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 16 Jul 2001 13:28:59 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6GDSwP25008; Mon, 16 Jul 2001 06:29:01 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 06:34:27 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D75@BBY1EXM01> From: Shahram Davari To: "'Ping Pan'" Cc: "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Mon, 16 Jul 2001 06:34:19 -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 Ping, > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Friday, July 13, 2001 8:05 PM > To: Shahram Davari > Cc: 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram Davari wrote: > > > > Hi All, > > > > How can the LSP-Ping work if the LSP is setup to carry > non-IP traffic? > > > > In an egress LSR there is a binding between an LSP and the > L3 protocol that it is supposed to carry. > > If anything other than IP is carried in an LSP, and we > inject ping packets in to that LSP, the egress > > LSR has no means of parsing that packet. How is this > addressed in this draft? > > > > Shahram, > > If the LSP (IP or non-IP) is initiated via RSVP-TE, then > draft-pan-lsp-ping-00.txt can be used to check the LSP. In this case, > the egress can parse the echo-requests. You are right, it > won't work in > a non-IP network. This is not correct. I am not talking about non-IP networks, I am talking about carrying non-IP traffic through MPLS network. Even if the LSP is initiated via RSVP-TE, you still could have the problem that I described. For example assume that an LSP is setup via RSVP-TE to carry Ethernet traffic (Here I am assuming only one label is used, which is different from Martini drafts). The L3PID will be signaled as Ethernet. In that case the Ethernet packets are encapsulated in MPLS, in other words a label belonging to that LSP is pushed before the Ethernet header. Now the egress LSR, first pops the top label and then does process the remaining payload knowing that it is an Ethernet packet. How does the egress LSR know that the payload is Ethernet? by looking at the NHLFE context which was build up during RSVP-TE signaling. Now what you are suggesting is that we send a Ping packet through the same LSP, using the same label which is used for the normal user-plane traffic. When the egress LSR receives this packet, by looking at the NHLFE table, it assumes that the payload is Ethernet, while your payload is UDP/IP. So the ping packet won't be processed correctly. Therefore you need an identifier that says this is a ping packet, regardless of what the LSP is carrying. One possible method is to use an extra label from the reserved label space. I hope this time I am more clear. Yours, -Shahram > > - Ping > From owner-mpls@UU.NET Mon Jul 16 09:58: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 JAA13121 for ; Mon, 16 Jul 2001 09:58: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 QQkxxv17037; Mon, 16 Jul 2001 13:59:03 GMT Received: by mail-control.mail.uu.net id QQkxxv07890 for mpls-outgoing; Mon, 16 Jul 2001 13:58:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxxv07860 for ; Mon, 16 Jul 2001 13:58:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxxv09328 for ; Mon, 16 Jul 2001 13:57:06 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxxv28618 for ; Mon, 16 Jul 2001 13:57:05 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6GDv3H87658; Mon, 16 Jul 2001 06:57:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200107161357.f6GDv3H87658@merlot.juniper.net> To: Shahram Davari cc: "'Ping Pan'" , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt In-Reply-To: Your message of "Mon, 16 Jul 2001 06:34:19 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6037A6D75@BBY1EXM01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37338.995291823.1@juniper.net> Date: Mon, 16 Jul 2001 06:57:03 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Shahram, > > > How can the LSP-Ping work if the LSP is setup to carry > > > non-IP traffic? > > > > > > In an egress LSR there is a binding between an LSP and the > > > L3 protocol that it is supposed to carry. > > > If anything other than IP is carried in an LSP, and we > > > inject ping packets in to that LSP, the egress > > > LSR has no means of parsing that packet. How is this > > > addressed in this draft? > > > > > > > Shahram, > > > > If the LSP (IP or non-IP) is initiated via RSVP-TE, then > > draft-pan-lsp-ping-00.txt can be used to check the LSP. In this case, > > the egress can parse the echo-requests. You are right, it > > won't work in > > a non-IP network. > > This is not correct. I am not talking about non-IP networks, I am > talking abo ut carrying non-IP traffic through MPLS network. Even > if the LSP is initiated v ia RSVP-TE, you still could have the > problem that I described. For example assume that an LSP is setup > via RSVP-TE to carry Ethernet traffic (Here I am assuming only one > label is used, which is different from Martini drafts). The L3PID > will be sig naled as Ethernet. In that case the Ethernet packets > are encapsulated in MPLS, in othe r words a label belonging to that > LSP is pushed before the Ethernet header. Now the egress LSR, > first pops the top label and then does process the remain ing > payload knowing that it is an Ethernet packet. How does the egress > LSR kno w that the payload is Ethernet? by looking at the NHLFE > context which was build up during RSVP-TE signaling. > > Now what you are suggesting is that we send a Ping packet through > the same LS P, using the same label which is used for the normal > user-plane traffic. When t he egress LSR receives this packet, by > looking at the NHLFE table, it assumes t hat the payload is Ethernet, > while your payload is UDP/IP. So the ping packet won't be processed > correctly. > > Therefore you need an identifier that says this is a ping packet, > regardless of what the LSP is carrying. One possible method is to > use an extra label from the reserved label space. Explicit IPv4 NULL. Yakov. From owner-mpls@UU.NET Mon Jul 16 10:11:38 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 KAA16285 for ; Mon, 16 Jul 2001 10:11: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 QQkxxw02380; Mon, 16 Jul 2001 14:11:30 GMT Received: by mail-control.mail.uu.net id QQkxxw25529 for mpls-outgoing; Mon, 16 Jul 2001 14:10: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 QQkxxw25008 for ; Mon, 16 Jul 2001 14:10:42 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 QQkxxw06371 for ; Mon, 16 Jul 2001 14:10:20 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 QQkxxw23179 for ; Mon, 16 Jul 2001 14:10:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA28245 for mpls@uu.net; Mon, 16 Jul 2001 10:10: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 QQkxxw22807 for ; Mon, 16 Jul 2001 14:09:42 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 QQkxxw07704 for ; Mon, 16 Jul 2001 14:08:12 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 QQkxxw28093 for ; Mon, 16 Jul 2001 14:08:12 GMT Received: (qmail 3912 invoked by uid 104); 16 Jul 2001 14:08:11 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.420209 secs); 16/07/2001 07:08:10 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 16 Jul 2001 14:08:10 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6GE8CP15384; Mon, 16 Jul 2001 07:08:12 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 07:13:41 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D76@BBY1EXM01> From: Shahram Davari To: "'Yakov Rekhter'" Cc: "'Ping Pan'" , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Mon, 16 Jul 2001 07:13:34 -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 Yakov, Good suggestion. However, I think due to periodic transmission of ping packets, and due to possibility of many LSPs being pinged at the same time, the processing overhead of UDP/IP is large and may limit the scalability. Using another reserved label for Ping (or OAM packets in general) could eliminate the use of UDP/IP and could reduce the processing burden at the egress LSR. Yours, -Shahram > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Monday, July 16, 2001 9:57 AM > To: Shahram Davari > Cc: 'Ping Pan'; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > > > > How can the LSP-Ping work if the LSP is setup to carry > > > > non-IP traffic? > > > > > > > > In an egress LSR there is a binding between an LSP and the > > > > L3 protocol that it is supposed to carry. > > > > If anything other than IP is carried in an LSP, and we > > > > inject ping packets in to that LSP, the egress > > > > LSR has no means of parsing that packet. How is this > > > > addressed in this draft? > > > > > > > > > > Shahram, > > > > > > If the LSP (IP or non-IP) is initiated via RSVP-TE, then > > > draft-pan-lsp-ping-00.txt can be used to check the LSP. > In this case, > > > the egress can parse the echo-requests. You are right, it > > > won't work in > > > a non-IP network. > > > > This is not correct. I am not talking about non-IP networks, I am > > talking abo ut carrying non-IP traffic through MPLS network. Even > > if the LSP is initiated v ia RSVP-TE, you still could have the > > problem that I described. For example assume that an LSP is setup > > via RSVP-TE to carry Ethernet traffic (Here I am assuming only one > > label is used, which is different from Martini drafts). The L3PID > > will be sig naled as Ethernet. In that case the Ethernet packets > > are encapsulated in MPLS, in othe r words a label belonging to that > > LSP is pushed before the Ethernet header. Now the egress LSR, > > first pops the top label and then does process the remain ing > > payload knowing that it is an Ethernet packet. How does the egress > > LSR kno w that the payload is Ethernet? by looking at the NHLFE > > context which was build up during RSVP-TE signaling. > > > > Now what you are suggesting is that we send a Ping packet through > > the same LS P, using the same label which is used for the normal > > user-plane traffic. When t he egress LSR receives this packet, by > > looking at the NHLFE table, it assumes t hat the payload is > Ethernet, > > while your payload is UDP/IP. So the ping packet won't be processed > > correctly. > > > > Therefore you need an identifier that says this is a ping packet, > > regardless of what the LSP is carrying. One possible method is to > > use an extra label from the reserved label space. > > Explicit IPv4 NULL. > > Yakov. > From owner-mpls@UU.NET Mon Jul 16 10:27: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 SMTP id KAA19585 for ; Mon, 16 Jul 2001 10:27: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 QQkxxx19337; Mon, 16 Jul 2001 14:27:35 GMT Received: by mail-control.mail.uu.net id QQkxxx01860 for mpls-outgoing; Mon, 16 Jul 2001 14:27:00 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 QQkxxx01828 for ; Mon, 16 Jul 2001 14:26:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxxx14555 for ; Mon, 16 Jul 2001 14:22:18 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 QQkxxx11082 for ; Mon, 16 Jul 2001 14:22:17 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25535 for ; Mon, 16 Jul 2001 10:22:16 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28575 for mpls@uu.net; Mon, 16 Jul 2001 10:22:10 -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 QQkxxg19259 for ; Mon, 16 Jul 2001 10:09:25 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 QQkxxg08387 for ; Mon, 16 Jul 2001 10:08:20 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQkxxg23212 for ; Mon, 16 Jul 2001 10:08:18 GMT Received: from netbrahma.com (khuzema.netbrahma.com [172.16.72.170]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBLHFJM; Mon, 16 Jul 2001 15:36:21 +0530 Message-ID: <3B52BCC1.9F9C8668@netbrahma.com> Date: Mon, 16 Jul 2001 15:36:57 +0530 From: Khuzema Pithewan Organization: Netbrahma Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Session Attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Session Attribute Object in RSVP-TE contains some flags , setup and holding priority and some session related info. My doubt is , if this object is per session or per LSP, because name suggest that it is per session, but holding/setup priorities are the attributes of a LSP. so basically where to keep this Object,?? in PSB or Session??? Khuzema. From owner-mpls@UU.NET Mon Jul 16 10:52: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 KAA25622 for ; Mon, 16 Jul 2001 10:52: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 QQkxxz18207; Mon, 16 Jul 2001 14:52:11 GMT Received: by mail-control.mail.uu.net id QQkxxz05189 for mpls-outgoing; Mon, 16 Jul 2001 14:51: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 QQkxxz05171 for ; Mon, 16 Jul 2001 14:51:24 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 QQkxxz04758 for ; Mon, 16 Jul 2001 14:50:59 GMT Received: from mxtlv1.corrigent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.203.64.34]) id QQkxxz16495 for ; Mon, 16 Jul 2001 14:50:46 GMT Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id <30PCVANG>; Mon, 16 Jul 2001 17:50:15 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B35372560F@mxtlv1.corrigent.com> From: David Zelig To: "'pwe3@ietf.org'" , ppvpn@zephion.net, mpls@UU.NET Subject: New I-Ds related to Pseudo Wire MIBs Date: Mon, 16 Jul 2001 17:50:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-mpls@UU.NET Precedence: bulk All, The following I-Ds describe some of the MIB modules for PW operation. http://www.ietf.org/internet-drafts/draft-zelig-pw-mib-00.txt This draft contains 2 MIB modules: PW-MIB - Configures general parameters for the PW/VC creation and signaling, Independent of PSN type and PW service. It contains performance monitoring common to all service types and 1+1 APS at the VC level configuration. PW-MPLS-MIB: Handles PW carried over MPLS PSN flavours : MPLS-TE, MPLS-LSP and VC only (no outer label). Other PSNs modules will be added in the future. Service specific modules will be defined in seperate i-d. For SoneT circuit emulation (CEM), the following MIB is available: http://search.ietf.org/internet-drafts/draft-danenberg-pw-cem-mib-00.txt http://search.ietf.org/internet-drafts/draft-nadeau-pw-tc-mib-00.txt contains the textual conventions used in the PW MIBs modules. Remarks and discussion are welcomed. David From owner-mpls@UU.NET Mon Jul 16 12:30: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 SMTP id MAA15586 for ; Mon, 16 Jul 2001 12:30: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 QQkxyg23951; Mon, 16 Jul 2001 16:30:27 GMT Received: by mail-control.mail.uu.net id QQkxyf25332 for mpls-outgoing; Mon, 16 Jul 2001 16:29:52 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 QQkxyf25325 for ; Mon, 16 Jul 2001 16:29: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 QQkxyf25689 for ; Mon, 16 Jul 2001 16:29:45 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkxyf20457 for ; Mon, 16 Jul 2001 16:29:44 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 16 Jul 2001 22:07:28 +0530 Received: from mohanvak (mohanvak.future.futsoft.com [10.20.6.31]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f6GGTMX07583; Mon, 16 Jul 2001 21:59:22 +0530 Reply-To: From: "Mohan Verma" To: "'George Thomas'" , Subject: RE: doubt related to draft-ietf-mpls-cr-ldp-05.txt Date: Mon, 16 Jul 2001 21:42:08 +1000 Message-Id: <000201c10dec$589b4be0$1f06140a@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) In-Reply-To: <20010716133547.7674.qmail@mailFA1.rediffmail.com> 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, There is egressId in the te-mib as index through which I hope you can still get the tunnel?? mohan -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of George Thomas Sent: Monday, July 16, 2001 11:36 PM To: mpls@uu.net Subject: doubt related to draft-ietf-mpls-cr-ldp-05.txt Hi, I just started reading the CR-LDP draft. Its mentioned in the CR-LDP Label-request message that the ER-TLV is optional. Without ER-Hops how explicit tunnels will be established? Is should be a mandatory object right. Could you please tell me, in which scenario it can be an optional object. Thanks and Regards, George ____________________________________________________ http://www.monsterindia.com - The Best Jobs. For the Best Minds. From owner-mpls@UU.NET Mon Jul 16 12:32: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 MAA15907 for ; Mon, 16 Jul 2001 12:32:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxyg26902; Mon, 16 Jul 2001 16:32:17 GMT Received: by mail-control.mail.uu.net id QQkxyg25501 for mpls-outgoing; Mon, 16 Jul 2001 16:31: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 QQkxyg25400 for ; Mon, 16 Jul 2001 16:30: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 QQkxyf10612 for ; Mon, 16 Jul 2001 16:28:31 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 QQkxyf19535 for ; Mon, 16 Jul 2001 16:28:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA10750 for mpls@uu.net; Mon, 16 Jul 2001 12:28:30 -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 QQkxyf25191 for ; Mon, 16 Jul 2001 16:27: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 QQkxyf16917 for ; Mon, 16 Jul 2001 16:23:41 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxyf12017 for ; Mon, 16 Jul 2001 16:23:40 GMT Received: from juniper.net ([172.16.167.236]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6GGNcH91690; Mon, 16 Jul 2001 09:23:38 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B531500.A9597E5C@juniper.net> Date: Mon, 16 Jul 2001 09:23:28 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D76@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > Hi Yakov, > > Good suggestion. However, I think due to periodic transmission of ping packets, and due > to possibility of many LSPs being pinged at the same time, the processing overhead of UDP/IP > is large and may limit the scalability. Shahram, That's why we choose a two-step ping: ICMP ping's followed by LSP ping's. Normally, the ingress sends the regular ICMP ping's to check LSP's. Only when there is no reply on ICMP ping's, LSP-ping messages are sent to detect if the failure is on the forwarding or the reverse LSP. The reason for using UDP is to allow the egress LSR's to regulate the LSP-ping traffic.... Don't think there is a scalability problem here. > Using another reserved label for Ping > (or OAM packets in general) could eliminate the use of UDP/IP and could reduce the processing burden at > the egress LSR. > How? At egress, ping packets need to be processed anyway. You still have to somehow limit the amount of probing traffic. BTW, I will add the idea of using Explicit IPv4 NULL for non-IP traffic in the next version. - Ping From owner-mpls@UU.NET Mon Jul 16 12:51:25 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 MAA20315 for ; Mon, 16 Jul 2001 12:51: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 QQkxyh19276; Mon, 16 Jul 2001 16:51:34 GMT Received: by mail-control.mail.uu.net id QQkxyh27850 for mpls-outgoing; Mon, 16 Jul 2001 16:51: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 QQkxyh27835 for ; Mon, 16 Jul 2001 16:50:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkxyh16468 for ; Mon, 16 Jul 2001 16:46:57 GMT Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQkxyh04826 for ; Mon, 16 Jul 2001 16:46:56 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA17143; Mon, 16 Jul 2001 16:46:43 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 16 Jul 2001 16:46:43 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1N9LMM>; Mon, 16 Jul 2001 09:46:40 -0700 Message-ID: From: "Feng, Mark" To: "'adithya@sasken.com'" , mpls@UU.NET Subject: RE: Some Doubts Date: Mon, 16 Jul 2001 09:46:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E16.DF4D50A0" 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_01C10E16.DF4D50A0 Content-Type: text/plain; charset="ISO-8859-1" To establish a LSP within a MPLS network, from the "first MPLS node on the path"/ingress node to the "last MPLS node on the path"/egress node, the ingress node should be the one to initiate the Path message. Hope this helps. Mark -----Original Message----- From: Adithya Bhat [mailto:adithya@sasken.com] Sent: Monday, July 16, 2001 2:26 AM To: mpls@uu.net Cc: Feng, Mark; sridhar@samsung.co.kr Subject: Re: Some Doubts Thanks for the reply, In the same draft Section 2.2 say:- "To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message." If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence? Does it not mean that some nodes along the path are non mpls ?? Thanks, Adithya "Feng, Mark" wrote: The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path." means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark -----Original Message----- From: Adithya Bhat [ mailto:adithya@sasken.com ] Sent: Thursday, July 12, 2001 11:58 PM To: mpls@UU.NET Subject: Some Doubts Hi *, In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." 1. Why should a PathErr be sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back. 2. If the above is not true does it mean that all the routers (from the sender to the reciever ) should be rsvp-te capable ( should support labels) routers ? 3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in the path." Please throw some light on this, Thanks in advance Adithya ------_=_NextPart_001_01C10E16.DF4D50A0 Content-Type: text/html; charset="ISO-8859-1"
To establish a LSP within a MPLS network, from the "first MPLS node on the path"/ingress node to the "last MPLS node on the path"/egress node, the ingress node should be the one to initiate the Path message.
 
Hope this helps.
 
Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Monday, July 16, 2001 2:26 AM
To: mpls@uu.net
Cc: Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some Doubts

 
Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

 The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts
 
Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

------_=_NextPart_001_01C10E16.DF4D50A0-- From owner-mpls@UU.NET Mon Jul 16 13:59: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 NAA05958 for ; Mon, 16 Jul 2001 13:59: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 QQkxyl22141; Mon, 16 Jul 2001 17:59:00 GMT Received: by mail-control.mail.uu.net id QQkxyl25521 for mpls-outgoing; Mon, 16 Jul 2001 17:58: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 QQkxyl25508 for ; Mon, 16 Jul 2001 17:58: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 QQkxyl01481 for ; Mon, 16 Jul 2001 17:57:43 GMT Received: from huginn.ctccom.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: Huginn.CTCCom.net [207.190.194.11]) id QQkxyl18136 for ; Mon, 16 Jul 2001 17:57:42 GMT Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ADH44011; Mon, 16 Jul 2001 13:57:30 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: , Cc: "'Feng, Mark'" , Subject: RE: Some Doubts Date: Mon, 16 Jul 2001 14:00:30 -0400 Message-ID: <00af01c10e21$345e7600$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01C10DFF.AD4CD600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B52B311.D2FA1B45@sasken.com> Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01C10DFF.AD4CD600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI All, Is it possible to have MPLS aware nodes but not aware of RSVP-TE??? Regards Madhubabu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat Sent: Monday, July 16, 2001 5:26 AM To: mpls@UU.NET Cc: Feng, Mark; sridhar@samsung.co.kr Subject: Re: Some Doubts Thanks for the reply, In the same draft Section 2.2 say:- "To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message." If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence? Does it not mean that some nodes along the path are non mpls ?? Thanks, Adithya "Feng, Mark" wrote: The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path." means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark -----Original Message----- From: Adithya Bhat [mailto:adithya@sasken.com] Sent: Thursday, July 12, 2001 11:58 PM To: mpls@UU.NET Subject: Some Doubts Hi *, In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." 1. Why should a PathErr be sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back. 2. If the above is not true does it mean that all the routers (from the sender to the reciever ) should be rsvp-te capable ( should support labels) routers ? 3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in the path." Please throw some light on this, Thanks in advance Adithya ------=_NextPart_000_00B0_01C10DFF.AD4CD600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI=20 All,
Is it=20 possible to have MPLS aware nodes but not aware of=20 RSVP-TE???
 
Regards
Madhubabu
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Adithya = Bhat
Sent:=20 Monday, July 16, 2001 5:26 AM
To: mpls@UU.NET
Cc: = Feng,=20 Mark; sridhar@samsung.co.kr
Subject: Re: Some=20 Doubts

 
Thanks for the reply,
In the = same=20 draft Section  2.2 say:-=20

 "To create an LSP tunnel, the first MPLS node on the path -- = that is,=20
   the sender node with respect to the path -- creates = an RSVP=20 Path
   message with a session type of LSP_TUNNEL_IPv4 = or=20 LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object = into the=20 Path message."=20

If each node along the way must support = RSVT-TE/Label=20 Request, Then what is the meaning of "the first MPLS node on the = path "=20 in the above sentence?
Does it not = mean that=20 some nodes  along the path are non mpls ??=20

Thanks,=20

Adithya
 =20
 =20

"Feng, Mark" wrote:=20

 The intention is = to establish a=20 LSP from the ingress to the egress. I don't think it is appropriate = for a=20 transit node to terminate the request in such manner. For example, = if the=20 ingress receives the Resv, how does it know how far the LSP has been = established?On the other = hand, when the=20 ingress node receives the PathErr, it knows what the problem is. It = could=20 decide to try the transit node as the egress node, though I don't = know why=20 it would want to do so.I guess you are = right that in=20 MPLS, each node along the way must support RSVT-TE/Label Request. If = one of=20 the nodes along the path cannot process the Label Request, that = means the=20 connection cannot be established end-to-end. As a result, we don't = have a=20 label-switched-path."MPLS being = negotiated,=20 but a non-RSVP capable router stands in the path."  means just = that,=20 there is a non-RSVP capable router on the intended=20 path.Hope this helps.Mark=20
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]<= /FONT>=20
Sent: Thursday, = July 12, 2001=20 11:58 PM
To:=20 mpls@UU.NET
Subject: Some Doubts =
 
Hi *,=20

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says=20

        "RSVP is designed to = cope=20 gracefully with non-RSVP routers anywhere
   between = senders=20 and receivers. However, obviously, non-RSVP routers =
  =20 cannot convey labels via RSVP. This means that if a router has a=20
   neighbor that is known to not be RSVP capable, = the router=20 MUST NOT
   advertise the LABEL_REQUEST object when = sending=20 messages that pass
   through the non-RSVP = routers. =20 The router SHOULD send a PathErr back
   to the = sender, with=20 the error code "Routing problem" and the error
   = value=20 "MPLS being negotiated, but a non-RSVP capable router stands in=20
   the path."=20

1. Why should a PathErr be  sent back to the sender ? Will = the=20 current router not be a egress router, and hence should send a = label=20 binding back.=20

2.  If the above is not true does it mean that all the = routers=20 (from the sender  to the reciever ) should be  rsvp-te = capable (=20 should support labels)  routers ?=20

3. What is the meaning of "MPLS being negotiated, but a = non-RSVP=20 capable router stands in
   the path."=20

 Please throw some light on this,=20

Thanks in advance
 =20

Adithya =
 

------=_NextPart_000_00B0_01C10DFF.AD4CD600-- From owner-mpls@UU.NET Mon Jul 16 14:23: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 SMTP id OAA10895 for ; Mon, 16 Jul 2001 14:23: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 QQkxyn22929; Mon, 16 Jul 2001 18:23:21 GMT Received: by mail-control.mail.uu.net id QQkxyn17833 for mpls-outgoing; Mon, 16 Jul 2001 18: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 QQkxyn17816 for ; Mon, 16 Jul 2001 18:22: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 QQkxyn13171 for ; Mon, 16 Jul 2001 18:17:13 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkxyn25908 for ; Mon, 16 Jul 2001 18:17:13 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6GIHCB02352 for ; Mon, 16 Jul 2001 14:17:12 -0400 (EDT) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6GIHCE02348 for ; Mon, 16 Jul 2001 14:17:12 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Jul 2001 14:17:12 -0400 Message-ID: From: "Jiang, Donghua (Donghua)" To: "'Madhu Babu Brahmanapally'" Cc: "'mpls@uu.net'" Subject: RE: Some Doubts Date: Mon, 16 Jul 2001 14:17:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E23.86E121F0" 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_01C10E23.86E121F0 Content-Type: text/plain Madhubabu, Not, unless you prefer CR-LDP. Regards, Jane D. Jiang -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Monday, July 16, 2001 11:01 AM To: adithya@sasken.com; mpls@UU.NET Cc: 'Feng, Mark'; sridhar@samsung.co.kr Subject: RE: Some Doubts HI All, Is it possible to have MPLS aware nodes but not aware of RSVP-TE??? Regards Madhubabu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat Sent: Monday, July 16, 2001 5:26 AM To: mpls@UU.NET Cc: Feng, Mark; sridhar@samsung.co.kr Subject: Re: Some Doubts Thanks for the reply, In the same draft Section 2.2 say:- "To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message." If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence? Does it not mean that some nodes along the path are non mpls ?? Thanks, Adithya "Feng, Mark" wrote: The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path." means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark -----Original Message----- From: Adithya Bhat [ mailto:adithya@sasken.com ] Sent: Thursday, July 12, 2001 11:58 PM To: mpls@UU.NET Subject: Some Doubts Hi *, In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." 1. Why should a PathErr be sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back. 2. If the above is not true does it mean that all the routers (from the sender to the reciever ) should be rsvp-te capable ( should support labels) routers ? 3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in the path." Please throw some light on this, Thanks in advance Adithya ------_=_NextPart_001_01C10E23.86E121F0 Content-Type: text/html
Madhubabu,
 
Not, unless you prefer CR-LDP.
 
Regards,
Jane D. Jiang
-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Monday, July 16, 2001 11:01 AM
To: adithya@sasken.com; mpls@UU.NET
Cc: 'Feng, Mark'; sridhar@samsung.co.kr
Subject: RE: Some Doubts

HI All,
Is it possible to have MPLS aware nodes but not aware of RSVP-TE???
 
Regards
Madhubabu
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat
Sent: Monday, July 16, 2001 5:26 AM
To: mpls@UU.NET
Cc: Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some Doubts

 
Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

 The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts
 
Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

------_=_NextPart_001_01C10E23.86E121F0-- From owner-mpls@UU.NET Mon Jul 16 14:28: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 OAA12087 for ; Mon, 16 Jul 2001 14:28: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 QQkxyn13121; Mon, 16 Jul 2001 18:28:25 GMT Received: by mail-control.mail.uu.net id QQkxyn18127 for mpls-outgoing; Mon, 16 Jul 2001 18:27:52 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 QQkxyn18109 for ; Mon, 16 Jul 2001 18:27: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 QQkxyn13390 for ; Mon, 16 Jul 2001 18:24:57 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 QQkxyn25019 for ; Mon, 16 Jul 2001 18:24:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA20484 for mpls@uu.net; Mon, 16 Jul 2001 14:24:56 -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 QQkxyn17803 for ; Mon, 16 Jul 2001 18:22: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 QQkxyn06790 for ; Mon, 16 Jul 2001 18:19:48 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 QQkxyn29581 for ; Mon, 16 Jul 2001 18:19:47 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 f6GIJR917274 for ; Mon, 16 Jul 2001 14:19:28 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 16 Jul 2001 14:19:30 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26HV8>; Mon, 16 Jul 2001 14:19:33 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mpls@uu.net'" Subject: CFP: Next Generation Internet at ICC 2002 Date: Mon, 16 Jul 2001 14:19:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E23.D845ECB0" 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_01C10E23.D845ECB0 Content-Type: text/plain CALL FOR PAPERS Next Generation Internet Symposium IN CONJUNCTION WITH ICC 2002 April 28-May 2, 2002 New York, NY USA As part of ICC 2002, a symposium on the Next Generation Internet will be held. Participation in this symposium is open to all registrants of ICC 2002 (i.e. a separate registration is not required). Papers submitted for consideration to the symposium should focus on topics related to the Next Generation Internet (i.e. addressing issues and areas that will not be deployed in the public Internet for at least 3-5 years). Examples of topics of interest include: * NGI Performance * NGI Architecture * QoS - Fact or Fiction * Streaming Media * Home Networking-based Internet * Voice over IP Services * Internet Service Management * Internet Appliances * Next Generation Optical * NGI Protocols Internet * NGI Operations & Management * NGI Applications and * Monitoring and measurements Services for next-generation networks * NGI modeling and * Middleboxes (in-the-net services) simulation tools * Network-friendly applications * Interplanetary issues Instructions: The paper submission schedule and process is the same as for the general ICC 2002 conference (see http://www.icc2002.com/InfoForAuthors.html). Be sure to indicate the Next Generation Internet (NGI) symposium as the target for your paper on the cover page and also list the relevant hot topic(s). See the ICC 2002 Call for Papers for detailed submission Instructions (i.e., schedule, paper-length, etc.). Business Application Sessions (i.e. panel discussions) proposals are also welcome. For these, please submit session proposals to Stan Moyer and include a brief description of the session, along with bios of the session organizer/moderator and the proposed speakers. Further information can be obtained from: Stan Moyer Michael Devetsikiotis General Co-Chair General Co-Chair Telcordia Technologies North Carolina State University stanm@research.telcordia.com mdevets@eos.ncsu.edu Sponsored by the following IEEE Communications Society Technical Committees: * Communications Systems * Computer Communications Integration & Modeling * Communications Software * Personal Communications Technical Program Committee: Symeon Papavassiliou, New Jersey Institute of Technology Nelson Fonseca, State University of Campinas, Brazil Pascal Lorenz, University of Haute-Alsace, France Mohammad Ilyas, Florida Atlantic University Algirdas Pakstas, University of North London Ray Sundararaman, Lucent Amitabh Mishra, Virginia Polytech Joe Touch, USC Information Sciences Institute Tim Moors, Polytechnic University Bassam Hashem, Nortel Networks Alagan Anpalagan, University of Toronto S.-H. Gary Chan, Hong Kong University of Science and Technology Sung Jun Lee, HP Labs Elizabeth Royer, UC Santa Barbara Muhammad Jaseemuddin, Nortel Networks Ted Faber, USC Information Sciences Institute Eric Nahum, IBM Watson Research Vishal Misra, University of Massachusetts Behcet Sarikaya, Alcatel USA David Harle, University of Strathclyde, Scotland Jogesh Muppala, Hong Kong University of Science & Technology l For more information, see: http://www.comsoc.org/socstr/techcom/commsoft/confs/ngi_cfp.htm ------_=_NextPart_001_01C10E23.D845ECB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable CFP: Next Generation Internet at ICC 2002

           &= nbsp;        CALL FOR PAPERS
           Next = Generation Internet Symposium

IN CONJUNCTION WITH ICC = 2002
April 28-May 2, 2002 New York, = NY USA

As part of ICC 2002, a symposium = on the Next Generation Internet
will be held. Participation in = this symposium is open to all
registrants of ICC 2002 (i.e. a = separate registration is not
required).

Papers submitted for = consideration to the symposium should focus on
topics related to the Next = Generation Internet (i.e. addressing
issues and areas that will not = be deployed in the public Internet
for at least 3-5 years). = Examples of topics of interest include:
  * NGI = Performance          &= nbsp;         * NGI = Architecture
  * QoS - Fact or = Fiction           = ;   * Streaming Media
  * Home Networking-based = Internet     * Voice over IP
    = Services          &nbs= p;           &nbs= p;    * Internet Service
           &= nbsp;           &= nbsp;           &= nbsp;     Management
  * Internet = Appliances          &n= bsp;     * Next Generation Optical
  * NGI = Protocols          &nb= sp;           &nb= sp; Internet
  * NGI Operations & = Management        * NGI Applications = and
  * Monitoring and = measurements          = Services
    for = next-generation networks       * NGI = modeling and
  * Middleboxes = (in-the-net services)    simulation tools
  * Network-friendly = applications      * Interplanetary = issues

Instructions: The paper = submission schedule and process is the same
as for the general ICC 2002 = conference (see
http://www.icc2002.com/InfoForAuthors.html<= /U>). Be sure to indicate = the
Next Generation Internet (NGI) = symposium as the target for your
paper on the cover page and = also list the relevant hot topic(s).
See the ICC 2002 Call for = Papers for detailed submission
Instructions (i.e., schedule, = paper-length, etc.).

Business Application Sessions = (i.e. panel discussions) proposals are
also welcome. For these, please = submit session proposals to Stan
Moyer and include a brief = description of the session, along with
bios of the session = organizer/moderator and the proposed speakers.
           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;
Further information can be = obtained from:
  Stan = Moyer           &= nbsp;           = Michael Devetsikiotis
  General = Co-Chair          &nbs= p;      General Co-Chair
  Telcordia = Technologies          = North Carolina State University
  = stanm@research.telcordia.com     = mdevets@eos.ncsu.edu

Sponsored by the following IEEE = Communications Society Technical
Committees:
 * Communications = Systems    * Computer Communications
   Integration & = Modeling    * Communications Software
 * Personal = Communications

Technical Program = Committee:

     Symeon = Papavassiliou, New Jersey Institute of Technology
     Nelson = Fonseca, State University of Campinas, Brazil
     Pascal = Lorenz, University of Haute-Alsace, France
     = Mohammad Ilyas, Florida Atlantic University
     = Algirdas Pakstas, University of North London
     Ray = Sundararaman, Lucent
     = Amitabh Mishra, Virginia Polytech
     Joe = Touch, USC Information Sciences Institute
     Tim = Moors, Polytechnic University
     Bassam = Hashem, Nortel Networks
     Alagan = Anpalagan, University of Toronto
     S.-H. = Gary Chan, Hong Kong University of Science and Technology
     Sung = Jun Lee, HP Labs
     = Elizabeth Royer, UC Santa Barbara
     = Muhammad Jaseemuddin, Nortel Networks
     Ted = Faber, USC Information Sciences Institute
     Eric = Nahum, IBM Watson Research
     Vishal = Misra, University of Massachusetts
     Behcet = Sarikaya, Alcatel USA
     David = Harle, University of Strathclyde, Scotland
     Jogesh = Muppala, Hong Kong University of Science & Technology
           &= nbsp;           &= nbsp;            = l
For more information, = see:
http://www.comsoc.org/socstr/techcom/commsoft/confs/ng= i_cfp.htm

------_=_NextPart_001_01C10E23.D845ECB0-- From owner-mpls@UU.NET Mon Jul 16 14:38: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 SMTP id OAA13738 for ; Mon, 16 Jul 2001 14:38: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 QQkxyo27039; Mon, 16 Jul 2001 18:38:09 GMT Received: by mail-control.mail.uu.net id QQkxyo18939 for mpls-outgoing; Mon, 16 Jul 2001 18:37:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxyo18917 for ; Mon, 16 Jul 2001 18:37: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 QQkxyo06385 for ; Mon, 16 Jul 2001 18:34:08 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 QQkxyo07244 for ; Mon, 16 Jul 2001 18:34:08 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.41 2001/07/09 21:06:22 root Exp $) with ESMTP id SAA08429; Mon, 16 Jul 2001 18:34:06 GMT Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id <30MJRK0M>; Mon, 16 Jul 2001 11:34:04 -0700 Message-ID: From: "Feng, Mark" To: "'Madhu Babu Brahmanapally'" , mpls@UU.NET Subject: RE: Some Doubts Date: Mon, 16 Jul 2001 11:33:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E25.DEA86040" 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_01C10E25.DEA86040 Content-Type: text/plain; charset="iso-8859-1" The bottom line is that, the label request must be understood and processed by each node along the LSP path. You could have nodes along the way that are not RSVP-TE, but the neighboring nodes has to do RSVP/LDP interworking. As far as I know, there is no RFC/draft to address this. So, it is not possible right now. Mark -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Monday, July 16, 2001 11:01 AM To: adithya@sasken.com; mpls@UU.NET Cc: 'Feng, Mark'; sridhar@samsung.co.kr Subject: RE: Some Doubts HI All, Is it possible to have MPLS aware nodes but not aware of RSVP-TE??? Regards Madhubabu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat Sent: Monday, July 16, 2001 5:26 AM To: mpls@UU.NET Cc: Feng, Mark; sridhar@samsung.co.kr Subject: Re: Some Doubts Thanks for the reply, In the same draft Section 2.2 say:- "To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message." If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence? Does it not mean that some nodes along the path are non mpls ?? Thanks, Adithya "Feng, Mark" wrote: The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path." means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark -----Original Message----- From: Adithya Bhat [ mailto:adithya@sasken.com ] Sent: Thursday, July 12, 2001 11:58 PM To: mpls@UU.NET Subject: Some Doubts Hi *, In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." 1. Why should a PathErr be sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back. 2. If the above is not true does it mean that all the routers (from the sender to the reciever ) should be rsvp-te capable ( should support labels) routers ? 3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in the path." Please throw some light on this, Thanks in advance Adithya ------_=_NextPart_001_01C10E25.DEA86040 Content-Type: text/html; charset="iso-8859-1"
The bottom line is that, the label request must be understood and processed by each node along the LSP path. You could have nodes along the way that are not RSVP-TE,  but the neighboring nodes has to do RSVP/LDP interworking. As far as I know, there is no RFC/draft to address this. So, it is not possible right now.
 
Mark
-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Monday, July 16, 2001 11:01 AM
To: adithya@sasken.com; mpls@UU.NET
Cc: 'Feng, Mark'; sridhar@samsung.co.kr
Subject: RE: Some Doubts

HI All,
Is it possible to have MPLS aware nodes but not aware of RSVP-TE???
 
Regards
Madhubabu
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat
Sent: Monday, July 16, 2001 5:26 AM
To: mpls@UU.NET
Cc: Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some Doubts

 
Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

 The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts
 
Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

------_=_NextPart_001_01C10E25.DEA86040-- From owner-mpls@UU.NET Mon Jul 16 14:45: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 OAA14961 for ; Mon, 16 Jul 2001 14:45: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 QQkxyp21049; Mon, 16 Jul 2001 18:46:01 GMT Received: by mail-control.mail.uu.net id QQkxyp19735 for mpls-outgoing; Mon, 16 Jul 2001 18:45: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 QQkxyp19725 for ; Mon, 16 Jul 2001 18:45: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 QQkxyo09243 for ; Mon, 16 Jul 2001 18:39:39 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 QQkxyo13245 for ; Mon, 16 Jul 2001 18:39:39 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA22138 for mpls@uu.net; Mon, 16 Jul 2001 14:39:39 -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 QQkxyo18373 for ; Mon, 16 Jul 2001 18:30:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkxyn18676 for ; Mon, 16 Jul 2001 18:27:19 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 QQkxyn28077 for ; Mon, 16 Jul 2001 18:27:18 GMT Received: (qmail 18117 invoked by uid 104); 16 Jul 2001 18:27:17 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.421126 secs); 16/07/2001 11:27:17 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 16 Jul 2001 18:27:17 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6GIRJP11911; Mon, 16 Jul 2001 11:27:19 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 11:32:48 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D78@BBY1EXM01> From: Shahram Davari To: "'Ping Pan'" Cc: "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Mon, 16 Jul 2001 11:32: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 Ping, Thanks for your reply. I have a fundamental question: If all you are looking for is whether the reverse path is functional or not why not do the following: By running periodic ICMP pings over the reverse path, the ingress LSR could find whether the reverse path is functional or not. This can be done by the ingress LSR checking whether it is receiving reverse' path ICMP pings regularly that have source addresses equal to the destination address of the forwarding path ICMP Ping. And therefore can find whether a failed ICMP ping over the forwarding path is due to forwarding path failure or reverse path failure. What is wrong with this approach as compared to LSP-ping. -Shahram > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Monday, July 16, 2001 12:23 PM > To: Shahram Davari > Cc: 'Yakov Rekhter'; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram Davari wrote: > > > > Hi Yakov, > > > > Good suggestion. However, I think due to periodic > transmission of ping packets, and due > > to possibility of many LSPs being pinged at the same time, > the processing overhead of UDP/IP > > is large and may limit the scalability. > > Shahram, > > That's why we choose a two-step ping: ICMP ping's followed by LSP > ping's. Normally, the ingress sends the regular ICMP ping's to check > LSP's. Only when there is no reply on ICMP ping's, LSP-ping > messages are > sent to detect if the failure is on the forwarding or the reverse LSP. > The reason for using UDP is to allow the egress LSR's to regulate the > LSP-ping traffic.... Don't think there is a scalability problem here. > > > Using another reserved label for Ping > > (or OAM packets in general) could eliminate the use of > UDP/IP and could reduce the processing burden at > > the egress LSR. > > > > How? At egress, ping packets need to be processed anyway. You > still have > to somehow limit the amount of probing traffic. > > BTW, I will add the idea of using Explicit IPv4 NULL for > non-IP traffic > in the next version. > > - Ping > From owner-mpls@UU.NET Mon Jul 16 14:50: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 OAA15661 for ; Mon, 16 Jul 2001 14:50: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 QQkxyp15609; Mon, 16 Jul 2001 18:50:03 GMT Received: by mail-control.mail.uu.net id QQkxyp20159 for mpls-outgoing; Mon, 16 Jul 2001 18:49: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 QQkxyp20139 for ; Mon, 16 Jul 2001 18:49: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 QQkxyp26073 for ; Mon, 16 Jul 2001 18:48:05 GMT Received: from huginn.ctccom.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: Huginn.CTCCom.net [207.190.194.11]) id QQkxyp24180 for ; Mon, 16 Jul 2001 18:48:05 GMT Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ADH44697; Mon, 16 Jul 2001 14:48:00 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Feng, Mark'" , Subject: RE: Some Doubts Date: Mon, 16 Jul 2001 14:51:00 -0400 Message-ID: <00d801c10e28$420614a0$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C10E06.BAF474A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C10E06.BAF474A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Feng,All, When there are two possible solutions like CR-LDP and RSVP-TE, there should be some IWF (might be in form of RFC ) between these as IMO both are going to stay for ever. Regards Madhubabu -----Original Message----- From: Feng, Mark [mailto:m_feng@trillium.com] Sent: Monday, July 16, 2001 2:34 PM To: 'Madhu Babu Brahmanapally'; mpls@UU.NET Subject: RE: Some Doubts The bottom line is that, the label request must be understood and processed by each node along the LSP path. You could have nodes along the way that are not RSVP-TE, but the neighboring nodes has to do RSVP/LDP interworking. As far as I know, there is no RFC/draft to address this. So, it is not possible right now. Mark -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Monday, July 16, 2001 11:01 AM To: adithya@sasken.com; mpls@UU.NET Cc: 'Feng, Mark'; sridhar@samsung.co.kr Subject: RE: Some Doubts HI All, Is it possible to have MPLS aware nodes but not aware of RSVP-TE??? Regards Madhubabu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat Sent: Monday, July 16, 2001 5:26 AM To: mpls@UU.NET Cc: Feng, Mark; sridhar@samsung.co.kr Subject: Re: Some Doubts Thanks for the reply, In the same draft Section 2.2 say:- "To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message." If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence? Does it not mean that some nodes along the path are non mpls ?? Thanks, Adithya "Feng, Mark" wrote: The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path." means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark -----Original Message----- From: Adithya Bhat [mailto:adithya@sasken.com] Sent: Thursday, July 12, 2001 11:58 PM To: mpls@UU.NET Subject: Some Doubts Hi *, In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." 1. Why should a PathErr be sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back. 2. If the above is not true does it mean that all the routers (from the sender to the reciever ) should be rsvp-te capable ( should support labels) routers ? 3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in the path." Please throw some light on this, Thanks in advance Adithya ------=_NextPart_000_00D9_01C10E06.BAF474A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Feng,All,
When=20 there are two possible solutions like CR-LDP and RSVP-TE, there should = be some=20 IWF (might be in form of RFC ) between these as IMO both are going to = stay for=20 ever.
 
Regards
Madhubabu
-----Original Message-----
From: Feng, Mark=20 [mailto:m_feng@trillium.com]
Sent: Monday, July 16, 2001 = 2:34=20 PM
To: 'Madhu Babu Brahmanapally'; = mpls@UU.NET
Subject:=20 RE: Some Doubts

The=20 bottom line is that, the label request must be understood and = processed by=20 each node along the LSP path. You could have nodes along the way that = are not=20 RSVP-TE,  but the neighboring nodes has to do RSVP/LDP = interworking. As=20 far as I know, there is no RFC/draft to address this. So, it is not = possible=20 right now.
 
Mark
-----Original Message-----
From: Madhu Babu = Brahmanapally=20 [mailto:madhubabu@kenetec.com]
Sent: Monday, July 16, 2001 = 11:01=20 AM
To: adithya@sasken.com; mpls@UU.NET
Cc: = 'Feng, Mark';=20 sridhar@samsung.co.kr
Subject: RE: Some=20 Doubts

HI=20 All,
Is=20 it possible to have MPLS aware nodes but not aware of=20 RSVP-TE???
 
Regards
Madhubabu
-----Original Message-----
From: = owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Adithya = Bhat
Sent:=20 Monday, July 16, 2001 5:26 AM
To: = mpls@UU.NET
Cc:=20 Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some=20 Doubts

 
Thanks for the reply,
In = the=20 same draft Section  2.2 say:-=20

 "To create an LSP tunnel, the first MPLS node on the path = -- that=20 is,
   the sender node with respect to the path -- = creates=20 an RSVP Path
   message with a session type of=20 LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a=20 LABEL_REQUEST object into the Path message."=20

If each node along the way must support=20 RSVT-TE/Label Request, Then what is the meaning of "the first = MPLS node=20 on the path " in the above sentence?
Does it not mean that some nodes  along the = path are=20 non mpls ??=20

Thanks,=20

Adithya
 
 =20

"Feng, Mark" wrote:=20

 The intention = is to=20 establish a LSP from the ingress to the egress. I don't think it = is=20 appropriate for a transit node to terminate the request in such = manner.=20 For example, if the ingress receives the Resv, how does it know = how far=20 the LSP has been established?On the other = hand, when the=20 ingress node receives the PathErr, it knows what the problem is. = It=20 could decide to try the transit node as the egress node, though = I don't=20 know why it would want to do = so.I guess you = are right that=20 in MPLS, each node along the way must support RSVT-TE/Label = Request. If=20 one of the nodes along the path cannot process the Label = Request, that=20 means the connection cannot be established end-to-end. As a = result, we=20 don't have a = label-switched-path."MPLS = being=20 negotiated, but a non-RSVP capable router stands in the = path." =20 means just that, there is a non-RSVP capable router on the = intended=20 path.Hope this=20 helps.Mark=20
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]<= /FONT>=20
Sent: Thursday, = July 12,=20 2001 11:58 PM
To: mpls@UU.NET
Subject: Some = Doubts=20
 
Hi *,=20

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 = says=20

        "RSVP is = designed to=20 cope gracefully with non-RSVP routers anywhere =
  =20 between senders and receivers. However, obviously, non-RSVP = routers=20
   cannot convey labels via RSVP. This means = that if a=20 router has a
   neighbor that is known to not be = RSVP=20 capable, the router MUST NOT
   advertise the=20 LABEL_REQUEST object when sending messages that pass =
  =20 through the non-RSVP routers.  The router SHOULD send a = PathErr=20 back
   to the sender, with the error code = "Routing=20 problem" and the error
   value "MPLS being = negotiated,=20 but a non-RSVP capable router stands in
   the = path."=20

1. Why should a PathErr be  sent back to the sender ? = Will the=20 current router not be a egress router, and hence should send a = label=20 binding back.=20

2.  If the above is not true does it mean that all the = routers=20 (from the sender  to the reciever ) should be  = rsvp-te=20 capable ( should support labels)  routers ?=20

3. What is the meaning of "MPLS being negotiated, = but a=20 non-RSVP capable router stands in
   the path."=20

 Please throw some light on this,=20

Thanks in advance
 =20

Adithya=20
 

------=_NextPart_000_00D9_01C10E06.BAF474A0-- From owner-mpls@UU.NET Mon Jul 16 14:57: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 OAA16844 for ; Mon, 16 Jul 2001 14:57:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxyp07017; Mon, 16 Jul 2001 18:57:36 GMT Received: by mail-control.mail.uu.net id QQkxyp21136 for mpls-outgoing; Mon, 16 Jul 2001 18:56: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 QQkxyp21102 for ; Mon, 16 Jul 2001 18:56: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 QQkxyp13469 for ; Mon, 16 Jul 2001 18:50:37 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxyp27735 for ; Mon, 16 Jul 2001 18:50:37 GMT Message-ID: <3B53377B.A40E144A@sandburst.com> Date: Mon, 16 Jul 2001 14:50:35 -0400 From: Eric Gray MIME-Version: 1.0 To: George Thomas Cc: "mpls@uu.net" Subject: Re: doubt related to draft-ietf-mpls-cr-ldp-05.txt References: <20010716133547.7674.qmail@mailFA1.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George, If you look at the format for CR-LDP Label Request and Label Mapping messages, you will see that there are several TLVs that are optional. If you further compare these with the TLVs defined in CR-LDP and not in LDP, you will see that either of these standard messages formats can be a CR-LDP message if they contain any of these CR-LDP defined TLVs. Also, there are specific restrictions on the use of LDP specified behavior in CR-LDP - i.e. - only DoD label distribution and ordered control mode are used (further implying conservative label retention). Hence it might make sense to send a CR-LDP Label Request without an explicit route object. For certain, it does no harm to allow an implementation to do so, since such a message (in the simplest case) is the same as an LDP specified message. Since it does not add to the protocol complexity to allow omission of the TLV and there may be a reason to do so, then there is little point in making it mandatory. -- Eric Gray You wrote: > Hi, > > I just started reading the CR-LDP draft. > Its mentioned in the CR-LDP Label-request message > that the ER-TLV is optional. Without ER-Hops how explicit > tunnels will be established? Is should be a mandatory object right. Could you please tell me, in which scenario it can be an optional object. > > Thanks and Regards, > George > > ____________________________________________________ > http://www.monsterindia.com - The Best Jobs. For the Best Minds. From owner-mpls@UU.NET Mon Jul 16 15:57: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 SMTP id PAA28280 for ; Mon, 16 Jul 2001 15:57: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 QQkxyt08411; Mon, 16 Jul 2001 19:57:03 GMT Received: by mail-control.mail.uu.net id QQkxyt16128 for mpls-outgoing; Mon, 16 Jul 2001 19:56: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 QQkxyt16090 for ; Mon, 16 Jul 2001 19:55:55 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 QQkxyt26604 for ; Mon, 16 Jul 2001 19:55:08 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxyt16596 for ; Mon, 16 Jul 2001 19:55:08 GMT Message-ID: <3B53469A.F32763A9@sandburst.com> Date: Mon, 16 Jul 2001 15:55:06 -0400 From: Eric Gray MIME-Version: 1.0 To: Shahram Davari Cc: "'Ping Pan'" , "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D78@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, I was just talking to someone (off-line) about something that is obliquely related to this. Your suggestion will not work because the ping in the reverse direction traverses an equally long LSP with (presumably) an equal probability of a return path failure. Therefore, there is an issue with non-terminating recursion in LSP integrity checking. If you could reduce the length of the LSP by at least one hop in each successive recursion, the recursion would terminate. I think this is may be the under-lying advantage to the approach suggested earlier by Eric Rosen: if you send a ping response using UDP, the integrity 'recursion' is terminating as long as the UDP packet does not immediately (as in at the output port of the responder) get injected into an LSP. Even if the UDP packet is subsequently injected inbto an LSP that terminates at the original ping sender, this LSP is going to contain (at least one) fewer hops than the LSP being verified by the original ping - and this LSP's integrity is presumably testable by a similar means. Admittedly, there is the pathological case in which each return LSP is at least as long as the LSP being verified - but this seems like an extreme exception and brings the alleged integrity of the control plane into serious doubt as well. So, if you assume that each LSP integrity checking 'ping' response starts out as a plane old UDP message that might be injected subsequently into a 'shorter' LSP, the integrity checking recursion will terminate and the ultimate integrity of the original LSP can be verified. -- Eric Gray You wrote: > Ping, > > Thanks for your reply. I have a fundamental question: > > If all you are looking for is whether the reverse path is functional or not why not do the following: > > By running periodic ICMP pings over the reverse path, the ingress LSR could find whether the reverse path is functional or not. This can be done by the ingress LSR checking whether it is receiving reverse' path ICMP pings regularly that have source addresses equal to the destination address of the forwarding path ICMP Ping. And therefore can find whether a failed ICMP ping over the forwarding path is due to forwarding path failure or reverse path failure. > > What is wrong with this approach as compared to LSP-ping. > > -Shahram > > > -----Original Message----- > > From: Ping Pan [mailto:pingpan@juniper.net] > > Sent: Monday, July 16, 2001 12:23 PM > > To: Shahram Davari > > Cc: 'Yakov Rekhter'; 'mpls@uu.net' > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > Shahram Davari wrote: > > > > > > Hi Yakov, > > > > > > Good suggestion. However, I think due to periodic > > transmission of ping packets, and due > > > to possibility of many LSPs being pinged at the same time, > > the processing overhead of UDP/IP > > > is large and may limit the scalability. > > > > Shahram, > > > > That's why we choose a two-step ping: ICMP ping's followed by LSP > > ping's. Normally, the ingress sends the regular ICMP ping's to check > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping > > messages are > > sent to detect if the failure is on the forwarding or the reverse LSP. > > The reason for using UDP is to allow the egress LSR's to regulate the > > LSP-ping traffic.... Don't think there is a scalability problem here. > > > > > Using another reserved label for Ping > > > (or OAM packets in general) could eliminate the use of > > UDP/IP and could reduce the processing burden at > > > the egress LSR. > > > > > > > How? At egress, ping packets need to be processed anyway. You > > still have > > to somehow limit the amount of probing traffic. > > > > BTW, I will add the idea of using Explicit IPv4 NULL for > > non-IP traffic > > in the next version. > > > > - Ping > > From owner-mpls@UU.NET Mon Jul 16 16:00: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 QAA28728 for ; Mon, 16 Jul 2001 16:00: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 QQkxyt03649; Mon, 16 Jul 2001 19:59:29 GMT Received: by mail-control.mail.uu.net id QQkxyt16182 for mpls-outgoing; Mon, 16 Jul 2001 19:56:29 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 QQkxyt16170 for ; Mon, 16 Jul 2001 19:56: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 QQkxyt27482 for ; Mon, 16 Jul 2001 19:55:53 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 QQkxyt27604 for ; Mon, 16 Jul 2001 19:55:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA00261 for mpls@uu.net; Mon, 16 Jul 2001 15:55:53 -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 QQkxyt16008 for ; Mon, 16 Jul 2001 19:55: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 QQkxyt25011 for ; Mon, 16 Jul 2001 19:53:50 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkxyt24113 for ; Mon, 16 Jul 2001 19:53:50 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27570; Mon, 16 Jul 2001 15:52:55 -0400 (EDT) Message-Id: <200107161952.PAA27570@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: MPLS Support of Differentiated Services to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 16 Jul 2001 15:52:55 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider MPLS Support of Differentiated Services as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 30, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.txt From owner-mpls@UU.NET Mon Jul 16 16:18:00 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 QAA02016 for ; Mon, 16 Jul 2001 16:17: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 QQkxyv26209; Mon, 16 Jul 2001 20:18:15 GMT Received: by mail-control.mail.uu.net id QQkxyv08206 for mpls-outgoing; Mon, 16 Jul 2001 20:17: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 QQkxyv08193 for ; Mon, 16 Jul 2001 20:17: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 QQkxyv20481 for ; Mon, 16 Jul 2001 20:16:47 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 QQkxyv04828 for ; Mon, 16 Jul 2001 20:16:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA02124 for mpls@uu.net; Mon, 16 Jul 2001 16:16:46 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkxyv08032 for ; Mon, 16 Jul 2001 20:16:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkxyu24732 for ; Mon, 16 Jul 2001 20:14:15 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 QQkxyu09037 for ; Mon, 16 Jul 2001 20:14:15 GMT Received: (qmail 5094 invoked by uid 104); 16 Jul 2001 20:14:14 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.435578 secs); 16/07/2001 13:14:13 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 16 Jul 2001 20:14:13 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6GKEFP14491; Mon, 16 Jul 2001 13:14:16 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 13:19:45 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D79@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" Cc: "'Ping Pan'" , "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Mon, 16 Jul 2001 13:19:37 -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 Eric, > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Monday, July 16, 2001 3:55 PM > To: Shahram Davari > Cc: 'Ping Pan'; 'Yakov Rekhter'; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > I was just talking to someone (off-line) about something > that is obliquely related to this. > > Your suggestion will not work because the ping in the reverse > direction traverses an equally long LSP with (presumably) an > equal probability of a return path failure. But I don't care about return path failure of the reverse LSP, because in the method that I suggested, the ingress LSR checks to see whether it is receiving the ICMP (not ECHO) messages over the reverse LSP periodically, and if it is, it means that the reverse LSP is fine. Example: /---E----\ A----B----C \---D----/ Ingress LSR: A Egress LSR: C Forward LSP: ABC Reverse LSP: CDA Return of the reverse LSP: AEC 1)LSR A sends ICMP over ABC, and the ICMP Echo comes back through CDA 2)LSR B sends ICMP over CDA, and the ICMP Echo comes back through AEC 3)LSR A checks to see whether it is receiving any ICMP from C, regardless of the status of the return LSP of the reverse LSP (i.e. AEC) 4)If so Any failure to receive ICMP Echo from C for LSP=ABC is due to reverse path (CDA) failure. Yours, -Shahram Therefore, there is an > issue with non-terminating recursion in LSP integrity checking. > > If you could reduce the length of the LSP by at least one hop > in each successive recursion, the recursion would terminate. I > think this is may be the under-lying advantage to the approach > suggested earlier by Eric Rosen: if you send a ping response > using UDP, the integrity 'recursion' is terminating as long as > the UDP packet does not immediately (as in at the output port > of the responder) get injected into an LSP. Even if the UDP > packet is subsequently injected inbto an LSP that terminates > at the original ping sender, this LSP is going to contain (at least > one) fewer hops than the LSP being verified by the original ping > - and this LSP's integrity is presumably testable by a similar > means. > > Admittedly, there is the pathological case in which each return > LSP is at least as long as the LSP being verified - but this seems > like an extreme exception and brings the alleged integrity of the > control plane into serious doubt as well. So, if you assume that > each LSP integrity checking 'ping' response starts out as a plane > old UDP message that might be injected subsequently into a > 'shorter' LSP, the integrity checking recursion will terminate and > the ultimate integrity of the original LSP can be verified. > > -- > Eric Gray > > You wrote: > > > Ping, > > > > Thanks for your reply. I have a fundamental question: > > > > If all you are looking for is whether the reverse path is > functional or not why not do the following: > > > > By running periodic ICMP pings over the reverse path, the > ingress LSR could find whether the reverse path is functional > or not. This can be done by the ingress LSR checking whether > it is receiving reverse' path ICMP pings regularly that have > source addresses equal to the destination address of the > forwarding path ICMP Ping. And therefore can find whether a > failed ICMP ping over the forwarding path is due to > forwarding path failure or reverse path failure. > > > > What is wrong with this approach as compared to LSP-ping. > > > > -Shahram > > > > > -----Original Message----- > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > Sent: Monday, July 16, 2001 12:23 PM > > > To: Shahram Davari > > > Cc: 'Yakov Rekhter'; 'mpls@uu.net' > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > Shahram Davari wrote: > > > > > > > > Hi Yakov, > > > > > > > > Good suggestion. However, I think due to periodic > > > transmission of ping packets, and due > > > > to possibility of many LSPs being pinged at the same time, > > > the processing overhead of UDP/IP > > > > is large and may limit the scalability. > > > > > > Shahram, > > > > > > That's why we choose a two-step ping: ICMP ping's followed by LSP > > > ping's. Normally, the ingress sends the regular ICMP > ping's to check > > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping > > > messages are > > > sent to detect if the failure is on the forwarding or the > reverse LSP. > > > The reason for using UDP is to allow the egress LSR's to > regulate the > > > LSP-ping traffic.... Don't think there is a scalability > problem here. > > > > > > > Using another reserved label for Ping > > > > (or OAM packets in general) could eliminate the use of > > > UDP/IP and could reduce the processing burden at > > > > the egress LSR. > > > > > > > > > > How? At egress, ping packets need to be processed anyway. You > > > still have > > > to somehow limit the amount of probing traffic. > > > > > > BTW, I will add the idea of using Explicit IPv4 NULL for > > > non-IP traffic > > > in the next version. > > > > > > - Ping > > > > From owner-mpls@UU.NET Mon Jul 16 16:24: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 QAA03125 for ; Mon, 16 Jul 2001 16:24:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkxyv17969; Mon, 16 Jul 2001 20:24:23 GMT Received: by mail-control.mail.uu.net id QQkxyv08728 for mpls-outgoing; Mon, 16 Jul 2001 20:23: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 QQkxyv08706 for ; Mon, 16 Jul 2001 20:23: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 QQkxyv25515 for ; Mon, 16 Jul 2001 20:19:54 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkxyv15475 for ; Mon, 16 Jul 2001 20:19:53 GMT Message-ID: <3B534C68.879AF40@sandburst.com> Date: Mon, 16 Jul 2001 16:19:52 -0400 From: Eric Gray MIME-Version: 1.0 To: Shahram Davari Cc: "'Ping Pan'" , "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D79@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, It's one thing to use ping to check the integrity of a link, and quite another to use it as an 'alive' protocol. Isn't there a better approach than this? -- Eric Gray You wrote: > Hi Eric, > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@sandburst.com] > > Sent: Monday, July 16, 2001 3:55 PM > > To: Shahram Davari > > Cc: 'Ping Pan'; 'Yakov Rekhter'; 'mpls@uu.net' > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > Shahram, > > > > I was just talking to someone (off-line) about something > > that is obliquely related to this. > > > > Your suggestion will not work because the ping in the reverse > > direction traverses an equally long LSP with (presumably) an > > equal probability of a return path failure. > > But I don't care about return path failure of the reverse LSP, because > in the method that I suggested, the ingress LSR checks to see whether > it is receiving the ICMP (not ECHO) messages over the reverse LSP periodically, > and if it is, it means that the reverse LSP is fine. > > Example: > > /---E----\ > A----B----C > \---D----/ > > Ingress LSR: A > Egress LSR: C > Forward LSP: ABC > Reverse LSP: CDA > Return of the reverse LSP: AEC > > 1)LSR A sends ICMP over ABC, and the ICMP Echo comes back through CDA > 2)LSR B sends ICMP over CDA, and the ICMP Echo comes back through AEC > 3)LSR A checks to see whether it is receiving any ICMP from C, regardless > of the status of the return LSP of the reverse LSP (i.e. AEC) > 4)If so Any failure to receive ICMP Echo from C for LSP=ABC is due to > reverse path (CDA) failure. > > Yours, > -Shahram > > Therefore, there is an > > issue with non-terminating recursion in LSP integrity checking. > > > > If you could reduce the length of the LSP by at least one hop > > in each successive recursion, the recursion would terminate. I > > think this is may be the under-lying advantage to the approach > > suggested earlier by Eric Rosen: if you send a ping response > > using UDP, the integrity 'recursion' is terminating as long as > > the UDP packet does not immediately (as in at the output port > > of the responder) get injected into an LSP. Even if the UDP > > packet is subsequently injected inbto an LSP that terminates > > at the original ping sender, this LSP is going to contain (at least > > one) fewer hops than the LSP being verified by the original ping > > - and this LSP's integrity is presumably testable by a similar > > means. > > > > Admittedly, there is the pathological case in which each return > > LSP is at least as long as the LSP being verified - but this seems > > like an extreme exception and brings the alleged integrity of the > > control plane into serious doubt as well. So, if you assume that > > each LSP integrity checking 'ping' response starts out as a plane > > old UDP message that might be injected subsequently into a > > 'shorter' LSP, the integrity checking recursion will terminate and > > the ultimate integrity of the original LSP can be verified. > > > > -- > > Eric Gray > > > > You wrote: > > > > > Ping, > > > > > > Thanks for your reply. I have a fundamental question: > > > > > > If all you are looking for is whether the reverse path is > > functional or not why not do the following: > > > > > > By running periodic ICMP pings over the reverse path, the > > ingress LSR could find whether the reverse path is functional > > or not. This can be done by the ingress LSR checking whether > > it is receiving reverse' path ICMP pings regularly that have > > source addresses equal to the destination address of the > > forwarding path ICMP Ping. And therefore can find whether a > > failed ICMP ping over the forwarding path is due to > > forwarding path failure or reverse path failure. > > > > > > What is wrong with this approach as compared to LSP-ping. > > > > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > > Sent: Monday, July 16, 2001 12:23 PM > > > > To: Shahram Davari > > > > Cc: 'Yakov Rekhter'; 'mpls@uu.net' > > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > Hi Yakov, > > > > > > > > > > Good suggestion. However, I think due to periodic > > > > transmission of ping packets, and due > > > > > to possibility of many LSPs being pinged at the same time, > > > > the processing overhead of UDP/IP > > > > > is large and may limit the scalability. > > > > > > > > Shahram, > > > > > > > > That's why we choose a two-step ping: ICMP ping's followed by LSP > > > > ping's. Normally, the ingress sends the regular ICMP > > ping's to check > > > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping > > > > messages are > > > > sent to detect if the failure is on the forwarding or the > > reverse LSP. > > > > The reason for using UDP is to allow the egress LSR's to > > regulate the > > > > LSP-ping traffic.... Don't think there is a scalability > > problem here. > > > > > > > > > Using another reserved label for Ping > > > > > (or OAM packets in general) could eliminate the use of > > > > UDP/IP and could reduce the processing burden at > > > > > the egress LSR. > > > > > > > > > > > > > How? At egress, ping packets need to be processed anyway. You > > > > still have > > > > to somehow limit the amount of probing traffic. > > > > > > > > BTW, I will add the idea of using Explicit IPv4 NULL for > > > > non-IP traffic > > > > in the next version. > > > > > > > > - Ping > > > > > > From owner-mpls@UU.NET Mon Jul 16 16:57: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 QAA08447 for ; Mon, 16 Jul 2001 16:57: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 QQkxyx02321; Mon, 16 Jul 2001 20:57:10 GMT Received: by mail-control.mail.uu.net id QQkxyx11943 for mpls-outgoing; Mon, 16 Jul 2001 20:56: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 QQkxyx11938 for ; Mon, 16 Jul 2001 20:56: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 QQkxyx23889 for ; Mon, 16 Jul 2001 20:54:57 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 QQkxyx29261 for ; Mon, 16 Jul 2001 20:54:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA06474 for mpls@uu.net; Mon, 16 Jul 2001 16:54:57 -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 QQkxyx11577 for ; Mon, 16 Jul 2001 20:54: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 QQkxyx21857 for ; Mon, 16 Jul 2001 20:51:40 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 QQkxyx27307 for ; Mon, 16 Jul 2001 20:51:40 GMT Received: (qmail 29404 invoked by uid 104); 16 Jul 2001 20:51:39 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.488891 secs); 16/07/2001 13:51:38 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 16 Jul 2001 20:51:38 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6GKpeP05432; Mon, 16 Jul 2001 13:51:40 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 13:57:10 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7A@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" Cc: "'Ping Pan'" , "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Mon, 16 Jul 2001 13:57: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 Eric, > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Monday, July 16, 2001 4:20 PM > To: Shahram Davari > Cc: 'Ping Pan'; 'Yakov Rekhter'; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > It's one thing to use ping to check the integrity of a link, > and quite another to use it as an 'alive' protocol. Isn't there > a better approach than this? If by better approach you mean the refresh RESV messages, it may not be the a better approach. The LSP ping relies on the fact that if you are receiving refresh RESV messages, then the reverse RSVP path MUST be fine. Therefore if you send an LSP-ping and you don't receive the reply, the forwarding path must be down. So it is using refresh RESV message as "alive" protocol. This I argue is not the best choice, because: 1) Refresh frequency may not be good enough, specially when refresh reduction is used. So when you think that the RSVP reverse path is fine, it might in fact be down, because your information might not be up to date. 2) It can't be applied to LDP and CR-LDP and static configured LSPs. Yours, -Shahram > > -- > Eric Gray > > You wrote: > > > Hi Eric, > > > > > -----Original Message----- > > > From: Eric Gray [mailto:eric.gray@sandburst.com] > > > Sent: Monday, July 16, 2001 3:55 PM > > > To: Shahram Davari > > > Cc: 'Ping Pan'; 'Yakov Rekhter'; 'mpls@uu.net' > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > Shahram, > > > > > > I was just talking to someone (off-line) about something > > > that is obliquely related to this. > > > > > > Your suggestion will not work because the ping in the reverse > > > direction traverses an equally long LSP with (presumably) an > > > equal probability of a return path failure. > > > > But I don't care about return path failure of the reverse > LSP, because > > in the method that I suggested, the ingress LSR checks to > see whether > > it is receiving the ICMP (not ECHO) messages over the > reverse LSP periodically, > > and if it is, it means that the reverse LSP is fine. > > > > Example: > > > > /---E----\ > > A----B----C > > \---D----/ > > > > Ingress LSR: A > > Egress LSR: C > > Forward LSP: ABC > > Reverse LSP: CDA > > Return of the reverse LSP: AEC > > > > 1)LSR A sends ICMP over ABC, and the ICMP Echo comes back > through CDA > > 2)LSR B sends ICMP over CDA, and the ICMP Echo comes back > through AEC > > 3)LSR A checks to see whether it is receiving any ICMP from > C, regardless > > of the status of the return LSP of the reverse LSP (i.e. AEC) > > 4)If so Any failure to receive ICMP Echo from C for LSP=ABC > is due to > > reverse path (CDA) failure. > > > > Yours, > > -Shahram > > > > Therefore, there is an > > > issue with non-terminating recursion in LSP integrity checking. > > > > > > If you could reduce the length of the LSP by at least one hop > > > in each successive recursion, the recursion would terminate. I > > > think this is may be the under-lying advantage to the approach > > > suggested earlier by Eric Rosen: if you send a ping response > > > using UDP, the integrity 'recursion' is terminating as long as > > > the UDP packet does not immediately (as in at the output port > > > of the responder) get injected into an LSP. Even if the UDP > > > packet is subsequently injected inbto an LSP that terminates > > > at the original ping sender, this LSP is going to contain > (at least > > > one) fewer hops than the LSP being verified by the original ping > > > - and this LSP's integrity is presumably testable by a similar > > > means. > > > > > > Admittedly, there is the pathological case in which > each return > > > LSP is at least as long as the LSP being verified - but this seems > > > like an extreme exception and brings the alleged integrity of the > > > control plane into serious doubt as well. So, if you assume that > > > each LSP integrity checking 'ping' response starts out as a plane > > > old UDP message that might be injected subsequently into a > > > 'shorter' LSP, the integrity checking recursion will terminate and > > > the ultimate integrity of the original LSP can be verified. > > > > > > -- > > > Eric Gray > > > > > > You wrote: > > > > > > > Ping, > > > > > > > > Thanks for your reply. I have a fundamental question: > > > > > > > > If all you are looking for is whether the reverse path is > > > functional or not why not do the following: > > > > > > > > By running periodic ICMP pings over the reverse path, the > > > ingress LSR could find whether the reverse path is functional > > > or not. This can be done by the ingress LSR checking whether > > > it is receiving reverse' path ICMP pings regularly that have > > > source addresses equal to the destination address of the > > > forwarding path ICMP Ping. And therefore can find whether a > > > failed ICMP ping over the forwarding path is due to > > > forwarding path failure or reverse path failure. > > > > > > > > What is wrong with this approach as compared to LSP-ping. > > > > > > > > -Shahram > > > > > > > > > -----Original Message----- > > > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > > > Sent: Monday, July 16, 2001 12:23 PM > > > > > To: Shahram Davari > > > > > Cc: 'Yakov Rekhter'; 'mpls@uu.net' > > > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > Hi Yakov, > > > > > > > > > > > > Good suggestion. However, I think due to periodic > > > > > transmission of ping packets, and due > > > > > > to possibility of many LSPs being pinged at the same time, > > > > > the processing overhead of UDP/IP > > > > > > is large and may limit the scalability. > > > > > > > > > > Shahram, > > > > > > > > > > That's why we choose a two-step ping: ICMP ping's > followed by LSP > > > > > ping's. Normally, the ingress sends the regular ICMP > > > ping's to check > > > > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping > > > > > messages are > > > > > sent to detect if the failure is on the forwarding or the > > > reverse LSP. > > > > > The reason for using UDP is to allow the egress LSR's to > > > regulate the > > > > > LSP-ping traffic.... Don't think there is a scalability > > > problem here. > > > > > > > > > > > Using another reserved label for Ping > > > > > > (or OAM packets in general) could eliminate the use of > > > > > UDP/IP and could reduce the processing burden at > > > > > > the egress LSR. > > > > > > > > > > > > > > > > How? At egress, ping packets need to be processed anyway. You > > > > > still have > > > > > to somehow limit the amount of probing traffic. > > > > > > > > > > BTW, I will add the idea of using Explicit IPv4 NULL for > > > > > non-IP traffic > > > > > in the next version. > > > > > > > > > > - Ping > > > > > > > > > From owner-mpls@UU.NET Mon Jul 16 18:10:41 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 SAA20985 for ; Mon, 16 Jul 2001 18:10: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 QQkxzc18369; Mon, 16 Jul 2001 22:10:33 GMT Received: by mail-control.mail.uu.net id QQkxzc27913 for mpls-outgoing; Mon, 16 Jul 2001 22:09:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkxzc27899 for ; Mon, 16 Jul 2001 22:09: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 QQkxzc28177 for ; Mon, 16 Jul 2001 22:08:59 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 QQkxzc19965 for ; Mon, 16 Jul 2001 22:08:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA12391 for mpls@uu.net; Mon, 16 Jul 2001 18:08:58 -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 QQkxzc12086 for ; Mon, 16 Jul 2001 22:02: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 QQkxzc12993 for ; Mon, 16 Jul 2001 22:01:02 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkxzc24825 for ; Mon, 16 Jul 2001 22:01:01 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6GM0xH11994; Mon, 16 Jul 2001 15:00:59 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B536412.3184B71D@juniper.net> Date: Mon, 16 Jul 2001 15:00:50 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: Dave Cooper , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7A@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > If by better approach you mean the refresh RESV messages, it may not be the a better approach. > The LSP ping relies on the fact that if you are receiving refresh RESV messages, then the reverse > RSVP path MUST be fine. Therefore if you send an LSP-ping and you don't receive the reply, > the forwarding path must be down. > > So it is using refresh RESV message as "alive" protocol. This I argue is not the best choice, because: > > 1) Refresh frequency may not be good enough, specially when refresh reduction is used. So when you > think that the RSVP reverse path is fine, it might in fact be down, because your information might > not be up to date. Shahram, Not true. In the draft, it says: ... 6.3. Procedures for the intermediate LSR's At the LSR's that support LSP-ping, the Resv messages that carry the LSP_ECHO object must be delivered upstream immediately. At LSR's that use RSVP refresh reduction, a Resv message that carries an LSP_ECHO object should be considered as a trigger message, and should be processed according to the procedures defined in [RSVP- REFRESH]. ... Since a RESV message contains a new object, LSP_ECHO, the RESV is a trigger message, and must be forwarded immediately on the links that support refresh reduction. In fact, using exponential backoff timers and ack-extension defined in RFC2961, trigger messages can be delivered fast and reliably to the next hop. In other words, the LSP-ping replies go back to the headend LSR pretty fast. - Ping From owner-mpls@UU.NET Tue Jul 17 00:07:22 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 AAA19641 for ; Tue, 17 Jul 2001 00:07: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 QQkyaa01320; Tue, 17 Jul 2001 04:07:06 GMT Received: by mail-control.mail.uu.net id QQkyaa24562 for mpls-outgoing; Tue, 17 Jul 2001 04:06:39 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 QQkyaa24510 for ; Tue, 17 Jul 2001 04:06: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 QQkyaa26872 for ; Tue, 17 Jul 2001 04:05:10 GMT Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkyaa28974 for ; Tue, 17 Jul 2001 04:05:06 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6H40Mk30819; Tue, 17 Jul 2001 09:30:24 +0530 Message-ID: <3B53BA1E.2BD2458A@multitech.co.in> Date: Tue, 17 Jul 2001 09:37:58 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jiang, Donghua (Donghua)" CC: "'Madhu Babu Brahmanapally'" , "'mpls@uu.net'" Subject: Re: Some Doubts References: Content-Type: multipart/alternative; boundary="------------78B421BF44797B808CE5D2AA" Sender: owner-mpls@UU.NET Precedence: bulk --------------78B421BF44797B808CE5D2AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Madhubabu, Yes,with CR-LDP. Originally CR-LDP is meant for Label Distribution and has optional extensions for T.E Features which requires a resource management and allocator in conjunction. With RSVP we have a resource management..but it has been extended to help in the establishment of LSP tunnels.. Regards, Abhay "Jiang, Donghua (Donghua)" wrote: > Madhubabu,Not, unless you prefer CR-LDP.Regards,Jane D. Jiang > > -----Original Message----- > From: Madhu Babu Brahmanapally > [mailto:madhubabu@kenetec.com] > Sent: Monday, July 16, 2001 11:01 AM > To: adithya@sasken.com; mpls@UU.NET > Cc: 'Feng, Mark'; sridhar@samsung.co.kr > Subject: RE: Some Doubts > > HI All,Is it possible to have MPLS aware nodes but not aware > of RSVP-TE???RegardsMadhubabu > > -----Original Message----- > From: owner-mpls@UU.NET > [mailto:owner-mpls@UU.NET]On Behalf Of Adithya > Bhat > Sent: Monday, July 16, 2001 5:26 AM > To: mpls@UU.NET > Cc: Feng, Mark; sridhar@samsung.co.kr > Subject: Re: Some Doubts > > > > Thanks for the reply, > In the same draft Section 2.2 say:- > > "To create an LSP tunnel, the first MPLS node on > the path -- that is, > the sender node with respect to the path -- > creates an RSVP Path > message with a session type of LSP_TUNNEL_IPv4 > or LSP_TUNNEL_IPv6 and > inserts a LABEL_REQUEST object into the Path > message." > > If each node along the way must support > RSVT-TE/Label Request, Then what is the meaning of > "the first MPLS node on the path " in the above > sentence? > Does it not mean that some nodes along the path > are non mpls ?? > > Thanks, > > Adithya > > > > "Feng, Mark" wrote: > > > The intention is to establish a LSP from the > > ingress to the egress. I don't think it is > > appropriate for a transit node to terminate the > > request in such manner. For example, if the > > ingress receives the Resv, how does it know how > > far the LSP has been established?On the other > > hand, when the ingress node receives the > > PathErr, it knows what the problem is. It could > > decide to try the transit node as the egress > > node, though I don't know why it would want to > > do so.I guess you are right that in MPLS, each > > node along the way must support RSVT-TE/Label > > Request. If one of the nodes along the path > > cannot process the Label Request, that means the > > connection cannot be established end-to-end. As > > a result, we don't have a > > label-switched-path."MPLS being negotiated, but > > a non-RSVP capable router stands in the path." > > means just that, there is a non-RSVP capable > > router on the intended path.Hope this helps.Mark > > > > -----Original Message----- > > From: Adithya Bhat > > [mailto:adithya@sasken.com] > > Sent: Thursday, July 12, 2001 11:58 PM > > > > To: mpls@UU.NET > > Subject: Some Doubts > > Hi *, > > > > In > > draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > > Section 4.2.5 says > > > > "RSVP is designed to cope > > gracefully with non-RSVP routers > > anywhere > > between senders and receivers. > > However, obviously, non-RSVP routers > > cannot convey labels via RSVP. This > > means that if a router has a > > neighbor that is known to not be > > RSVP capable, the router MUST NOT > > advertise the LABEL_REQUEST object > > when sending messages that pass > > through the non-RSVP routers. The > > router SHOULD send a PathErr back > > to the sender, with the error code > > "Routing problem" and the error > > value "MPLS being negotiated, but a > > non-RSVP capable router stands in > > the path." > > > > 1. Why should a PathErr be sent back > > to the sender ? Will the current > > router not be a egress router, and > > hence should send a label binding > > back. > > > > 2. If the above is not true does it > > mean that all the routers (from the > > sender to the reciever ) should be > > rsvp-te capable ( should support > > labels) routers ? > > > > 3. What is the meaning of "MPLS being > > negotiated, but a non-RSVP capable > > router stands in > > the path." > > > > Please throw some light on this, > > > > Thanks in advance > > > > > > Adithya > > > > --------------78B421BF44797B808CE5D2AA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hello Madhubabu,
                Yes,with CR-LDP.
                Originally CR-LDP is meant for Label Distribution and has optional extensions
                for T.E Features which requires a resource management and allocator in conjunction.
                With RSVP we have a resource management..but it has been extended to help in the
                establishment of LSP tunnels..
                Regards,
                Abhay


"Jiang, Donghua (Donghua)" wrote:

 Madhubabu,Not, unless you prefer CR-LDP.Regards,Jane D. Jiang
-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Monday, July 16, 2001 11:01 AM
To: adithya@sasken.com; mpls@UU.NET
Cc: 'Feng, Mark'; sridhar@samsung.co.kr
Subject: RE: Some Doubts
 
HI All,Is it possible to have MPLS aware nodes but not aware of RSVP-TE???RegardsMadhubabu 
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat
Sent: Monday, July 16, 2001 5:26 AM
To: mpls@UU.NET
Cc: Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some Doubts
 


Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts
Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

--------------78B421BF44797B808CE5D2AA-- From owner-mpls@UU.NET Tue Jul 17 00: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 AAA20891 for ; Tue, 17 Jul 2001 00: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 QQkyab05547; Tue, 17 Jul 2001 04:18:54 GMT Received: by mail-control.mail.uu.net id QQkyab26035 for mpls-outgoing; Tue, 17 Jul 2001 04:18: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 QQkyab26023 for ; Tue, 17 Jul 2001 04:18: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 QQkyaa06831 for ; Tue, 17 Jul 2001 04:12:53 GMT Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkyaa08032 for ; Tue, 17 Jul 2001 04:12:47 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6H48Uk31239; Tue, 17 Jul 2001 09:38:30 +0530 Message-ID: <3B53BC09.8CA5ECB8@multitech.co.in> Date: Tue, 17 Jul 2001 09:46:09 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Madhu Babu Brahmanapally CC: "'Feng, Mark'" , mpls@UU.NET Subject: Re: Some Doubts References: <00d801c10e28$420614a0$c500a8c0@MBRAHMANAPALLY> Content-Type: multipart/alternative; boundary="------------3679130624075E3B525F546F" Sender: owner-mpls@UU.NET Precedence: bulk --------------3679130624075E3B525F546F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Madhu, IMHO ,CR-LDP has a lot of extensions and drafts. RSVP-TE too..but this is kind of more stable in terms of changes and extensions. In a perspective vendors generally prefer to play with RSVP rather than CR-LDP Although some have CR-LDP implemented and interoperated with other vendors.. Hope both stay and healthy competition gives rise to better working protocols.. Regards, Abhay Madhu Babu Brahmanapally wrote: > Hi Feng,All,When there are two possible solutions like CR-LDP and > RSVP-TE, there should be some IWF (might be in form of RFC ) between > these as IMO both are going to stay for ever.RegardsMadhubabu > > -----Original Message----- > From: Feng, Mark [mailto:m_feng@trillium.com] > Sent: Monday, July 16, 2001 2:34 PM > To: 'Madhu Babu Brahmanapally'; mpls@UU.NET > Subject: RE: Some Doubts > > The bottom line is that, the label request must be > understood and processed by each node along the LSP path. > You could have nodes along the way that are not RSVP-TE, > but the neighboring nodes has to do RSVP/LDP interworking. > As far as I know, there is no RFC/draft to address this. So, > it is not possible right now.Mark > > -----Original Message----- > From: Madhu Babu Brahmanapally > [mailto:madhubabu@kenetec.com] > Sent: Monday, July 16, 2001 11:01 AM > To: adithya@sasken.com; mpls@UU.NET > Cc: 'Feng, Mark'; sridhar@samsung.co.kr > Subject: RE: Some Doubts > > HI All,Is it possible to have MPLS aware nodes but > not aware of RSVP-TE???RegardsMadhubabu > > -----Original Message----- > From: owner-mpls@UU.NET > [mailto:owner-mpls@UU.NET]On Behalf Of > Adithya Bhat > Sent: Monday, July 16, 2001 5:26 AM > To: mpls@UU.NET > Cc: Feng, Mark; sridhar@samsung.co.kr > Subject: Re: Some Doubts > > > > Thanks for the reply, > In the same draft Section 2.2 say:- > > "To create an LSP tunnel, the first > MPLS node on the path -- that is, > the sender node with respect to the > path -- creates an RSVP Path > message with a session type of > LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and > inserts a LABEL_REQUEST object into > the Path message." > > If each node along the way must support > RSVT-TE/Label Request, Then what is the > meaning of "the first MPLS node on the > path " in the above sentence? > Does it not mean that some nodes along > the path are non mpls ?? > > Thanks, > > Adithya > > > > "Feng, Mark" wrote: > > > The intention is to establish a LSP > > from the ingress to the egress. I > > don't think it is appropriate for a > > transit node to terminate the request > > in such manner. For example, if the > > ingress receives the Resv, how does it > > know how far the LSP has been > > established?On the other hand, when > > the ingress node receives the PathErr, > > it knows what the problem is. It could > > decide to try the transit node as the > > egress node, though I don't know why > > it would want to do so.I guess you are > > right that in MPLS, each node along > > the way must support RSVT-TE/Label > > Request. If one of the nodes along the > > path cannot process the Label Request, > > that means the connection cannot be > > established end-to-end. As a result, > > we don't have a > > label-switched-path."MPLS being > > negotiated, but a non-RSVP capable > > router stands in the path." means > > just that, there is a non-RSVP capable > > router on the intended path.Hope this > > helps.Mark > > > > -----Original Message----- > > From: Adithya Bhat > > [mailto:adithya@sasken.com] > > Sent: Thursday, July 12, > > 2001 11:58 PM > > To: mpls@UU.NET > > Subject: Some Doubts > > Hi *, > > > > In > > draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > > Section 4.2.5 says > > > > "RSVP is designed to > > cope gracefully with > > non-RSVP routers anywhere > > between senders and > > receivers. However, > > obviously, non-RSVP routers > > cannot convey labels via > > RSVP. This means that if a > > router has a > > neighbor that is known to > > not be RSVP capable, the > > router MUST NOT > > advertise the > > LABEL_REQUEST object when > > sending messages that pass > > through the non-RSVP > > routers. The router SHOULD > > send a PathErr back > > to the sender, with the > > error code "Routing problem" > > and the error > > value "MPLS being > > negotiated, but a non-RSVP > > capable router stands in > > the path." > > > > 1. Why should a PathErr be > > sent back to the sender ? > > Will the current router not > > be a egress router, and > > hence should send a label > > binding back. > > > > 2. If the above is not true > > does it mean that all the > > routers (from the sender to > > the reciever ) should be > > rsvp-te capable ( should > > support labels) routers ? > > > > 3. What is the meaning of > > "MPLS being negotiated, but > > a non-RSVP capable router > > stands in > > the path." > > > > Please throw some light on > > this, > > > > Thanks in advance > > > > > > Adithya > > > > --------------3679130624075E3B525F546F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Madhu,
      IMHO ,CR-LDP has a lot of extensions and drafts.
      RSVP-TE too..but this is kind of more stable in terms of changes and extensions.
      In a perspective vendors generally prefer to play with RSVP rather than CR-LDP
      Although some have CR-LDP implemented and interoperated with other vendors..
      Hope both stay and healthy competition gives rise to better working protocols..
      Regards,
      Abhay
 


Madhu Babu Brahmanapally wrote:

 Hi Feng,All,When there are two possible solutions like CR-LDP and RSVP-TE, there should be some IWF (might be in form of RFC ) between these as IMO both are going to stay for ever.RegardsMadhubabu
-----Original Message-----
From: Feng, Mark [mailto:m_feng@trillium.com]
Sent: Monday, July 16, 2001 2:34 PM
To: 'Madhu Babu Brahmanapally'; mpls@UU.NET
Subject: RE: Some Doubts
 
The bottom line is that, the label request must be understood and processed by each node along the LSP path. You could have nodes along the way that are not RSVP-TE,  but the neighboring nodes has to do RSVP/LDP interworking. As far as I know, there is no RFC/draft to address this. So, it is not possible right now.Mark
-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Monday, July 16, 2001 11:01 AM
To: adithya@sasken.com; mpls@UU.NET
Cc: 'Feng, Mark'; sridhar@samsung.co.kr
Subject: RE: Some Doubts
 
HI All,Is it possible to have MPLS aware nodes but not aware of RSVP-TE???RegardsMadhubabu 
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat
Sent: Monday, July 16, 2001 5:26 AM
To: mpls@UU.NET
Cc: Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some Doubts
 


Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark
-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts
Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

        "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

1. Why should a PathErr be  sent back to the sender ? Will the current router not be a egress router, and hence should send a label binding back.

2.  If the above is not true does it mean that all the routers (from the sender  to the reciever ) should be  rsvp-te capable ( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

 Please throw some light on this,

Thanks in advance
 

Adithya
 

--------------3679130624075E3B525F546F-- From owner-mpls@UU.NET Tue Jul 17 01: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 SMTP id BAA13979 for ; Tue, 17 Jul 2001 01:44: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 QQkyag29780; Tue, 17 Jul 2001 05:44:36 GMT Received: by mail-control.mail.uu.net id QQkyag21890 for mpls-outgoing; Tue, 17 Jul 2001 05:44: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 QQkyag21885 for ; Tue, 17 Jul 2001 05:44:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkyag12150 for ; Tue, 17 Jul 2001 05:41:27 GMT Received: from samar.sasken.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkyag03628 for ; Tue, 17 Jul 2001 05:38:09 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f6H5Rig09318; Tue, 17 Jul 2001 10:57:44 +0530 (IST) Received: from sasken.com (pcka172.sasi.com [10.0.82.172]) by sunk3.sasi.com (8.9.3/8.9.3) with ESMTP id KAA05562; Tue, 17 Jul 2001 10:57:37 +0530 (IST) Message-ID: <3B53CCFD.7644B3A9@sasken.com> Date: Tue, 17 Jul 2001 10:58:29 +0530 From: Rajesh P Jain Organization: SASKEN Communication Technologies Ltd X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: abhay , Madhu Babu Brahmanapally , "'Feng, Mark'" Subject: Re: Some Doubts References: <00d801c10e28$420614a0$c500a8c0@MBRAHMANAPALLY> <3B53BC09.8CA5ECB8@multitech.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Hi", With respect to the discussion, I would like to ask the following question. In the diagram below, Let us consider that MPLS domain is from R3 to R7 Sender---R1---R2---R3---R4---R5---R6---R7---R8---Receiver In the routers R3 to R7, RSVP-TE is supported in the MPLS domain. In the routers R1,R2 and R8, RSVP is suppported but not MPLS. Now, The Sender sends a Path message towards the receiver along the path R1 to R8. Will the router R3 (the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message. - Section 2.2 - Operation od LSP tunnel in the Draft of RSVP extension for LSP tunnel) insert the LABEL Request Object???? Is it possible to establish the LSP tunnel in the MPLS domain (R3 to R7) or should all the nodes (i.e R1, R2 and R8 also) along the path from Sender to Receiver support MPLS ?? TIA Rajesh P Jain abhay wrote: > > > Madhu, > > IMHO ,CR-LDP has a lot of extensions and drafts. > > RSVP-TE too..but this is kind of more stable in terms of changes and extensions. > > In a perspective vendors generally prefer to play with RSVP rather than CR-LDP > > Although some have CR-LDP implemented and interoperated with other vendors.. > > Hope both stay and healthy competition gives rise to better working protocols.. > > Regards, > > Abhay > > > > > Madhu Babu Brahmanapally wrote: > >> Hi Feng,All,When there are two possible solutions like CR-LDP and >> RSVP-TE, there should be some IWF (might be in form of RFC ) between >> these as IMO both are going to stay for ever.RegardsMadhubabu >> >> -----Original Message----- >> From: Feng, Mark [mailto:m_feng@trillium.com] >> Sent: Monday, July 16, 2001 2:34 PM >> To: 'Madhu Babu Brahmanapally'; mpls@UU.NET >> Subject: RE: Some Doubts >> The bottom line is that, the label request must be >> understood and processed by each node along the LSP path. >> You could have nodes along the way that are not RSVP-TE, >> but the neighboring nodes has to do RSVP/LDP interworking. >> As far as I know, there is no RFC/draft to address this. >> So, it is not possible right now.Mark >> >> -----Original Message----- >> From: Madhu Babu Brahmanapally >> [mailto:madhubabu@kenetec.com] >> Sent: Monday, July 16, 2001 11:01 AM >> To: adithya@sasken.com; mpls@UU.NET >> Cc: 'Feng, Mark'; sridhar@samsung.co.kr >> Subject: RE: Some Doubts >> HI All,Is it possible to have MPLS aware nodes >> but not aware of RSVP-TE???RegardsMadhubabu >> >> -----Original Message----- >> From: owner-mpls@UU.NET >> [mailto:owner-mpls@UU.NET]On Behalf Of >> Adithya Bhat >> Sent: Monday, July 16, 2001 5:26 AM >> To: mpls@UU.NET >> Cc: Feng, Mark; sridhar@samsung.co.kr >> Subject: Re: Some Doubts >> >> >> Thanks for the reply, >> In the same draft Section 2.2 say:- >> >> "To create an LSP tunnel, the first >> MPLS node on the path -- that is, >> the sender node with respect to the >> path -- creates an RSVP Path >> message with a session type of >> LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and >> >> inserts a LABEL_REQUEST object into >> the Path message." >> >> If each node along the way must >> support RSVT-TE/Label Request, Then >> what is the meaning of "the first MPLS >> node on the path " in the above >> sentence? >> Does it not mean that some nodes >> along the path are non mpls ?? >> >> Thanks, >> >> Adithya >> >> >> >> "Feng, Mark" wrote: >> >> > The intention is to establish a LSP >> > from the ingress to the egress. I >> > don't think it is appropriate for a >> > transit node to terminate the request >> > in such manner. For example, if the >> > ingress receives the Resv, how does >> > it know how far the LSP has been >> > established?On the other hand, when >> > the ingress node receives the >> > PathErr, it knows what the problem >> > is. It could decide to try the >> > transit node as the egress node, >> > though I don't know why it would want >> > to do so.I guess you are right that >> > in MPLS, each node along the way must >> > support RSVT-TE/Label Request. If one >> > of the nodes along the path cannot >> > process the Label Request, that means >> > the connection cannot be established >> > end-to-end. As a result, we don't >> > have a label-switched-path."MPLS >> > being negotiated, but a non-RSVP >> > capable router stands in the path." >> > means just that, there is a non-RSVP >> > capable router on the intended >> > path.Hope this helps.Mark >> > >> > -----Original Message----- >> > From: Adithya Bhat >> > [mailto:adithya@sasken.com] >> > >> > Sent: Thursday, July 12, >> > 2001 11:58 PM >> > To: mpls@UU.NET >> > Subject: Some Doubts >> > Hi *, >> > >> > In >> > draft-ietf-mpls-rsvp-lsp-tunnel-08.txt >> > Section 4.2.5 says >> > >> > "RSVP is designed >> > to cope gracefully with >> > non-RSVP routers anywhere >> > between senders and >> > receivers. However, >> > obviously, non-RSVP routers >> > >> > cannot convey labels via >> > RSVP. This means that if a >> > router has a >> > neighbor that is known >> > to not be RSVP capable, the >> > router MUST NOT >> > advertise the >> > LABEL_REQUEST object when >> > sending messages that pass >> > through the non-RSVP >> > routers. The router SHOULD >> > send a PathErr back >> > to the sender, with the >> > error code "Routing >> > problem" and the error >> > value "MPLS being >> > negotiated, but a non-RSVP >> > capable router stands in >> > the path." >> > >> > 1. Why should a PathErr be >> > sent back to the sender ? >> > Will the current router not >> > be a egress router, and >> > hence should send a label >> > binding back. >> > >> > 2. If the above is not >> > true does it mean that all >> > the routers (from the >> > sender to the reciever ) >> > should be rsvp-te capable >> > ( should support labels) >> > routers ? >> > >> > 3. What is the meaning of >> > "MPLS being negotiated, but >> > a non-RSVP capable router >> > stands in >> > the path." >> > >> > Please throw some light on >> > this, >> > >> > Thanks in advance >> > >> > >> > Adithya >> > >> > From owner-mpls@UU.NET Tue Jul 17 04:02:05 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 EAA20898 for ; Tue, 17 Jul 2001 04:02:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyaq22010; Tue, 17 Jul 2001 08:01:11 GMT Received: by mail-control.mail.uu.net id QQkyaq15119 for mpls-outgoing; Tue, 17 Jul 2001 08:00: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 QQkyaq14644 for ; Tue, 17 Jul 2001 08:00:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkyap23688 for ; Tue, 17 Jul 2001 07:58:23 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 QQkyap25024 for ; Tue, 17 Jul 2001 07:58:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA08507 for mpls@uu.net; Tue, 17 Jul 2001 03:58:21 -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 QQkyap12398 for ; Tue, 17 Jul 2001 07:57: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 QQkyap13801 for ; Tue, 17 Jul 2001 07:57:20 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 QQkyap14951 for ; Tue, 17 Jul 2001 07:57:19 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 f6H8vXg05968 for ; Tue, 17 Jul 2001 10:57: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 f6H8vWh05961; Tue, 17 Jul 2001 10:57: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; Tue, 17 Jul 2001 10:58:49 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id <3ZBZ2FCG>; Tue, 17 Jul 2001 10:55:48 +0200 Message-ID: From: Sasha Vainshtein To: "'flefauch@cisco.com'" Cc: "'mpls@uu.net'" , Alik Shimelmits Subject: IESG Last Call for "MPLS Support of Differentiated Services" Date: Tue, 17 Jul 2001 10:55:46 +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 Francois, From my personal experience, I have found Applicability Statement (AS) documents accompanying most major MPLS standards most useful. So I would like to ask you, whether there is any intention to prepare an AS document for "MPLS Support of Differentiated Services"? The IESG last call message simply triggered this question. IMHO, one of valid issues to be considered in such a document would be the following scenario: Promotion of an IP-based Diffserv-enabled domain to MPLS. 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 Tue Jul 17 09:43: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 JAA06384 for ; Tue, 17 Jul 2001 09:43: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 QQkybm07163; Tue, 17 Jul 2001 13:42:45 GMT Received: by mail-control.mail.uu.net id QQkybm12341 for mpls-outgoing; Tue, 17 Jul 2001 13:42: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 QQkybm12328 for ; Tue, 17 Jul 2001 13:41: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 QQkybm01943 for ; Tue, 17 Jul 2001 13:40:41 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 QQkybm05102 for ; Tue, 17 Jul 2001 13:40:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA23285 for mpls@uu.net; Tue, 17 Jul 2001 09:40:40 -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 QQkybm12070 for ; Tue, 17 Jul 2001 13:39:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkybm26723 for ; Tue, 17 Jul 2001 13:36:53 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 QQkybm28150 for ; Tue, 17 Jul 2001 13:36:53 GMT Received: (qmail 29445 invoked by uid 104); 17 Jul 2001 13:36:52 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.408126 secs); 17/07/2001 06:36:52 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 13:36:52 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HDasP16245; Tue, 17 Jul 2001 06:36:54 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 06:42:26 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7B@BBY1EXM01> From: Shahram Davari To: "'Ping Pan'" Cc: Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 06:42:25 -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 Ping, > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Monday, July 16, 2001 6:01 PM > To: Shahram Davari > Cc: Dave Cooper; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram Davari wrote: > > > > If by better approach you mean the refresh RESV messages, > it may not be the a better approach. > > The LSP ping relies on the fact that if you are receiving > refresh RESV messages, then the reverse > > RSVP path MUST be fine. Therefore if you send an LSP-ping > and you don't receive the reply, > > the forwarding path must be down. > > > > So it is using refresh RESV message as "alive" protocol. > This I argue is not the best choice, because: > > > > 1) Refresh frequency may not be good enough, specially when > refresh reduction is used. So when you > > think that the RSVP reverse path is fine, it might in fact > be down, because your information might > > not be up to date. > > Shahram, > > Not true. In the draft, it says: > > ... > 6.3. Procedures for the intermediate LSR's > > At the LSR's that support LSP-ping, the Resv messages that > carry the > LSP_ECHO object must be delivered upstream immediately. > > At LSR's that use RSVP refresh reduction, a Resv message > that carries > an LSP_ECHO object should be considered as a trigger message, and > should be processed according to the procedures defined in [RSVP- > REFRESH]. > ... > I am talking about a different issue. Assume that at time "t" the RESV refresh (with interval "T") is received by the ingress LSR. Now assume that at time "t+x" in which t+x Since a RESV message contains a new object, LSP_ECHO, the RESV is a > trigger message, and must be forwarded immediately on the links that > support refresh reduction. In fact, using exponential backoff > timers and > ack-extension defined in RFC2961, trigger messages can be > delivered fast > and reliably to the next hop. In other words, the LSP-ping replies go > back to the headend LSR pretty fast. > > - Ping > From owner-mpls@UU.NET Tue Jul 17 09:45: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 JAA06542 for ; Tue, 17 Jul 2001 09:45: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 QQkybm03449; Tue, 17 Jul 2001 13:44:24 GMT Received: by mail-control.mail.uu.net id QQkybm12402 for mpls-outgoing; Tue, 17 Jul 2001 13:43: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 QQkybm12389 for ; Tue, 17 Jul 2001 13:43: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 QQkybm02428 for ; Tue, 17 Jul 2001 13:41:19 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 QQkybm05677 for ; Tue, 17 Jul 2001 13:41:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA23342 for mpls@uu.net; Tue, 17 Jul 2001 09:41:18 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkybm12131 for ; Tue, 17 Jul 2001 13:40:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkybm20548 for ; Tue, 17 Jul 2001 13:40:14 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 QQkybm04649 for ; Tue, 17 Jul 2001 13:40:13 GMT Received: (qmail 29815 invoked by uid 104); 17 Jul 2001 13:40:12 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.441075 secs); 17/07/2001 06:40:12 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 13:40:11 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HDeEP17478; Tue, 17 Jul 2001 06:40:14 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 06:45:46 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7C@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" Cc: "'Ping Pan'" , "'Yakov Rekhter'" , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 06:45:45 -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 Eric, > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Monday, July 16, 2001 4:20 PM > To: Shahram Davari > Cc: 'Ping Pan'; 'Yakov Rekhter'; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > It's one thing to use ping to check the integrity of a link, > and quite another to use it as an 'alive' protocol. Isn't there > a better approach than this? > It seems that this draft is suggesting the same thing; to use ICMP-ping as "alive" protocol! -Shahram > -- > Eric Gray > > You wrote: > > > Hi Eric, > > > > > -----Original Message----- > > > From: Eric Gray [mailto:eric.gray@sandburst.com] > > > Sent: Monday, July 16, 2001 3:55 PM > > > To: Shahram Davari > > > Cc: 'Ping Pan'; 'Yakov Rekhter'; 'mpls@uu.net' > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > Shahram, > > > > > > I was just talking to someone (off-line) about something > > > that is obliquely related to this. > > > > > > Your suggestion will not work because the ping in the reverse > > > direction traverses an equally long LSP with (presumably) an > > > equal probability of a return path failure. > > > > But I don't care about return path failure of the reverse > LSP, because > > in the method that I suggested, the ingress LSR checks to > see whether > > it is receiving the ICMP (not ECHO) messages over the > reverse LSP periodically, > > and if it is, it means that the reverse LSP is fine. > > > > Example: > > > > /---E----\ > > A----B----C > > \---D----/ > > > > Ingress LSR: A > > Egress LSR: C > > Forward LSP: ABC > > Reverse LSP: CDA > > Return of the reverse LSP: AEC > > > > 1)LSR A sends ICMP over ABC, and the ICMP Echo comes back > through CDA > > 2)LSR B sends ICMP over CDA, and the ICMP Echo comes back > through AEC > > 3)LSR A checks to see whether it is receiving any ICMP from > C, regardless > > of the status of the return LSP of the reverse LSP (i.e. AEC) > > 4)If so Any failure to receive ICMP Echo from C for LSP=ABC > is due to > > reverse path (CDA) failure. > > > > Yours, > > -Shahram > > > > Therefore, there is an > > > issue with non-terminating recursion in LSP integrity checking. > > > > > > If you could reduce the length of the LSP by at least one hop > > > in each successive recursion, the recursion would terminate. I > > > think this is may be the under-lying advantage to the approach > > > suggested earlier by Eric Rosen: if you send a ping response > > > using UDP, the integrity 'recursion' is terminating as long as > > > the UDP packet does not immediately (as in at the output port > > > of the responder) get injected into an LSP. Even if the UDP > > > packet is subsequently injected inbto an LSP that terminates > > > at the original ping sender, this LSP is going to contain > (at least > > > one) fewer hops than the LSP being verified by the original ping > > > - and this LSP's integrity is presumably testable by a similar > > > means. > > > > > > Admittedly, there is the pathological case in which > each return > > > LSP is at least as long as the LSP being verified - but this seems > > > like an extreme exception and brings the alleged integrity of the > > > control plane into serious doubt as well. So, if you assume that > > > each LSP integrity checking 'ping' response starts out as a plane > > > old UDP message that might be injected subsequently into a > > > 'shorter' LSP, the integrity checking recursion will terminate and > > > the ultimate integrity of the original LSP can be verified. > > > > > > -- > > > Eric Gray > > > > > > You wrote: > > > > > > > Ping, > > > > > > > > Thanks for your reply. I have a fundamental question: > > > > > > > > If all you are looking for is whether the reverse path is > > > functional or not why not do the following: > > > > > > > > By running periodic ICMP pings over the reverse path, the > > > ingress LSR could find whether the reverse path is functional > > > or not. This can be done by the ingress LSR checking whether > > > it is receiving reverse' path ICMP pings regularly that have > > > source addresses equal to the destination address of the > > > forwarding path ICMP Ping. And therefore can find whether a > > > failed ICMP ping over the forwarding path is due to > > > forwarding path failure or reverse path failure. > > > > > > > > What is wrong with this approach as compared to LSP-ping. > > > > > > > > -Shahram > > > > > > > > > -----Original Message----- > > > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > > > Sent: Monday, July 16, 2001 12:23 PM > > > > > To: Shahram Davari > > > > > Cc: 'Yakov Rekhter'; 'mpls@uu.net' > > > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > Hi Yakov, > > > > > > > > > > > > Good suggestion. However, I think due to periodic > > > > > transmission of ping packets, and due > > > > > > to possibility of many LSPs being pinged at the same time, > > > > > the processing overhead of UDP/IP > > > > > > is large and may limit the scalability. > > > > > > > > > > Shahram, > > > > > > > > > > That's why we choose a two-step ping: ICMP ping's > followed by LSP > > > > > ping's. Normally, the ingress sends the regular ICMP > > > ping's to check > > > > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping > > > > > messages are > > > > > sent to detect if the failure is on the forwarding or the > > > reverse LSP. > > > > > The reason for using UDP is to allow the egress LSR's to > > > regulate the > > > > > LSP-ping traffic.... Don't think there is a scalability > > > problem here. > > > > > > > > > > > Using another reserved label for Ping > > > > > > (or OAM packets in general) could eliminate the use of > > > > > UDP/IP and could reduce the processing burden at > > > > > > the egress LSR. > > > > > > > > > > > > > > > > How? At egress, ping packets need to be processed anyway. You > > > > > still have > > > > > to somehow limit the amount of probing traffic. > > > > > > > > > > BTW, I will add the idea of using Explicit IPv4 NULL for > > > > > non-IP traffic > > > > > in the next version. > > > > > > > > > > - Ping > > > > > > > > > From owner-mpls@UU.NET Tue Jul 17 10:00: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 KAA09818 for ; Tue, 17 Jul 2001 10:00: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 QQkybo24931; Tue, 17 Jul 2001 14:00:16 GMT Received: by mail-control.mail.uu.net id QQkybn14318 for mpls-outgoing; Tue, 17 Jul 2001 13:59: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 QQkybn14310 for ; Tue, 17 Jul 2001 13:59:47 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 QQkybn18465 for ; Tue, 17 Jul 2001 13:59:06 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkybn25468 for ; Tue, 17 Jul 2001 13:59:05 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HDwxH43467; Tue, 17 Jul 2001 06:58:59 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200107171358.f6HDwxH43467@merlot.juniper.net> To: Shahram Davari cc: Dave Cooper , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt In-Reply-To: Your message of "Tue, 17 Jul 2001 06:42:25 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7B@BBY1EXM01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82464.995378339.1@juniper.net> Date: Tue, 17 Jul 2001 06:58:59 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Shahram, > > > If by better approach you mean the refresh RESV messages, > > > it may not be the a better approach. > > > The LSP ping relies on the fact that if you are receiving > > > refresh RESV messages, then the reverse > > > RSVP path MUST be fine. Therefore if you send an LSP-ping > > > and you don't receive the reply, the forwarding path must be down. > > > > > > So it is using refresh RESV message as "alive" protocol. > > > This I argue is not the best choice, because: > > > > > > 1) Refresh frequency may not be good enough, specially when > > > refresh reduction is used. So when you > > > think that the RSVP reverse path is fine, it might in fact > > > be down, because your information might > > > not be up to date. > > > > Shahram, > > > > Not true. In the draft, it says: > > > > ... > > 6.3. Procedures for the intermediate LSR's > > > > At the LSR's that support LSP-ping, the Resv messages that > > carry the LSP_ECHO object must be delivered upstream immediately. > > > > At LSR's that use RSVP refresh reduction, a Resv message that carries > > an LSP_ECHO object should be considered as a trigger message, and > > should be processed according to the procedures defined in [RSVP- > > REFRESH]. > > ... > > I am talking about a different issue. Assume that at time "t" the > RESV refresh (with interval "T") is received by the ingress LSR. > Now assume that at time "t+x" in which t+x LSP and the RESV path fail (this can happen for example if both > the RESV message and the reverse LSP are transmitted from the same > line-card in the egress LSR and that line-card fails). The information > that you have at time t+x is that there is a failure, but the RESV > path is fine. So you start sending LSP-ping and you don't receive > any LSP-ECHO, therefore you reach to a false conclusion that the > forward LSP is down. If you don't receive any LSP-ECHO then you may conclude that either the forward LSP is down, or the control channel used by RSVP (or to be more precise by RESV) to set up the LSP is down. Yakov. From owner-mpls@UU.NET Tue Jul 17 10:03:22 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 KAA10535 for ; Tue, 17 Jul 2001 10:03: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 QQkybo29719; Tue, 17 Jul 2001 14:02:26 GMT Received: by mail-control.mail.uu.net id QQkybo21385 for mpls-outgoing; Tue, 17 Jul 2001 14:01: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 QQkybo20096 for ; Tue, 17 Jul 2001 14:01:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkybo28321 for ; Tue, 17 Jul 2001 14:00:07 GMT Received: from mailFA6.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.151]) id QQkybo24687 for ; Tue, 17 Jul 2001 14:00:05 GMT Received: (qmail 18777 invoked by uid 510); 17 Jul 2001 14:06:59 -0000 Date: 17 Jul 2001 14:06:59 -0000 Message-ID: <20010717140659.18776.qmail@mailFA6.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 17 Jul 2001 14:06:59 -0000 MIME-Version: 1.0 To: "mpls@UU.NET" Subject: Re: Re: doubt related to draft-ietf-mpls-cr-ldp-05.txt From: "George Thomas" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks all, for clarifying my doubt. Let me put my understanding this way. CR-LDP label request message can contain the FEC TLV with the valid Prefix (as the Egress ID as Mohan mentioned in his reply) and then it can use other optional TLVs like Priorities, Traffic Parm TLV, and other stuff with out ER-TLV. Please Let me know if I am wrong. Regards, George ------------- Original Message -------------- Eric Gray wrote: To:George Thomas From:Eric Gray Date:Mon, 16 Jul 2001 14:50:35 -0400 CC:"mpls@uu.net" Subject:Re: doubt related to draft-ietf-mpls-cr-ldp-05.txt George, If you look at the format for CR-LDP Label Request and Label Mapping messages, you will see that there are several TLVs that are optional. If you further compare these with the TLVs defined in CR-LDP and not in LDP, you will see that either of these standard messages formats can be a CR-LDP message if they contain any of these CR-LDP defined TLVs. Also, there are specific restrictions on the use of LDP specified behavior in CR-LDP - i.e. - only DoD label distribution and ordered control mode are used (further implying conservative label retention). Hence it might make sense to send a CR-LDP Label Request without an explicit route object. For certain, it does no harm to allow an implementation to do so, since such a message (in the simplest case) is the same as an LDP specified message. Since it does not add to the protocol complexity to allow omission of the TLV and there may be a reason to do so, then there is little point in making it mandatory. -- Eric Gray You wrote: > Hi, > > I just started reading the CR-LDP draft. > Its mentioned in the CR-LDP Label-request message > that the ER-TLV is optional. Without ER-Hops how explicit > tunnels will be established? Is should be a mandatory object right. Could you please tell me, in which scenario it can be an optional object. > > Thanks and Regards, > George > > ____________________________________________________ > http://www.monsterindia.com - The Best Jobs. For the Best Minds. ____________________________________________________ http://www.monsterindia.com - The Best Jobs. For the Best Minds. From owner-mpls@UU.NET Tue Jul 17 10:38:01 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 KAA18701 for ; Tue, 17 Jul 2001 10:38: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 QQkybq25746; Tue, 17 Jul 2001 14:36:57 GMT Received: by mail-control.mail.uu.net id QQkybq07411 for mpls-outgoing; Tue, 17 Jul 2001 14:36: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 QQkybq07387 for ; Tue, 17 Jul 2001 14:36:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkybq29484 for ; Tue, 17 Jul 2001 14:32:48 GMT Received: from almso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQkybq07957 for ; Tue, 17 Jul 2001 14:32:48 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f6HEWjp24619; Tue, 17 Jul 2001 10:32:46 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA00641; Tue, 17 Jul 2001 10:31:26 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id <36SHNT15>; Tue, 17 Jul 2001 10:32:45 -0400 Message-ID: <1B08859602C8D211B66F0000C0769CFA03A95A84@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALCTA" To: "'te-wg@ops.ietf.org'" , "'mpls@uu.net'" Cc: "Ash, Gerald R (Jerry), ALCTA" , "Lai, Wai S (Waisum), ALSVC" , "Fang, Luyuan, ALSVC" Subject: FW: I-D ACTION:draft-ash-mpls-diffserv-te-alternative-00.txt Date: Tue, 17 Jul 2001 10:32:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10ECD.54879220" 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_01C10ECD.54879220 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 17, 2001 6:50 AM To: IETF-Announce; @wsscan.att.com Subject: I-D ACTION:draft-ash-mpls-diffserv-te-alternative-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Alternative Technical Solution for MPLS DiffServ TE Author(s) : J. Ash et al. Filename : draft-ash-mpls-diffserv-te-alternative-00.txt Pages : 10 Date : 16-Jul-01 Service Provider requirements for support of DiffServ-aware MPLS Traffic Engineering (DS-TE) are presented in [DS-TE-REQ]. [DS-TE- SOLN] describes a proposed technical solution for meeting the DS-TE requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-alternative-0 0.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-mpls-diffserv-te-alternative-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-mpls-diffserv-te-alternative-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C10ECD.54879220 Content-Type: message/rfc822 To: Subject: Date: Tue, 17 Jul 2001 10:32:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C10ECD.54879220" ------_=_NextPart_002_01C10ECD.54879220 Content-Type: text/plain ------_=_NextPart_002_01C10ECD.54879220 Content-Type: application/octet-stream; name="ATT31049" Content-Disposition: attachment; filename="ATT31049" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010716153144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-mpls-diffserv-te-alternative-00.txt ------_=_NextPart_002_01C10ECD.54879220 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ash-mpls-diffserv-te-alternative-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C10ECD.54879220-- ------_=_NextPart_000_01C10ECD.54879220-- From owner-mpls@UU.NET Tue Jul 17 10:57: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 KAA23404 for ; Tue, 17 Jul 2001 10:57:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkybr26797; Tue, 17 Jul 2001 14:56:07 GMT Received: by mail-control.mail.uu.net id QQkybr09186 for mpls-outgoing; Tue, 17 Jul 2001 14:55: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 QQkybr09152 for ; Tue, 17 Jul 2001 14:55:24 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 QQkybr06770 for ; Tue, 17 Jul 2001 14:53:58 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 QQkybr04548 for ; Tue, 17 Jul 2001 14:53:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA01413 for mpls@uu.net; Tue, 17 Jul 2001 10:53:57 -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 QQkybr09010 for ; Tue, 17 Jul 2001 14:53:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkybr04801 for ; Tue, 17 Jul 2001 14:47:15 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 QQkybr26155 for ; Tue, 17 Jul 2001 14:47:14 GMT Received: (qmail 18563 invoked by uid 104); 17 Jul 2001 14:47:14 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.416938 secs); 17/07/2001 07:47:13 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 14:47:13 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HElGP27593; Tue, 17 Jul 2001 07:47:16 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 07:52:47 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7D@BBY1EXM01> From: Shahram Davari To: "'Yakov Rekhter'" Cc: Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 07:52:47 -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 Yakov, > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Tuesday, July 17, 2001 9:59 AM > To: Shahram Davari > Cc: Dave Cooper; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > > > > If by better approach you mean the refresh RESV messages, > > > > it may not be the a better approach. > > > > The LSP ping relies on the fact that if you are receiving > > > > refresh RESV messages, then the reverse > > > > RSVP path MUST be fine. Therefore if you send an LSP-ping > > > > and you don't receive the reply, the forwarding path > must be down. > > > > > > > > So it is using refresh RESV message as "alive" protocol. > > > > This I argue is not the best choice, because: > > > > > > > > 1) Refresh frequency may not be good enough, specially when > > > > refresh reduction is used. So when you > > > > think that the RSVP reverse path is fine, it might in fact > > > > be down, because your information might > > > > not be up to date. > > > > > > Shahram, > > > > > > Not true. In the draft, it says: > > > > > > ... > > > 6.3. Procedures for the intermediate LSR's > > > > > > At the LSR's that support LSP-ping, the Resv messages that > > > carry the LSP_ECHO object must be delivered upstream > immediately. > > > > > > At LSR's that use RSVP refresh reduction, a Resv > message that carries > > > an LSP_ECHO object should be considered as a trigger > message, and > > > should be processed according to the procedures > defined in [RSVP- > > > REFRESH]. > > > ... > > > > I am talking about a different issue. Assume that at time "t" the > > RESV refresh (with interval "T") is received by the ingress LSR. > > Now assume that at time "t+x" in which t+x > LSP and the RESV path fail (this can happen for example if both > > the RESV message and the reverse LSP are transmitted from the same > > line-card in the egress LSR and that line-card fails). The > information > > that you have at time t+x is that there is a failure, but the RESV > > path is fine. So you start sending LSP-ping and you don't receive > > any LSP-ECHO, therefore you reach to a false conclusion that the > > forward LSP is down. > > If you don't receive any LSP-ECHO then you may conclude that either > the forward LSP is down, or the control channel used by RSVP > (or to be more precise by RESV) to set up the LSP is down. > Which is a useless information, because the whole point of the LSP-ping was to find whether the fault is in forward LSP or not ! -Shahram > Yakov. > From owner-mpls@UU.NET Tue Jul 17 11:12: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 LAA26881 for ; Tue, 17 Jul 2001 11:12: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 QQkybs27418; Tue, 17 Jul 2001 15:11:54 GMT Received: by mail-control.mail.uu.net id QQkybs00125 for mpls-outgoing; Tue, 17 Jul 2001 15:11:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkybs00094 for ; Tue, 17 Jul 2001 15:11:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkybs02829 for ; Tue, 17 Jul 2001 15:07:40 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 QQkybs21767 for ; Tue, 17 Jul 2001 15:07:39 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA03477 for mpls@uu.net; Tue, 17 Jul 2001 11:07:39 -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 QQkybs22229 for ; Tue, 17 Jul 2001 15:06: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 QQkybs29357 for ; Tue, 17 Jul 2001 15:06:01 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 QQkybs13822 for ; Tue, 17 Jul 2001 15:06:00 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6HF5xv07161; Tue, 17 Jul 2001 08:05:59 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4137.cisco.com [10.50.16.40]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ABA00464 (AUTH rraszuk); Tue, 17 Jul 2001 08:05:56 -0700 (PDT) Message-ID: <3B5453D8.FAEB7F8F@cisco.com> Date: Tue, 17 Jul 2001 08:03:52 -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: Shahram Davari CC: "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7D@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, > > If you don't receive any LSP-ECHO then you may conclude that either > > the forward LSP is down, or the control channel used by RSVP > > (or to be more precise by RESV) to set up the LSP is down. > > > > Which is a useless information, because the whole point of the LSP-ping was to > find whether the fault is in forward LSP or not ! Notice what the draft says: In the case where an LSP has failed to deliver user traffic, and the failure cannot be easily detected by the MPLS control plane (and specifically, RSVP-TE component), So we do assume that the RSVP-TE control plane is up and running fine otherwise there would be no point of even sending icmp msg over failed LSP. Having this in mind not receiving of LSP_ECHO in RSVP RESV msg IMHO clearly identifies the failure of forward LSP under test. R. From owner-mpls@UU.NET Tue Jul 17 11:45: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 LAA04265 for ; Tue, 17 Jul 2001 11:45: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 QQkybu09311; Tue, 17 Jul 2001 15:42:48 GMT Received: by mail-control.mail.uu.net id QQkybu02996 for mpls-outgoing; Tue, 17 Jul 2001 15:42: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 QQkybu02988 for ; Tue, 17 Jul 2001 15:42: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 QQkybu01827 for ; Tue, 17 Jul 2001 15:40:41 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 QQkybu10731 for ; Tue, 17 Jul 2001 15:40:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA06512 for mpls@uu.net; Tue, 17 Jul 2001 11:40:40 -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 QQkybu02771 for ; Tue, 17 Jul 2001 15:39: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 QQkybu27278 for ; Tue, 17 Jul 2001 15:38:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkybu02791 for ; Tue, 17 Jul 2001 15:38:08 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 LAA28177; Tue, 17 Jul 2001 11:38:07 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225]) by bucket.cisco.com (Mirapoint) with ESMTP id ADO01475; Tue, 17 Jul 2001 11:38:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20010717113650.02cbb2e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jul 2001 11:42:54 -0400 To: raszuk@cisco.com, Shahram Davari From: "Thomas D. Nadeau" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt Cc: "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" In-Reply-To: <3B5453D8.FAEB7F8F@cisco.com> References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7D@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:03 AM 7/17/2001 -0700, Robert Raszuk wrote: >Shahram, > > > > If you don't receive any LSP-ECHO then you may conclude that either > > > the forward LSP is down, or the control channel used by RSVP > > > (or to be more precise by RESV) to set up the LSP is down. > > > > > > > Which is a useless information, because the whole point of the LSP-ping > was to > > find whether the fault is in forward LSP or not ! > >Notice what the draft says: > > In the case where an LSP has failed to deliver user traffic, and the > failure cannot be easily detected by the MPLS control plane (and > specifically, RSVP-TE component), > >So we do assume that the RSVP-TE control plane is up and running fine >otherwise there would be no point of even sending icmp msg over failed >LSP. Having this in mind not receiving of LSP_ECHO in RSVP RESV msg IMHO >clearly identifies the failure of forward LSP under test. Just to clarify the assumption made above. If the control plane is down, you should be notified pretty quickly that this is the case by one of the signaling protocols. --Tom From owner-mpls@UU.NET Tue Jul 17 11:50: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 SMTP id LAA05721 for ; Tue, 17 Jul 2001 11:50:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkybv26039; Tue, 17 Jul 2001 15:49:20 GMT Received: by mail-control.mail.uu.net id QQkybv03834 for mpls-outgoing; Tue, 17 Jul 2001 15:48:06 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 QQkybv03814 for ; Tue, 17 Jul 2001 15:47: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 QQkybu04277 for ; Tue, 17 Jul 2001 15:43:41 GMT Received: from smtp015.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp015.mail.yahoo.com [216.136.173.59]) id QQkybu15768 for ; Tue, 17 Jul 2001 15:43:41 GMT Received: from 63-217-58-117.sdsl.cais.net (HELO mansari) (63.217.58.117) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jul 2001 15:43:40 -0000 X-Apparently-From: Message-ID: <006a01c10ed7$40765960$753ad93f@gemplex.com> Reply-To: "AM Shaikh" From: "AM Shaikh" To: Subject: RFC2547 - Multi-Party Security Associations Date: Tue, 17 Jul 2001 11:43:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C10EB5.B8935FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C10EB5.B8935FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pls suggest me of a product implementing "Multi-Party Security = Associations" as described in RFC2547 section 9.2 or the way to = implement it with cisco routers Thanx Majid ------=_NextPart_000_0067_01C10EB5.B8935FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Pls suggest me of a product=20 implementing "Multi-Party Security = Associations" as=20 described in RFC2547 section 9.2 or the way to implement it with cisco=20 routers
 
Thanx
Majid
------=_NextPart_000_0067_01C10EB5.B8935FA0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-mpls@UU.NET Tue Jul 17 11:51: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 LAA05949 for ; Tue, 17 Jul 2001 11:51: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 QQkybv29163; Tue, 17 Jul 2001 15:50:49 GMT Received: by mail-control.mail.uu.net id QQkybv03855 for mpls-outgoing; Tue, 17 Jul 2001 15:48: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 QQkybv03815 for ; Tue, 17 Jul 2001 15:47: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 QQkybu03272 for ; Tue, 17 Jul 2001 15:42:35 GMT Received: from smtp016.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp016.mail.yahoo.com [216.136.174.113]) id QQkybu26583 for ; Tue, 17 Jul 2001 15:42:35 GMT Received: from 63-217-58-117.sdsl.cais.net (HELO mansari) (63.217.58.117) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jul 2001 15:42:34 -0000 X-Apparently-From: Message-ID: <005b01c10ed7$19096c50$753ad93f@gemplex.com> Reply-To: "AM Shaikh" From: "AM Shaikh" To: Subject: GRE Tunnel interfaces in MPLS VRF Date: Tue, 17 Jul 2001 11:42:32 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C10EB5.90A7A5A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C10EB5.90A7A5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Can anyone point me to details on how GRE tunnels are carried in MPLS = network ... is GRE header removed before the packet enters MPLS LSP ... = or packet is carried with GRE Tunnel .... Thanx AM ------=_NextPart_000_0058_01C10EB5.90A7A5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Can anyone point me to details on = how GRE=20 tunnels are carried in MPLS network ... is GRE header removed before the = packet=20 enters MPLS LSP ... or packet is carried with GRE Tunnel = ....
 
Thanx
AM
------=_NextPart_000_0058_01C10EB5.90A7A5A0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-mpls@UU.NET Tue Jul 17 11:55:30 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 LAA06909 for ; Tue, 17 Jul 2001 11:55:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkybv22815; Tue, 17 Jul 2001 15:52:27 GMT Received: by mail-control.mail.uu.net id QQkybv03885 for mpls-outgoing; Tue, 17 Jul 2001 15:48: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 QQkybv03839 for ; Tue, 17 Jul 2001 15:48:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkybv10949 for ; Tue, 17 Jul 2001 15:45:21 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 QQkybv18666 for ; Tue, 17 Jul 2001 15:45:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA06962 for mpls@uu.net; Tue, 17 Jul 2001 11:45: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 QQkybu02319 for ; Tue, 17 Jul 2001 15:33: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 QQkybu21309 for ; Tue, 17 Jul 2001 15:30:48 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 QQkybu22711 for ; Tue, 17 Jul 2001 15:30:48 GMT Received: (qmail 29543 invoked by uid 104); 17 Jul 2001 15:30: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.805216 secs); 17/07/2001 08:30:46 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 15:30:46 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HFUnP24375; Tue, 17 Jul 2001 08:30:49 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 08:36:21 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7E@BBY1EXM01> From: Shahram Davari To: "'raszuk@cisco.com'" Cc: "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 08:36:20 -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, > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Tuesday, July 17, 2001 11:04 AM > To: Shahram Davari > Cc: 'Yakov Rekhter'; Dave Cooper; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > > > If you don't receive any LSP-ECHO then you may conclude > that either > > > the forward LSP is down, or the control channel used by RSVP > > > (or to be more precise by RESV) to set up the LSP is down. > > > > > > > Which is a useless information, because the whole point of > the LSP-ping was to > > find whether the fault is in forward LSP or not ! > > Notice what the draft says: > > In the case where an LSP has failed to deliver user > traffic, and the > failure cannot be easily detected by the MPLS control plane (and > specifically, RSVP-TE component), > > So we do assume that the RSVP-TE control plane is up and running fine > otherwise there would be no point of even sending icmp msg over failed > LSP. So let me see if I understand this correctly. What you are trying to say is that first we select an LSP for connectivity test. Then we check to see that we are receiving the RESV messages with refresh interval "T". Then we run ICMP-ping messages until we don't receive ICMP-Echo back. At this time we wait for a period of "T" to see whether we receive another RESV message or not. If we don't, this means that the RESV path is down, otherwise the RESV path is fine and we can now run LSP-ping. And if we don't receive LSP-Echo back, this means that the forward LSP is down. Right? If this is correct then you probably have noticed the delay time "T" between detecting a failure and isolating it to the forward LSP. My point was that this time interval may be large specially when refresh reduction is used. -Shahram Having this in mind not receiving of LSP_ECHO in RSVP > RESV msg IMHO > clearly identifies the failure of forward LSP under test. > > R. > From owner-mpls@UU.NET Tue Jul 17 12:07: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 MAA09437 for ; Tue, 17 Jul 2001 12:07: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 QQkybw19596; Tue, 17 Jul 2001 16:06:53 GMT Received: by mail-control.mail.uu.net id QQkybw18752 for mpls-outgoing; Tue, 17 Jul 2001 16:06: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 QQkybw18369 for ; Tue, 17 Jul 2001 16:06: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 QQkybw26625 for ; Tue, 17 Jul 2001 16:04:18 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 QQkybw17267 for ; Tue, 17 Jul 2001 16:04:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA10670 for mpls@uu.net; Tue, 17 Jul 2001 12:04:17 -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 QQkybw11407 for ; Tue, 17 Jul 2001 16:03:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkybv07653 for ; Tue, 17 Jul 2001 15:59:17 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkybv02439 for ; Tue, 17 Jul 2001 15:59:16 GMT Received: from juniper.net ([172.16.167.234]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HFxEH46538; Tue, 17 Jul 2001 08:59:14 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B54623E.53399A2D@juniper.net> Date: Tue, 17 Jul 2001 09:05:18 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: Dave Cooper , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7B@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > > I am talking about a different issue. Assume that at time "t" the RESV > refresh (with interval "T") is received by the ingress LSR. Now assume > that at time "t+x" in which t+x path fail (this can happen for example if both the RESV message and the > reverse LSP are transmitted from the same line-card in the egress LSR > and that line-card fails). The information that you have at time t+x is that there is > a failure, but the RESV path is fine. So you start sending LSP-ping and > you don't receive any LSP-ECHO, therefore you reach to a false conclusion > that the forward LSP is down. > Shahram, First, if RSVP-TE detects a failure inside the network, it must send error messages to notify the ingress LSR's. Second, we only determine the forwarding LSP is down if the ingress does not receive the echo-replies via RESV. In your example, if the failure takes place at t+x, the ingress would either know it via PathErr, or by the fact that no replies from the egress AFTER t+x. LSP-ping works fine here. - Ping From owner-mpls@UU.NET Tue Jul 17 12:21: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 MAA13044 for ; Tue, 17 Jul 2001 12: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 QQkybx20945; Tue, 17 Jul 2001 16:19:19 GMT Received: by mail-control.mail.uu.net id QQkybx28155 for mpls-outgoing; Tue, 17 Jul 2001 16:18: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 QQkybx28130 for ; Tue, 17 Jul 2001 16:18:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkybx00195 for ; Tue, 17 Jul 2001 16:15:13 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 QQkybx28204 for ; Tue, 17 Jul 2001 16:15:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA11797 for mpls@uu.net; Tue, 17 Jul 2001 12:15:12 -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 QQkybv04984 for ; Tue, 17 Jul 2001 15:59: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 QQkybv17068 for ; Tue, 17 Jul 2001 15:55:38 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkybv09540 for ; Tue, 17 Jul 2001 15:55:37 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6HFrXH22678; Tue, 17 Jul 2001 08:55:36 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4137.cisco.com [10.50.16.40]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ABA01208 (AUTH rraszuk); Tue, 17 Jul 2001 08:53:08 -0700 (PDT) Message-ID: <3B545EE9.6CF57A9A@cisco.com> Date: Tue, 17 Jul 2001 08:51:05 -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: Shahram Davari CC: "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7E@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, As Thomas just said for failure of control plane we will use RSVP Tear msgs (case of unprotected lsp by frr) so the head will know immediately of the failure. > the RESV messages with refresh interval "T". Then we run ICMP-ping messages > until we don't receive ICMP-Echo back. In your description I don't see why waiting for reception of next rsvp resv msg is required for triggering the ICMP test in the first place. R. > Shahram Davari wrote: > > Hi, > > > -----Original Message----- > > From: Robert Raszuk [mailto:raszuk@cisco.com] > > Sent: Tuesday, July 17, 2001 11:04 AM > > To: Shahram Davari > > Cc: 'Yakov Rekhter'; Dave Cooper; 'mpls@uu.net' > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > Shahram, > > > > > > If you don't receive any LSP-ECHO then you may conclude > > that either > > > > the forward LSP is down, or the control channel used by RSVP > > > > (or to be more precise by RESV) to set up the LSP is down. > > > > > > > > > > Which is a useless information, because the whole point of > > the LSP-ping was to > > > find whether the fault is in forward LSP or not ! > > > > Notice what the draft says: > > > > In the case where an LSP has failed to deliver user > > traffic, and the > > failure cannot be easily detected by the MPLS control plane (and > > specifically, RSVP-TE component), > > > > So we do assume that the RSVP-TE control plane is up and running fine > > otherwise there would be no point of even sending icmp msg over failed > > LSP. > > So let me see if I understand this correctly. What you are trying to say is that > first we select an LSP for connectivity test. Then we check to see that we are receiving > the RESV messages with refresh interval "T". Then we run ICMP-ping messages until we don't receive ICMP-Echo back. At this time we wait for a period of "T" to see whether we receive another RESV message or not. If we don't, this means that the RESV path is down, otherwise the RESV path is fine and we can now run LSP-ping. And if we don't receive LSP-Echo back, this means that the forward LSP is down. Right? > > If this is correct then you probably have noticed the delay time "T" between detecting a failure and isolating it to the forward LSP. My point was that this time interval may > be large specially when refresh reduction is used. > > -Shahram > > Having this in mind not receiving of LSP_ECHO in RSVP > > RESV msg IMHO > > clearly identifies the failure of forward LSP under test. > > > > R. > > From owner-mpls@UU.NET Tue Jul 17 12:32: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 SMTP id MAA15707 for ; Tue, 17 Jul 2001 12:32:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyby13918; Tue, 17 Jul 2001 16:31:10 GMT Received: by mail-control.mail.uu.net id QQkyby29564 for mpls-outgoing; Tue, 17 Jul 2001 16:30: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 QQkyby29549 for ; Tue, 17 Jul 2001 16:30:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkybx02914 for ; Tue, 17 Jul 2001 16:28:28 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 QQkybx11227 for ; Tue, 17 Jul 2001 16:28:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA13340 for mpls@uu.net; Tue, 17 Jul 2001 12:28: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 QQkybx28832 for ; Tue, 17 Jul 2001 16:24:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkybx12734 for ; Tue, 17 Jul 2001 16:24:29 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkybx07516 for ; Tue, 17 Jul 2001 16:24:28 GMT Received: from juniper.net ([172.16.167.234]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HGOJH47653; Tue, 17 Jul 2001 09:24:19 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B546820.CE0659B2@juniper.net> Date: Tue, 17 Jul 2001 09:30:24 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'raszuk@cisco.com'" , "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7E@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, Why are you talking about the refresh interval here? Did we write a single word that defines the timing intervals in the draft? No! Shahram Davari wrote: > > So let me see if I understand this correctly. What you are trying to say is that > first we select an LSP for connectivity test. Then we check to see that we are > receiving the RESV messages with refresh interval "T". Then we run ICMP-ping messages > until we don't receive ICMP-Echo back. At this time we wait for a period of "T" to see > whether we receive another RESV message or not. Maybe, maybe not. Another situation is to send the LSP-ping packets immediately while monitoring the LSP states. > If we don't, this means that the RESV path > is down, otherwise the RESV path is fine and we can now run LSP-ping. And if we don't > receive LSP-Echo back, this means that the forward LSP is down. Right? > > If this is correct then you probably have noticed the delay time "T" between detecting > a failure and isolating it to the forward LSP. My point was that this time interval may > be large specially when refresh reduction is used. > T is an independent parameter. - Ping From owner-mpls@UU.NET Tue Jul 17 12:50: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 MAA18609 for ; Tue, 17 Jul 2001 12:50: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 QQkybz29022; Tue, 17 Jul 2001 16:46:27 GMT Received: by mail-control.mail.uu.net id QQkybz01164 for mpls-outgoing; Tue, 17 Jul 2001 16:45:52 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 QQkybz01141 for ; Tue, 17 Jul 2001 16:45:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyby06128 for ; Tue, 17 Jul 2001 16:42:27 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 QQkyby24431 for ; Tue, 17 Jul 2001 16:42:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA14886 for mpls@uu.net; Tue, 17 Jul 2001 12:42: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 QQkyby00691 for ; Tue, 17 Jul 2001 16:41: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 QQkyby24503 for ; Tue, 17 Jul 2001 16:41:12 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 QQkyby00740 for ; Tue, 17 Jul 2001 16:41:11 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 MAA22336; Tue, 17 Jul 2001 12:41:11 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA21645; Tue, 17 Jul 2001 12:41:09 -0400 (EDT) Message-Id: <200107171641.MAA21645@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'raszuk@cisco.com'" , "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" , swallow@cisco.com Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt In-reply-to: Your message of "Tue, 17 Jul 2001 08:36:20 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7E@BBY1EXM01> Date: Tue, 17 Jul 2001 12:41:09 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > If this is correct then you probably have noticed the delay time "T" > between detecting a failure and isolating it to the forward LSP. My > point was that this time interval may be large specially when refresh > reduction is used. Refresh reduction defines a trigger message. The presence of a new or changed LSP_ECHO object will cause an immediate refresh. So without refresh reduction it could take 30 secs / hop (default). With refresh reduction it should be very responsive. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 17 13:18: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 SMTP id NAA24060 for ; Tue, 17 Jul 2001 13:18: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 QQkyca16544; Tue, 17 Jul 2001 17:10:32 GMT Received: by mail-control.mail.uu.net id QQkyca22764 for mpls-outgoing; Tue, 17 Jul 2001 17:09: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 QQkyca22737 for ; Tue, 17 Jul 2001 17:09: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 QQkyca09659 for ; Tue, 17 Jul 2001 17:05: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 QQkyca14781 for ; Tue, 17 Jul 2001 17:05:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA17016 for mpls@uu.net; Tue, 17 Jul 2001 13:05:53 -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 QQkyca17611 for ; Tue, 17 Jul 2001 17:04:59 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 QQkyca07576 for ; Tue, 17 Jul 2001 17:04:45 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 QQkyca21225 for ; Tue, 17 Jul 2001 17:04:44 GMT Received: (qmail 28349 invoked by uid 104); 17 Jul 2001 17:04:44 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.435797 secs); 17/07/2001 10:04:43 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 17:04:43 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HH4fP22921; Tue, 17 Jul 2001 10:04:41 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 10:10:13 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D7F@BBY1EXM01> From: Shahram Davari To: "'raszuk@cisco.com'" Cc: "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 10:10:11 -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, > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Tuesday, July 17, 2001 11:51 AM > To: Shahram Davari > Cc: 'Yakov Rekhter'; Dave Cooper; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > As Thomas just said for failure of control plane we will use RSVP Tear > msgs (case of unprotected lsp by frr) so the head will know > immediately > of the failure. How? if the RESV path has failed how do you detect that and how do you send the Tear message? > > > the RESV messages with refresh interval "T". Then we run > ICMP-ping messages > > until we don't receive ICMP-Echo back. > > In your description I don't see why waiting for reception of next rsvp > resv msg is required for triggering the ICMP test in the first place. > > R. > > > Shahram Davari wrote: > > > > Hi, > > > > > -----Original Message----- > > > From: Robert Raszuk [mailto:raszuk@cisco.com] > > > Sent: Tuesday, July 17, 2001 11:04 AM > > > To: Shahram Davari > > > Cc: 'Yakov Rekhter'; Dave Cooper; 'mpls@uu.net' > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > > > > > > Shahram, > > > > > > > > If you don't receive any LSP-ECHO then you may conclude > > > that either > > > > > the forward LSP is down, or the control channel used by RSVP > > > > > (or to be more precise by RESV) to set up the LSP is down. > > > > > > > > > > > > > Which is a useless information, because the whole point of > > > the LSP-ping was to > > > > find whether the fault is in forward LSP or not ! > > > > > > Notice what the draft says: > > > > > > In the case where an LSP has failed to deliver user > > > traffic, and the > > > failure cannot be easily detected by the MPLS control > plane (and > > > specifically, RSVP-TE component), > > > > > > So we do assume that the RSVP-TE control plane is up and > running fine > > > otherwise there would be no point of even sending icmp > msg over failed > > > LSP. > > > > So let me see if I understand this correctly. What you are > trying to say is that > > first we select an LSP for connectivity test. Then we check > to see that we are receiving > > the RESV messages with refresh interval "T". Then we run > ICMP-ping messages until we don't receive ICMP-Echo back. At > this time we wait for a period of "T" to see whether we > receive another RESV message or not. If we don't, this means > that the RESV path is down, otherwise the RESV path is fine > and we can now run LSP-ping. And if we don't receive LSP-Echo > back, this means that the forward LSP is down. Right? > > > > If this is correct then you probably have noticed the delay > time "T" between detecting a failure and isolating it to the > forward LSP. My point was that this time interval may > > be large specially when refresh reduction is used. > > > > -Shahram > > > > Having this in mind not receiving of LSP_ECHO in RSVP > > > RESV msg IMHO > > > clearly identifies the failure of forward LSP under test. > > > > > > R. > > > > From owner-mpls@UU.NET Tue Jul 17 13:30: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 SMTP id NAA27245 for ; Tue, 17 Jul 2001 13:30: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 QQkycb12870; Tue, 17 Jul 2001 17:27:34 GMT Received: by mail-control.mail.uu.net id QQkycb24564 for mpls-outgoing; Tue, 17 Jul 2001 17:26: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 QQkycb24534 for ; Tue, 17 Jul 2001 17:26: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 QQkycb14725 for ; Tue, 17 Jul 2001 17:24:17 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 QQkycb00026 for ; Tue, 17 Jul 2001 17:24:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA19395 for mpls@uu.net; Tue, 17 Jul 2001 13:24: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 QQkycb23625 for ; Tue, 17 Jul 2001 17:15: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 QQkyca16773 for ; Tue, 17 Jul 2001 17:10:47 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 QQkyca28572 for ; Tue, 17 Jul 2001 17:10:46 GMT Received: (qmail 18793 invoked by uid 104); 17 Jul 2001 17:10:45 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.679457 secs); 17/07/2001 10:10:45 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 17:10:44 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HHAlP26061; Tue, 17 Jul 2001 10:10:47 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 10:16:19 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D80@BBY1EXM01> From: Shahram Davari To: "'Ping Pan'" Cc: "'raszuk@cisco.com'" , "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 10:16:18 -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 Ping, > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Tuesday, July 17, 2001 12:30 PM > To: Shahram Davari > Cc: 'raszuk@cisco.com'; 'Yakov Rekhter'; Dave Cooper; 'mpls@uu.net' > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram, > > Why are you talking about the refresh interval here? Did we write a > single word that defines the timing intervals in the draft? No! No you haven't, but your method implicitly requires a waiting time of "T" equal to the period of refresh RESV message, in order to work correctly. > > Shahram Davari wrote: > > > > So let me see if I understand this correctly. What you are > trying to say is that > > first we select an LSP for connectivity test. Then we check > to see that we are > > receiving the RESV messages with refresh interval "T". Then > we run ICMP-ping messages > > until we don't receive ICMP-Echo back. At this time we wait > for a period of "T" to see > > whether we receive another RESV message or not. > > Maybe, maybe not. Another situation is to send the LSP-ping packets > immediately while monitoring the LSP states. If you do that, then what I explained in my previous emails will happen. In which a failure to receive LSP-Echo can't be translated to a failure in forward LSP, because it might be related to a failure in RESV path. > > > If we don't, this means that the RESV path > > is down, otherwise the RESV path is fine and we can now run > LSP-ping. And if we don't > > receive LSP-Echo back, this means that the forward LSP is > down. Right? > > > > If this is correct then you probably have noticed the delay > time "T" between detecting > > a failure and isolating it to the forward LSP. My point was > that this time interval may > > be large specially when refresh reduction is used. > > > > T is an independent parameter. I know, but in order for you method to work you need to have a short refresh interval "T", which creates scalability issues. > > - Ping > From owner-mpls@UU.NET Tue Jul 17 13:33: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 NAA28037 for ; Tue, 17 Jul 2001 13:33:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkycc06132; Tue, 17 Jul 2001 17:31:02 GMT Received: by mail-control.mail.uu.net id QQkycc25386 for mpls-outgoing; Tue, 17 Jul 2001 17:30: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 QQkycc25347 for ; Tue, 17 Jul 2001 17:30: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 QQkycb24196 for ; Tue, 17 Jul 2001 17:29:09 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 QQkycb15089 for ; Tue, 17 Jul 2001 17:28:46 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA27926 for ; Tue, 17 Jul 2001 13:28:46 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02860 for mpls@uu.net; Tue, 17 Jul 2001 13:28:39 -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 QQkycb24254 for ; Tue, 17 Jul 2001 17:22:37 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 QQkycb17068; Tue, 17 Jul 2001 17:22:34 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkycb12275; Tue, 17 Jul 2001 17:22:33 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Date: Tue, 17 Jul 2001 13:16:53 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-mpls@UU.NET Tue Jul 17 13:40: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 NAA29695 for ; Tue, 17 Jul 2001 13:40: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 QQkycc00062; Tue, 17 Jul 2001 17:37:46 GMT Received: by mail-control.mail.uu.net id QQkycc26972 for mpls-outgoing; Tue, 17 Jul 2001 17:37: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 QQkycc26967 for ; Tue, 17 Jul 2001 17:37:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkycc04750 for ; Tue, 17 Jul 2001 17:36:20 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 QQkycc12708 for ; Tue, 17 Jul 2001 17:36:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA21455 for mpls@uu.net; Tue, 17 Jul 2001 13:36:20 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkycc25880 for ; Tue, 17 Jul 2001 17:32:12 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 QQkycc11205 for ; Tue, 17 Jul 2001 17:30:23 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 QQkycc17647 for ; Tue, 17 Jul 2001 17:30:22 GMT Received: (qmail 5120 invoked by uid 104); 17 Jul 2001 17:30:22 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.406418 secs); 17/07/2001 10:30:21 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 17:30:21 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HHUOP07631; Tue, 17 Jul 2001 10:30:24 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 10:35:56 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D81@BBY1EXM01> From: Shahram Davari To: "'George Swallow'" Cc: "'raszuk@cisco.com'" , "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 10:35:54 -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 George, > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, July 17, 2001 12:41 PM > To: Shahram Davari > Cc: 'raszuk@cisco.com'; 'Yakov Rekhter'; Dave Cooper; 'mpls@uu.net'; > swallow@cisco.com > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > > If this is correct then you probably have noticed the delay time "T" > > between detecting a failure and isolating it to the forward LSP. My > > point was that this time interval may be large specially > when refresh > > reduction is used. > > Refresh reduction defines a trigger message. The presence of a new or > changed LSP_ECHO object will cause an immediate refresh. So without > refresh reduction it could take 30 secs / hop (default). With refresh > reduction it should be very responsive. > Sure. But I am talking about the time period before we start sending LSP-ping and receiving LSP-Echo. I am talking about the time period during which we are sending ICMP-ping and receiving ICMP-Echo. Since ICMP-ping/Echo is not a trigger for refresh RESV, then during this time interval you rely on the usual 30 sec/hop refresh. Therefore if during this interval both the RESV path and reverse LSP fail, we will notice a missing ICMP-Echo but we have no knowledge that the RESV path has failed unless we wait for another refresh RESV message or may be trigger an early RESV message (using methods other than LSP-ping!!). Because if we use LSP-ping to cause an early RESV message, and we don't receive that RESV message, then we won't know whether the failure was in forward LSP or in RESV path. Yours, -Shahram > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Tue Jul 17 14:04: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 OAA05722 for ; Tue, 17 Jul 2001 14:04: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 QQkyce21340; Tue, 17 Jul 2001 18:03:23 GMT Received: by mail-control.mail.uu.net id QQkyce08145 for mpls-outgoing; Tue, 17 Jul 2001 18:02:50 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 QQkyce07985 for ; Tue, 17 Jul 2001 18:02:48 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 QQkyce29997 for ; Tue, 17 Jul 2001 18:02:36 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 QQkyce20179 for ; Tue, 17 Jul 2001 18:02:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA24892 for mpls@uu.net; Tue, 17 Jul 2001 14:02:35 -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 QQkyce04227 for ; Tue, 17 Jul 2001 18: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 QQkyce04161 for ; Tue, 17 Jul 2001 18:01:43 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 QQkyce27793 for ; Tue, 17 Jul 2001 18:01:43 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 OAA17254; Tue, 17 Jul 2001 14:01:42 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA00400; Tue, 17 Jul 2001 14:01:41 -0400 (EDT) Message-Id: <200107171801.OAA00400@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'George Swallow'" , "'raszuk@cisco.com'" , "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" , swallow@cisco.com Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt In-reply-to: Your message of "Tue, 17 Jul 2001 10:35:54 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6037A6D81@BBY1EXM01> Date: Tue, 17 Jul 2001 14:01:41 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Shahram - > Sure. But I am talking about the time period before we start sending > LSP-ping and receiving LSP-Echo. I am talking about the time period > during which we are sending ICMP-ping and receiving ICMP-Echo. Since > ICMP-ping/Echo is not a trigger for refresh RESV, then during this > time interval you rely on the usual 30 sec/hop refresh. Therefore if > during this interval both the RESV path and reverse LSP fail, we > will notice a missing ICMP-Echo but we have no knowledge that the RESV > path has failed unless we wait for another refresh RESV message or may > be trigger an early RESV message (using methods other than LSP-ping!!). Because > if we use LSP-ping to cause an early RESV message, and we don't receive that > RESV message, then we won't know whether the failure was in forward LSP > or in RESV path. So your scenario is that the RSVP control plane and the reverse data plane fail at the same time? And the control plane fails in a way that the headend is not notified quickly? Is this a case worth worrying about? Yes the LSP-tunnel ping will fail. The operator will get notified that there is a problem. And he does indeed have a problem...having an alarm go off for the wrong reason is much better than no alarm. And unless you're trying to do some form of non-stop forwarding over the failure of an intermediate node, then one can argue that you do have a problem with the LSP under test as well. And if are doing some form of non-stop forwarding then the operations staff should be aware of it and know to look for problems in the control plane as well. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 17 14:14:25 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 OAA08168 for ; Tue, 17 Jul 2001 14:14: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 QQkyce09930; Tue, 17 Jul 2001 18:13:39 GMT Received: by mail-control.mail.uu.net id QQkyce20217 for mpls-outgoing; Tue, 17 Jul 2001 18:13: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 QQkyce20206 for ; Tue, 17 Jul 2001 18:12:54 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 QQkyce17431 for ; Tue, 17 Jul 2001 18:11:12 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 QQkyce02191 for ; Tue, 17 Jul 2001 18:11:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA25929 for mpls@uu.net; Tue, 17 Jul 2001 14:11:11 -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 QQkyce19955 for ; Tue, 17 Jul 2001 18:10: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 QQkyce16131 for ; Tue, 17 Jul 2001 18:10:07 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 QQkyce07370 for ; Tue, 17 Jul 2001 18:10:06 GMT Received: (qmail 18312 invoked by uid 104); 17 Jul 2001 18:10:05 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.41642 secs); 17/07/2001 11:10:05 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 18:10:04 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HIA7P01918; Tue, 17 Jul 2001 11:10:08 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 11:15:40 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D82@BBY1EXM01> From: Shahram Davari To: "'George Swallow'" Cc: "'raszuk@cisco.com'" , "'Yakov Rekhter'" , Dave Cooper , "'mpls@uu.net'" Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt Date: Tue, 17 Jul 2001 11:15:37 -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 George, > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, July 17, 2001 2:02 PM > To: Shahram Davari > Cc: 'George Swallow'; 'raszuk@cisco.com'; 'Yakov Rekhter'; > Dave Cooper; > 'mpls@uu.net'; swallow@cisco.com > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt > > > Shahram - > > > Sure. But I am talking about the time period before we start sending > > LSP-ping and receiving LSP-Echo. I am talking about the time period > > during which we are sending ICMP-ping and receiving ICMP-Echo. Since > > ICMP-ping/Echo is not a trigger for refresh RESV, then during this > > time interval you rely on the usual 30 sec/hop refresh. > Therefore if > > during this interval both the RESV path and reverse LSP fail, we > > will notice a missing ICMP-Echo but we have no knowledge > that the RESV > > path has failed unless we wait for another refresh RESV > message or may > > be trigger an early RESV message (using methods other than > LSP-ping!!). Because > > if we use LSP-ping to cause an early RESV message, and we > don't receive that > > RESV message, then we won't know whether the failure was in > forward LSP > > or in RESV path. > > So your scenario is that the RSVP control plane and the reverse data > plane fail at the same time? And the control plane fails in a way > that the headend is not notified quickly? Is this a case worth > worrying about? Yes. Because it can happen easily when a line card that is shared by both RESV path and reverse LSP fails at the egress LSR. > Yes the LSP-tunnel ping will fail. The operator will > get notified that there is a problem. And he does indeed have a > problem...having an alarm go off for the wrong reason is much better > than no alarm. I didn't suggest having no alarm, I suggested using another method that does not have this problem. > > And unless you're trying to do some form of non-stop forwarding over > the failure of an intermediate node, then one can argue that you do > have a problem with the LSP under test as well. A failure of the control-plane is not equal to a failure of data-plane and should not cause interruption of data-plane. > > And if are doing some form of non-stop forwarding then the operations > staff should be aware of it and know to look for problems in the > control plane as well. That is the job of control plane. Control plane should have its own OAM. -Shahram > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Tue Jul 17 15:06: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 PAA18787 for ; Tue, 17 Jul 2001 15:06: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 QQkyci12104; Tue, 17 Jul 2001 19:04:30 GMT Received: by mail-control.mail.uu.net id QQkyci04528 for mpls-outgoing; Tue, 17 Jul 2001 19:03: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 QQkyci04136 for ; Tue, 17 Jul 2001 19:03: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 QQkyci24252 for ; Tue, 17 Jul 2001 19:02:59 GMT Received: from hypnos.cps.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hypnos.cps.intel.com [192.198.165.17]) id QQkyci10243 for ; Tue, 17 Jul 2001 19:02:58 GMT Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id TAA25813; Tue, 17 Jul 2001 19:02:44 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 17 Jul 2001 19:02:44 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 12:02:43 -0700 Message-ID: From: "Feng, Mark" To: "'David Charlap'" , mpls@UU.NET Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Date: Tue, 17 Jul 2001 12:02:41 -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 Thanks for the response. Please see the comments below. > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Tuesday, July 17, 2001 11:33 AM > To: mpls@UU.NET > Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > > > "Feng, Mark" wrote: > > > > Hi, I have some doubts regarding the usage of SE style within MPLS. > > > > My question is, with SE style, besides doing make-before-break, is > > it used for other purpose? > > > > Consider the following LSP setups (with each sender potentially > > having different traffic requirements) using SE style, by using > > explicit routing. > > > > ______ > > | | > > +---| |---+ > > | |______| | > > | | > > |s1,s3 |s1,s3 > > s1,s2 ______ | | ______ > > -----| |-+ +-| | s1,s2,s3,s4 > > -----| |-+ +-| |------ > > s3,s4|______| | | |______| > > |s2,s4_____ |s2,s4 > > | | | | > > +---| |---+ > > |______| > > > > Is this possible in RSVP-TE? > > SE style only shares resources among LSPs that share a single session. > Sorry I didn't make it clear. All the senders in the diagram belong to the same session. Considering the first node on the diagram, S1, S2 come in at one interface, and S3, S4 come in at a different interface. Even though they belong to the same session, the Path messages travel a different path. This is somewhat different from RSVP/RFC 2205, where, in unicast, Path messages for the same session take the same path. In this case, because Path messages take different routes, Resv messages will arrive at different interfaces, with potentially different resource requirements. The process of handling the resource allocation at various interfaces, as a result, is somewhat different from RSVP/RFC 2205. I just want to make sure this is a valid scenario. > If two LSPs must not share resources, then they should be in separate > sessions. The easiest way to ensure this is to make sure > that they use > different tunnel IDs. > > Putting them in the same session and requesting FF style > might work, but > I would not recommend it because: > 1: The egress router may ignore the request and reserve SE > style anyway. > 2: If one of those LSPs must be rerouted, make-before-break > may fail. If it doesn't fail, it may temporarily waste > resources. > I agree. Or they could put their own IP address in the extended tunnle ID. > -- David > - Mark From owner-mpls@UU.NET Tue Jul 17 15:07: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 PAA19171 for ; Tue, 17 Jul 2001 15:07: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 QQkyci15368; Tue, 17 Jul 2001 19:07:00 GMT Received: by mail-control.mail.uu.net id QQkyci08835 for mpls-outgoing; Tue, 17 Jul 2001 19:06:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkyci08501 for ; Tue, 17 Jul 2001 19:06:06 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 QQkyci25531 for ; Tue, 17 Jul 2001 19:05:35 GMT Received: from saga14.Stanford.EDU by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saga14.Stanford.EDU [171.64.15.144]) id QQkyci13620 for ; Tue, 17 Jul 2001 19:05:35 GMT Received: (from manish1@localhost) by saga14.Stanford.EDU (8.11.3/8.11.3) id f6HJ5Y119860; Tue, 17 Jul 2001 12:05:34 -0700 (PDT) Date: Tue, 17 Jul 2001 12:05:34 -0700 (PDT) From: To: Subject: [MPLS] Popping Multiple Labels Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I was wondering if there are any possible scenarios in which a node might pop multiple labels from the stack. One case I was thinking of is : a node is endpoint of a tunnel (T1) and is also a penultimate hop for another tunnel (T2) and T2 is tunneled over T1! Maybe this is not a valid scenario but I would like to check. I appreciate any help. thanks, manish PS: Scenario +-----+ +-------+ +-------+ +------+ | | ===~== | | ====~~=== | +---------+ | | L1 | | L21 | | L2n | | L3 | +-----+ +-------+ +-------+ +------+ <------------ T1 --------------> <--------------------------T2----------------------> From owner-mpls@UU.NET Tue Jul 17 15:13: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 PAA20076 for ; Tue, 17 Jul 2001 15:13: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 QQkyci21135; Tue, 17 Jul 2001 19:13:12 GMT Received: by mail-control.mail.uu.net id QQkyci15272 for mpls-outgoing; Tue, 17 Jul 2001 19:12:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkyci15255 for ; Tue, 17 Jul 2001 19:12:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyci02247 for ; Tue, 17 Jul 2001 19:09:02 GMT Received: from smtp.monmouth.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.monmouth.com [209.191.58.6]) id QQkyci24498 for ; Tue, 17 Jul 2001 19:09:01 GMT Received: from monmouth.com ([64.19.191.1]) by smtp.monmouth.com (8.11.4/8.11.4) with ESMTP id f6HJ91M45210 for ; Tue, 17 Jul 2001 15:09:01 -0400 (EDT) Message-ID: <3B547F4C.FD923F53@monmouth.com> Date: Tue, 17 Jul 2001 14:09:16 -0400 From: Dipak X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: One simple question References: <006a01c10ed7$40765960$753ad93f@gemplex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, Can anybody suggest someway that a network manager (say, SNMP manager) can discover that any MPLS enabled router in its network has RSVP-TE implemented for establishing LSP tunnel? Thanks, dipak From owner-mpls@UU.NET Tue Jul 17 15:17:00 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 PAA20593 for ; Tue, 17 Jul 2001 15:17: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 QQkycj00494; Tue, 17 Jul 2001 19:15:51 GMT Received: by mail-control.mail.uu.net id QQkycj15763 for mpls-outgoing; Tue, 17 Jul 2001 19:15: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 QQkycj15753 for ; Tue, 17 Jul 2001 19:15:12 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 QQkyci10917 for ; Tue, 17 Jul 2001 19:14:46 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 QQkyci23254 for ; Tue, 17 Jul 2001 19:14:46 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 PAA21576 for ; Tue, 17 Jul 2001 15:14:43 -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 PAA12471 for ; Tue, 17 Jul 2001 15:14:43 -0400 (EDT) Message-ID: <3B548EA8.C2184D99@marconi.com> Date: Tue, 17 Jul 2001 15:14:48 -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: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Feng, Mark" wrote: >>> >>> ______ >>> | | >>> +---| |---+ >>> | |______| | >>> | | >>> |s1,s3 |s1,s3 >>> s1,s2 ______ | | ______ >>> -----| |-+ +-| | s1,s2,s3,s4 >>> -----| |-+ +-| |------ >>> s3,s4|______| | | |______| >>> |s2,s4_____ |s2,s4 >>> | | | | >>> +---| |---+ >>> |______| >>> >>> Is this possible in RSVP-TE? >> >> SE style only shares resources among LSPs that share a single >> session. > > Sorry I didn't make it clear. All the senders in the diagram belong > to the same session. Then all senders will get the same reservation. > Considering the first node on the diagram, S1, S2 come in at one > interface, and S3, S4 come in at a different interface. Even though > they belong to the same session, the Path messages travel a > different path. This is somewhat different from RSVP/RFC 2205, > where, in unicast, Path messages for the same session take the > same path. > > In this case, because Path messages take different routes, Resv > messages will arrive at different interfaces, with potentially > different resource requirements. The process of handling the > resource allocation at various interfaces, as a result, is > somewhat different from RSVP/RFC 2205. Not really. Reservations all come from the egress. All LSPs share a common egress router. Whatever reservation it chooses for one sender must be used for all of them. This Resv message may split up (with different filterspecs in the flow descriptor) as it follows to the different PHOP routers, but they all reserve the same resources. When they come back together at the ingress router, they are still the same. If the egress router tries to send different flowspecs for each sender, then it is in error. > I just want to make sure this is a valid scenario. It is. >> If two LSPs must not share resources, then they should be in >> separate sessions. The easiest way to ensure this is to make sure >> that they use different tunnel IDs. >> >> Putting them in the same session and requesting FF style >> might work, but I would not recommend it because: >> 1: The egress router may ignore the request and reserve SE >> style anyway. >> 2: If one of those LSPs must be rerouted, make-before-break >> may fail. If it doesn't fail, it may temporarily waste >> resources. > > I agree. Or they could put their own IP address in the extended > tunnle ID. If all the LSPs originate from the same router, then it may not be possible to give them different extended tunnel IDs. But yes, that would also be possible. -- David From owner-mpls@UU.NET Tue Jul 17 15:18:17 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 PAA20845 for ; Tue, 17 Jul 2001 15:18:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkycj28297; Tue, 17 Jul 2001 19:17:27 GMT Received: by mail-control.mail.uu.net id QQkycj16216 for mpls-outgoing; Tue, 17 Jul 2001 19:16: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 QQkycj16203 for ; Tue, 17 Jul 2001 19:16: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 QQkycj14868 for ; Tue, 17 Jul 2001 19:15:27 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 QQkycj25861 for ; Tue, 17 Jul 2001 19:15:26 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA14218; Tue, 17 Jul 2001 15:15:25 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03238; Tue, 17 Jul 2001 15:15:18 -0400 (EDT) Message-Id: <200107171915.PAA03238@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'mpLS@UU.net'" Subject: Re: LSP-ping In-reply-to: Your message of Tue, 17 Jul 2001 11:46:04 -0700. <9DC5E2ABE65BD54CA9088DA3194461D6037A6D83@BBY1EXM01> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Jul 2001 15:15:18 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> Could anybody explain to me what is wrong with running ICMP-ping Shahram> over the both the forward and reverse LSP? This won't help you determine which of these two LSPs has failed, since each ICMP-ping uses both LSPs. A mechanism which uses ONLY the LSP that is being tested seems worthwhile as a fault isolation tool, and that's really what LSP-ping offers you. As you've pointed out, the mechanism only returns useful information when the control plane is functioning properly. What the mechanism really tells you is that somewhere along the line, some LSR has a corrupt label switching table, where "corrupt" may be defined as "what's in the table is not what the control plane thinks is in there". Although I think this mechanism is useful, I'm not convinced that piggybacking the response in the control messages is necessary or desirable, and I plan to look at alternative mechanisms for returning the response. From owner-mpls@UU.NET Tue Jul 17 15:24: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 PAA22106 for ; Tue, 17 Jul 2001 15:24: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 QQkycj06038; Tue, 17 Jul 2001 19:23:37 GMT Received: by mail-control.mail.uu.net id QQkycj17496 for mpls-outgoing; Tue, 17 Jul 2001 19:22: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 QQkycj17464 for ; Tue, 17 Jul 2001 19:22:54 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 QQkycj19485 for ; Tue, 17 Jul 2001 19:19:13 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 QQkycj28791 for ; Tue, 17 Jul 2001 19:19:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA05196 for mpls@uu.net; Tue, 17 Jul 2001 15:19: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 QQkycj16308 for ; Tue, 17 Jul 2001 19:17: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 QQkycj12152 for ; Tue, 17 Jul 2001 19:15:44 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkycj26138 for ; Tue, 17 Jul 2001 19:15:44 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HJFfH57776; Tue, 17 Jul 2001 12:15:41 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B548ED4.2942A3D1@juniper.net> Date: Tue, 17 Jul 2001 12:15:33 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'mpLS@UU.net'" Subject: Re: LSP-ping References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D83@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > Hi, > > Could anybody explain to me what is wrong with running ICMP-ping over the both the forward and reverse LSP? > If the reserve path has multiple LSP's and one of them is down, how can you tell if the forwarding LSP (the one operators are interested in) is up or down? From owner-mpls@UU.NET Tue Jul 17 15:28:17 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 PAA23048 for ; Tue, 17 Jul 2001 15:28:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkycg08793; Tue, 17 Jul 2001 18:37:17 GMT Received: by mail-control.mail.uu.net id QQkycg22328 for mpls-outgoing; Tue, 17 Jul 2001 18:36:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkycg22309 for ; Tue, 17 Jul 2001 18:36: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 QQkycg15892 for ; Tue, 17 Jul 2001 18:35: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 QQkycg04753 for ; Tue, 17 Jul 2001 18:35:13 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16973 for ; Tue, 17 Jul 2001 14:35:10 -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 OAA29034 for ; Tue, 17 Jul 2001 14:35:11 -0400 (EDT) Message-ID: <3B548564.899AF7E2@marconi.com> Date: Tue, 17 Jul 2001 14:35: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: Some Doubts References: <00af01c10e21$345e7600$c500a8c0@MBRAHMANAPALLY> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Is it possible to have MPLS aware nodes but not aware of RSVP-TE??? Yes. It is possible that some vendor's implementation may support LDP or CR-LDP but not RSVP-TE. It is also possible that the RSVP-TE protocol may be disabled on a switch. -- David From owner-mpls@UU.NET Tue Jul 17 15:30: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 PAA23351 for ; Tue, 17 Jul 2001 15:30: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 QQkycj11844; Tue, 17 Jul 2001 19:29:27 GMT Received: by mail-control.mail.uu.net id QQkycj18619 for mpls-outgoing; Tue, 17 Jul 2001 19:28: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 QQkycj18544 for ; Tue, 17 Jul 2001 19:28: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 QQkycj28408 for ; Tue, 17 Jul 2001 19:26:40 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 QQkycj08174 for ; Tue, 17 Jul 2001 19:26:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA06328 for mpls@uu.net; Tue, 17 Jul 2001 15:26:39 -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 QQkycj18136 for ; Tue, 17 Jul 2001 19:26:00 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 QQkycj24968 for ; Tue, 17 Jul 2001 19:25:04 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 QQkycj07889 for ; Tue, 17 Jul 2001 19:25:03 GMT Received: (qmail 24363 invoked by uid 104); 17 Jul 2001 19:25:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.386153 secs); 17/07/2001 12:25:02 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 19:25:02 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HJP5P20759; Tue, 17 Jul 2001 12:25:05 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 12:30:37 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D86@BBY1EXM01> From: Shahram Davari To: "'Ping Pan'" Cc: "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Tue, 17 Jul 2001 12:30:36 -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 Ping, > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Tuesday, July 17, 2001 3:16 PM > To: Shahram Davari > Cc: 'mpLS@UU.net' > Subject: Re: LSP-ping > > > Shahram Davari wrote: > > > > Hi, > > > > Could anybody explain to me what is wrong with running > ICMP-ping over the both the forward and reverse LSP? > > > > If the reserve path has multiple LSP's and one of them is > down, how can > you tell if the forwarding LSP (the one operators are > interested in) is > up or down? > The ingress LSR should know which LSP is the reverse LSP. -Shahram From owner-mpls@UU.NET Tue Jul 17 15:32: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 PAA23731 for ; Tue, 17 Jul 2001 15:32: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 QQkyck13741; Tue, 17 Jul 2001 19:31:02 GMT Received: by mail-control.mail.uu.net id QQkyck19151 for mpls-outgoing; Tue, 17 Jul 2001 19:30: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 QQkyck19122 for ; Tue, 17 Jul 2001 19:30:23 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 QQkycj28849 for ; Tue, 17 Jul 2001 19:28:30 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 QQkycj10542 for ; Tue, 17 Jul 2001 19:28:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA06664 for mpls@uu.net; Tue, 17 Jul 2001 15:28: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 QQkycj18064 for ; Tue, 17 Jul 2001 19:25: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 QQkycj22511 for ; Tue, 17 Jul 2001 19:23:49 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 QQkycj06316 for ; Tue, 17 Jul 2001 19:23:48 GMT Received: (qmail 24126 invoked by uid 104); 17 Jul 2001 19:23:48 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.929806 secs); 17/07/2001 12:23:47 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 19:23:46 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HJNnP19821; Tue, 17 Jul 2001 12:23:49 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 12:29:21 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D85@BBY1EXM01> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Tue, 17 Jul 2001 12:29:20 -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, > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, July 17, 2001 3:15 PM > To: Shahram Davari > Cc: 'mpLS@UU.net' > Subject: Re: LSP-ping > > > > Shahram> Could anybody explain to me what is wrong with > running ICMP-ping > Shahram> over the both the forward and reverse LSP? > > This won't help you determine which of these two LSPs has > failed, since each > ICMP-ping uses both LSPs. My suggestion is different. The ingress LSR checks the connectivity status of the reverse LSP, by checking to see whether it is receiving ICMP-pings from the egress LSR. If it is, then the reverse LSP is fine, and any failure to receive ICMP-Echo from the egress LSR is due to forward LSP. -Shahram > A mechanism which uses ONLY the LSP that is being tested > seems worthwhile as > a fault isolation tool, and that's really what LSP-ping offers you. > > As you've pointed out, the mechanism only returns useful > information when > the control plane is functioning properly. What the > mechanism really tells > you is that somewhere along the line, some LSR has a corrupt > label switching > table, where "corrupt" may be defined as "what's in the > table is not what > the control plane thinks is in there". > > Although I think this mechanism is useful, I'm not > convinced that > piggybacking the response in the control messages is > necessary or desirable, > and I plan to look at alternative mechanisms for returning > the response. > > > From owner-mpls@UU.NET Tue Jul 17 15:33: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 PAA23968 for ; Tue, 17 Jul 2001 15:33:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyck15793; Tue, 17 Jul 2001 19:32:39 GMT Received: by mail-control.mail.uu.net id QQkyck19565 for mpls-outgoing; Tue, 17 Jul 2001 19:32:03 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 QQkyck19245 for ; Tue, 17 Jul 2001 19:31: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 QQkyck00973 for ; Tue, 17 Jul 2001 19:30:21 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 QQkyck13279 for ; Tue, 17 Jul 2001 19:30:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA06887 for mpls@uu.net; Tue, 17 Jul 2001 15:30:21 -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 QQkycj18011 for ; Tue, 17 Jul 2001 19:25: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 QQkycj24007 for ; Tue, 17 Jul 2001 19:25:08 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkycj07945 for ; Tue, 17 Jul 2001 19:25:07 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HJP5H58218; Tue, 17 Jul 2001 12:25:05 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B549109.C4BB5622@juniper.net> Date: Tue, 17 Jul 2001 12:24:57 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari , "'mpLS@UU.net'" Subject: Re: LSP-ping References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D83@BBY1EXM01> <3B548ED4.2942A3D1@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping Pan wrote: > > Shahram Davari wrote: > > > > Hi, > > > > Could anybody explain to me what is wrong with running ICMP-ping over the both the forward and reverse LSP? > > > > If the reserve path has multiple LSP's and one of them is down, how can ^^^^^^^ reverse > you tell if the forwarding LSP (the one operators are interested in) is > up or down? From owner-mpls@UU.NET Tue Jul 17 15:39: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 PAA25414 for ; Tue, 17 Jul 2001 15:39: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 QQkycg15108; Tue, 17 Jul 2001 18:44:12 GMT Received: by mail-control.mail.uu.net id QQkycg22934 for mpls-outgoing; Tue, 17 Jul 2001 18:43: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 QQkycg22926 for ; Tue, 17 Jul 2001 18:43: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 QQkycg24503 for ; Tue, 17 Jul 2001 18:41:24 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkycg14315 for ; Tue, 17 Jul 2001 18:41:24 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 OAA17841 for ; Tue, 17 Jul 2001 14:41:21 -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 OAA00706 for ; Tue, 17 Jul 2001 14:41:23 -0400 (EDT) Message-ID: <3B5486D8.B0689650@marconi.com> Date: Tue, 17 Jul 2001 14:41:28 -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: Some Doubts References: <3B4E9BF5.247F724D@sasken.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adithya Bhat wrote: > > In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says > > "RSVP is designed to cope gracefully with non-RSVP routers > anywhere between senders and receivers. However, obviously, > non-RSVP routers cannot convey labels via RSVP. This means > that if a router has a neighbor that is known to not be RSVP > capable, the router MUST NOT advertise the LABEL_REQUEST > object when sending messages that pass through the non-RSVP > routers. The router SHOULD send a PathErr back to the sender, > with the error code "Routing problem" and the error value > "MPLS being negotiated, but a non-RSVP capable router stands > in the path." > > 1. Why should a PathErr be sent back to the sender ? Will the > current router not be a egress router, and hence should send a > label binding back. This is RSVP-TE, not LDP. The egress router for an LSP is the router specified in the SESSION object, and no other. RSVP-TE signaled LSPs can only terminate on the router specified by the SESSION object. If the LSP can not be established to that router, then it is an error condition and the ingress router must be notified (via a PathErr object) > 2. If the above is not true does it mean that all the routers (from > the sender to the reciever ) should be rsvp-te capable ( should > support labels) routers ? Yes. All the routers along the path from ingress to egress must support RSVP-TE. > 3. What is the meaning of "MPLS being negotiated, but a non-RSVP > capable router stands in the path." Just what it says. There's a router along the path from ingress to egress that does not support RSVP-TE. If an explicit route object is used, the ingress must generate a different ERO that avoids the non-RSVP-TE router. If ERO is not used, then the LSP won't be able to come up unless the routing table changes sufficiently so that the non-RSVP-TE router won't be used by the LSP. -- David From owner-mpls@UU.NET Tue Jul 17 15:42: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 SMTP id PAA26286 for ; Tue, 17 Jul 2001 15:42: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 QQkyck25606; Tue, 17 Jul 2001 19:42:40 GMT Received: by mail-control.mail.uu.net id QQkyck20635 for mpls-outgoing; Tue, 17 Jul 2001 19:42: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 QQkyck20605 for ; Tue, 17 Jul 2001 19:41: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 QQkyck15053 for ; Tue, 17 Jul 2001 19:41:31 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 QQkyck26766 for ; Tue, 17 Jul 2001 19:41:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA09638 for mpls@uu.net; Tue, 17 Jul 2001 15:41:31 -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 QQkyck20515 for ; Tue, 17 Jul 2001 19:40:54 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 QQkyck10942 for ; Tue, 17 Jul 2001 19:38:11 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 QQkyck23573 for ; Tue, 17 Jul 2001 19:38:10 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 PAA17134; Tue, 17 Jul 2001 15:38:09 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA25135; Tue, 17 Jul 2001 15:38:08 -0400 (EDT) Message-Id: <200107171938.PAA25135@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'Ping Pan'" , "'mpLS@UU.net'" , swallow@cisco.com Subject: Re: LSP-ping In-reply-to: Your message of "Tue, 17 Jul 2001 12:30:36 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6037A6D86@BBY1EXM01> Date: Tue, 17 Jul 2001 15:38:08 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > The ingress LSR should know which LSP is the reverse LSP. Huh??? There may be no LSP directly from the egress LSR back to the ingress. Suppose we have a tunnel from A to D A->B->C->D D may have no tunnel to A but one to either B or C. or D could have no tunnels but C has one to either B or A. Or B could have a tunnel back to A. Or the IP routed path in the reverse direction is not symmetric and the reply could be lost going down a tunnel from G to Q. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 17 15:48: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 PAA27489 for ; Tue, 17 Jul 2001 15:48: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 QQkycl00844; Tue, 17 Jul 2001 19:47:56 GMT Received: by mail-control.mail.uu.net id QQkycl21451 for mpls-outgoing; Tue, 17 Jul 2001 19:47: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 QQkycl21390 for ; Tue, 17 Jul 2001 19:47:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkycl24574 for ; Tue, 17 Jul 2001 19:45:44 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 QQkycl01945 for ; Tue, 17 Jul 2001 19:45:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA10319 for mpls@uu.net; Tue, 17 Jul 2001 15:45:43 -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 QQkycl21140 for ; Tue, 17 Jul 2001 19:45: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 QQkyck18815 for ; Tue, 17 Jul 2001 19:44:42 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 QQkyck27767 for ; Tue, 17 Jul 2001 19:44:41 GMT Received: (qmail 29322 invoked by uid 104); 17 Jul 2001 19:44:40 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.978614 secs); 17/07/2001 12:44:39 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 19:44:39 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HJigP03165; Tue, 17 Jul 2001 12:44:42 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 12:50:14 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D87@BBY1EXM01> From: Shahram Davari To: "'Ping Pan'" Cc: "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Tue, 17 Jul 2001 12:50:13 -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 Ping, What do you mean by multiple LSPs? if you mean multiple parallel LSPs, then the answer is what I said, that the ingress LSR should know which LSP is used as the reverse LSP for the ICMP-Echo. If by multiple LSPs you mean multiple hierarchical LSPs, it doesn't matter which one fails, if you don't receive the ICMP-ping through the LSP that is used to carry the ICMP-Echo (of the forward LSP), then the reverse path has effectively failed not the forward LSP. -Shahram > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Tuesday, July 17, 2001 3:39 PM > To: Shahram Davari > Cc: 'mpLS@UU.net' > Subject: Re: LSP-ping > > > Shahram Davari wrote: > > > > > > > > If the reserve path has multiple LSP's and one of them is > > > down, how can > > > you tell if the forwarding LSP (the one operators are > > > interested in) is > > > up or down? > > > > > > > The ingress LSR should know which LSP is the reverse LSP. > > > > One more time, the reverse path can go through *many* LSP's. > One of them > is dead in the middle of somewhere. How can the ingress know if the > forwarding LSP is up or down base on ICMP ping's? The answer is it > doesn't, and your scheme does not work! > From owner-mpls@UU.NET Tue Jul 17 15:55: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 PAA29269 for ; Tue, 17 Jul 2001 15:55: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 QQkycl13306; Tue, 17 Jul 2001 19:54:54 GMT Received: by mail-control.mail.uu.net id QQkycl22307 for mpls-outgoing; Tue, 17 Jul 2001 19:54: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 QQkycl22294 for ; Tue, 17 Jul 2001 19:54:08 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 QQkycl25118 for ; Tue, 17 Jul 2001 19:53:22 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 QQkycl11274 for ; Tue, 17 Jul 2001 19:53:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA11632 for mpls@uu.net; Tue, 17 Jul 2001 15:53:22 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkycl22174 for ; Tue, 17 Jul 2001 19:52: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 QQkycl02609 for ; Tue, 17 Jul 2001 19:51:32 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 QQkycl08986 for ; Tue, 17 Jul 2001 19:51:32 GMT Received: (qmail 944 invoked by uid 104); 17 Jul 2001 19:51:27 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.394581 secs); 17/07/2001 12:51:27 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 19:51:27 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HJpUP06932; Tue, 17 Jul 2001 12:51:30 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 12:57:02 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D88@BBY1EXM01> From: Shahram Davari To: "'George Swallow'" Cc: "'Ping Pan'" , "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Tue, 17 Jul 2001 12:57:01 -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 George, My scheme still works in the scenarios that you mentioned. Becasue the egress LSR sends ICMP-ping toward the ingress LSR (not necessarily through any LSP) , the same way that it sends the ICMP-Echo toward the ingress LSR. So both the ICMP-Echo (of the forward LSP) and the ICMP-ping of the reverse direction travel over the same path, which may or may not include some LSPs. The end result is that the ingress LSR checks to see whether it is receiving any ICMP-ping from the egress LSR, and if so, the reverse path (be it an LSP or anything else) is fine. -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, July 17, 2001 3:38 PM > To: Shahram Davari > Cc: 'Ping Pan'; 'mpLS@UU.net'; swallow@cisco.com > Subject: Re: LSP-ping > > > > The ingress LSR should know which LSP is the reverse LSP. > > Huh??? There may be no LSP directly from the egress LSR back to the > ingress. > > Suppose we have a tunnel from A to D A->B->C->D > > D may have no tunnel to A but one to either B or C. or D could have > no tunnels but C has one to either B or A. Or B could have a tunnel > back to A. Or the IP routed path in the reverse direction is not > symmetric and the reply could be lost going down a tunnel from G to Q. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Tue Jul 17 15:57: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 PAA29978 for ; Tue, 17 Jul 2001 15:57: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 QQkycl09955; Tue, 17 Jul 2001 19:56:30 GMT Received: by mail-control.mail.uu.net id QQkycl22439 for mpls-outgoing; Tue, 17 Jul 2001 19:55: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 QQkycl22393 for ; Tue, 17 Jul 2001 19:55:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkycl03472 for ; Tue, 17 Jul 2001 19:54:58 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 QQkycl08275 for ; Tue, 17 Jul 2001 19:54:58 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03263; Tue, 17 Jul 2001 15:54:56 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03335; Tue, 17 Jul 2001 15:54:49 -0400 (EDT) Message-Id: <200107171954.PAA03335@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'mpLS@UU.net'" Subject: Re: LSP-ping In-reply-to: Your message of Tue, 17 Jul 2001 12:29:20 -0700. <9DC5E2ABE65BD54CA9088DA3194461D6037A6D85@BBY1EXM01> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Jul 2001 15:54:49 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> My suggestion is different. The ingress LSR checks the connectivity Shahram> status of the reverse LSP, by checking to see whether it is Shahram> receiving ICMP-pings from the egress LSR. If it is, then the Shahram> reverse LSP is fine, and any failure to receive ICMP-Echo from the Shahram> egress LSR is due to forward LSP. Presumably, the egress LSR is not normally pinging the ingress LSR, so I'm not sure just what you mean. (If all LSP egresses are constantly pinging all LSP ingresses, then I think we have a scaling problem.) If the problem one is investigating is that there appear to be data packets that reach the LSP ingress but get lost before they reach the LSP egress, I don't think one wants a diagnostic tool that depends on one's being able to explicitly control the egress. So telling the egress to ping the ingress (and then monitoring the ingress to see if the pings are received) doesn't seem like the best strategy. From owner-mpls@UU.NET Tue Jul 17 16:22: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 QAA05851 for ; Tue, 17 Jul 2001 16:22: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 QQkycg26881; Tue, 17 Jul 2001 18:38:41 GMT Received: by mail-control.mail.uu.net id QQkycg22366 for mpls-outgoing; Tue, 17 Jul 2001 18:36: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 QQkycg22330 for ; Tue, 17 Jul 2001 18:36:44 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 QQkycg12399 for ; Tue, 17 Jul 2001 18:32:42 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkycg21299 for ; Tue, 17 Jul 2001 18:32:42 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16664 for ; Tue, 17 Jul 2001 14:32:34 -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 OAA28376 for ; Tue, 17 Jul 2001 14:32:36 -0400 (EDT) Message-ID: <3B5484CA.AF739B47@marconi.com> Date: Tue, 17 Jul 2001 14:32:42 -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: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Feng, Mark" wrote: > > Hi, I have some doubts regarding the usage of SE style within MPLS. > > My question is, with SE style, besides doing make-before-break, is > it used for other purpose? > > Consider the following LSP setups (with each sender potentially > having different traffic requirements) using SE style, by using > explicit routing. > > ______ > | | > +---| |---+ > | |______| | > | | > |s1,s3 |s1,s3 > s1,s2 ______ | | ______ > -----| |-+ +-| | s1,s2,s3,s4 > -----| |-+ +-| |------ > s3,s4|______| | | |______| > |s2,s4_____ |s2,s4 > | | | | > +---| |---+ > |______| > > Is this possible in RSVP-TE? SE style only shares resources among LSPs that share a single session. If two LSPs must not share resources, then they should be in separate sessions. The easiest way to ensure this is to make sure that they use different tunnel IDs. Putting them in the same session and requesting FF style might work, but I would not recommend it because: 1: The egress router may ignore the request and reserve SE style anyway. 2: If one of those LSPs must be rerouted, make-before-break may fail. If it doesn't fail, it may temporarily waste resources. -- David From owner-mpls@UU.NET Tue Jul 17 16:26: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 QAA06333 for ; Tue, 17 Jul 2001 16:26: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 QQkycn18041; Tue, 17 Jul 2001 20:25:08 GMT Received: by mail-control.mail.uu.net id QQkycn15501 for mpls-outgoing; Tue, 17 Jul 2001 20:24: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 QQkycn15493 for ; Tue, 17 Jul 2001 20:24:30 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 QQkycn22558 for ; Tue, 17 Jul 2001 20:23:20 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 QQkycn18050 for ; Tue, 17 Jul 2001 20:23:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA15778 for mpls@uu.net; Tue, 17 Jul 2001 16:23:19 -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 QQkyck20507 for ; Tue, 17 Jul 2001 19:40: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 QQkyck11586 for ; Tue, 17 Jul 2001 19:38:41 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkyck23403 for ; Tue, 17 Jul 2001 19:38:41 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HJccH58959; Tue, 17 Jul 2001 12:38:38 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B549436.6D567A14@juniper.net> Date: Tue, 17 Jul 2001 12:38:30 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'mpLS@UU.net'" Subject: Re: LSP-ping References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D86@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > > > > If the reserve path has multiple LSP's and one of them is > > down, how can > > you tell if the forwarding LSP (the one operators are > > interested in) is > > up or down? > > > > The ingress LSR should know which LSP is the reverse LSP. > One more time, the reverse path can go through *many* LSP's. One of them is dead in the middle of somewhere. How can the ingress know if the forwarding LSP is up or down base on ICMP ping's? The answer is it doesn't, and your scheme does not work! From owner-mpls@UU.NET Tue Jul 17 16:35: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 QAA07700 for ; Tue, 17 Jul 2001 16:35: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 QQkyco20153; Tue, 17 Jul 2001 20:35:24 GMT Received: by mail-control.mail.uu.net id QQkyco16608 for mpls-outgoing; Tue, 17 Jul 2001 20:34:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkyco16555 for ; Tue, 17 Jul 2001 20:34:40 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 QQkyco00216 for ; Tue, 17 Jul 2001 20:30:56 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkyco14953 for ; Tue, 17 Jul 2001 20:30:55 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6HKUsX06583 for ; Tue, 17 Jul 2001 16:30:54 -0400 (EDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Jul 2001 16:30:54 -0400 Message-ID: From: "Jiang, Donghua (Donghua)" To: "'wiseguy@cs.stanford.edu'" Cc: "'mpls@uu.net'" Subject: RE: [MPLS] Popping Multiple Labels Date: Tue, 17 Jul 2001 16:30:53 -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 Manish, I could not see why it is not possible. Regards, Jane -----Original Message----- From: wiseguy@cs.stanford.edu [mailto:wiseguy@cs.stanford.edu] Sent: Tuesday, July 17, 2001 12:06 PM To: mpls@UU.NET Subject: [MPLS] Popping Multiple Labels Hi, I was wondering if there are any possible scenarios in which a node might pop multiple labels from the stack. One case I was thinking of is : a node is endpoint of a tunnel (T1) and is also a penultimate hop for another tunnel (T2) and T2 is tunneled over T1! Maybe this is not a valid scenario but I would like to check. I appreciate any help. thanks, manish PS: Scenario +-----+ +-------+ +-------+ +------+ | | ===~== | | ====~~=== | +---------+ | | L1 | | L21 | | L2n | | L3 | +-----+ +-------+ +-------+ +------+ <------------ T1 --------------> <--------------------------T2----------------------> From owner-mpls@UU.NET Tue Jul 17 16:37:38 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 QAA08017 for ; Tue, 17 Jul 2001 16:37: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 QQkyco02130; Tue, 17 Jul 2001 20:36:58 GMT Received: by mail-control.mail.uu.net id QQkyco16825 for mpls-outgoing; Tue, 17 Jul 2001 20:36: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 QQkyco16785 for ; Tue, 17 Jul 2001 20:36:12 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 QQkycn20684 for ; Tue, 17 Jul 2001 20:28:45 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 QQkycn24472 for ; Tue, 17 Jul 2001 20:28:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA16288 for mpls@uu.net; Tue, 17 Jul 2001 16:28:45 -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 QQkyck20139 for ; Tue, 17 Jul 2001 19:36:24 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 QQkyck08425 for ; Tue, 17 Jul 2001 19:36:01 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 QQkyck20349 for ; Tue, 17 Jul 2001 19:36:01 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 PAA00827; Tue, 17 Jul 2001 15:36:00 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225]) by bucket.cisco.com (Mirapoint) with ESMTP id ADR03969; Tue, 17 Jul 2001 15:35:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20010717153802.02d0cbc0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jul 2001 15:40:47 -0400 To: Dipak , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: One simple question In-Reply-To: <3B547F4C.FD923F53@monmouth.com> References: <006a01c10ed7$40765960$753ad93f@gemplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Assuming that the MPLS-TE-MIB has been implemented by the vendor in question, you can query for any of the scalars in the MIB. If they are returned, you know that the MIB and thus RSVP-TE is supported. The MIB can be found here: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt Another means of telling this without doing the query, is to look at the vendor's agent capabilities statement for the MPLS-TE-MIB. It will tell you if the MIB has been implemented. --Tom > Can anybody suggest someway that a network manager (say, SNMP >manager) can discover that any MPLS enabled router in its network has >RSVP-TE implemented for establishing LSP tunnel? > >Thanks, >dipak From owner-mpls@UU.NET Tue Jul 17 17:03: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 RAA13519 for ; Tue, 17 Jul 2001 17:03: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 QQkycq00984; Tue, 17 Jul 2001 21:02:41 GMT Received: by mail-control.mail.uu.net id QQkycq24222 for mpls-outgoing; Tue, 17 Jul 2001 21:02:09 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 QQkycq23987 for ; Tue, 17 Jul 2001 21:01:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkycp28867 for ; Tue, 17 Jul 2001 20:56:46 GMT Received: from smtp.monmouth.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.monmouth.com [209.191.58.6]) id QQkycp24518 for ; Tue, 17 Jul 2001 20:56:45 GMT Received: from monmouth.com ([64.19.191.1]) by smtp.monmouth.com (8.11.4/8.11.4) with ESMTP id f6HKugM66871; Tue, 17 Jul 2001 16:56:42 -0400 (EDT) Message-ID: <3B549889.8463D85@monmouth.com> Date: Tue, 17 Jul 2001 15:56:57 -0400 From: Dipak X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: mpls@UU.NET Subject: Re: One simple question References: <006a01c10ed7$40765960$753ad93f@gemplex.com> <4.3.2.7.2.20010717153802.02d0cbc0@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit How can you be sure that if MPLS-TE-MIB is existing then RSVP-TE is supported? It can only be CR-LDP to signal the LSP tunnel establishment. Isn't it? Dipak "Thomas D. Nadeau" wrote: > Assuming that the MPLS-TE-MIB > has been implemented by the vendor in question, > you can query for any of the scalars in the > MIB. If they are returned, you know that the > MIB and thus RSVP-TE is supported. The MIB > can be found here: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt > > Another means of telling this without doing > the query, is to look at the vendor's > agent capabilities statement for the MPLS-TE-MIB. > It will tell you if the MIB has been implemented. > > --Tom > > > Can anybody suggest someway that a network manager (say, SNMP > >manager) can discover that any MPLS enabled router in its network has > >RSVP-TE implemented for establishing LSP tunnel? > > > >Thanks, > >dipak From owner-mpls@UU.NET Tue Jul 17 17:04: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 RAA13890 for ; Tue, 17 Jul 2001 17:04: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 QQkycq06183; Tue, 17 Jul 2001 21:04:36 GMT Received: by mail-control.mail.uu.net id QQkycq00310 for mpls-outgoing; Tue, 17 Jul 2001 21:03: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 QQkycq00241 for ; Tue, 17 Jul 2001 21:03: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 QQkycq08137 for ; Tue, 17 Jul 2001 21:03:13 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkycq01730 for ; Tue, 17 Jul 2001 21:03:13 GMT Message-ID: <3B54A80F.2CBEBEFD@sandburst.com> Date: Tue, 17 Jul 2001 17:03:11 -0400 From: Eric Gray MIME-Version: 1.0 To: erosen@cisco.com Cc: Shahram Davari , "'mpLS@UU.net'" Subject: Re: LSP-ping References: <200107171954.PAA03335@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, The thrust of Shahram's proposal is that the egress LSR would normally be pinging the ingress LSR. This was why I asked him if there wasn't a better approach than using ping as an alive protocol. =================================================== Shahram, As I understand it (based in part on the partial dialog between Ping Pan and George Swallow), Ping's proposal is not an attempt to use LSP ping as an alive protocol, but rather an additional tool to use when normal ping is not working. If I am mis-representing the dialog, I offer my apologies, but - if this is in fact what is proposed - it at least has this advantage over your proposal. -- Eric Gray You wrote: > Shahram> My suggestion is different. The ingress LSR checks the connectivity > Shahram> status of the reverse LSP, by checking to see whether it is > Shahram> receiving ICMP-pings from the egress LSR. If it is, then the > Shahram> reverse LSP is fine, and any failure to receive ICMP-Echo from the > Shahram> egress LSR is due to forward LSP. > > Presumably, the egress LSR is not normally pinging the ingress LSR, so I'm > not sure just what you mean. (If all LSP egresses are constantly pinging > all LSP ingresses, then I think we have a scaling problem.) > > If the problem one is investigating is that there appear to be data packets > that reach the LSP ingress but get lost before they reach the LSP egress, I > don't think one wants a diagnostic tool that depends on one's being able to > explicitly control the egress. So telling the egress to ping the ingress > (and then monitoring the ingress to see if the pings are received) doesn't > seem like the best strategy. From owner-mpls@UU.NET Tue Jul 17 17:14:16 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 RAA15968 for ; Tue, 17 Jul 2001 17:14:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkycq17588; Tue, 17 Jul 2001 21:13:49 GMT Received: by mail-control.mail.uu.net id QQkycq10105 for mpls-outgoing; Tue, 17 Jul 2001 21:13: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 QQkycq10097 for ; Tue, 17 Jul 2001 21:13: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 QQkycq19836 for ; Tue, 17 Jul 2001 21:11:48 GMT Received: from thalia.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQkycq15097 for ; Tue, 17 Jul 2001 21:11:47 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA11023; Tue, 17 Jul 2001 21:11:37 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 17 Jul 2001 21:11:37 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3ZBJ2HHZ>; Tue, 17 Jul 2001 14:11:36 -0700 Message-ID: From: "Feng, Mark" To: "'Khuzema Pithewan'" , mpls@UU.NET Subject: RE: Session Attributes Date: Tue, 17 Jul 2001 14:11:35 -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 I think the name Session Attribute is a misnomer. IMO, the attributes apply to a particular LSP. Where to keep it is implementation dependent. PSB seems to be a logical place. - Mark > -----Original Message----- > From: Khuzema Pithewan [mailto:khuzema@netbrahma.com] > Sent: Monday, July 16, 2001 3:07 AM > To: mpls@UU.NET > Subject: Session Attributes > > > Hi, > > Session Attribute Object in RSVP-TE contains some flags , setup and > holding priority and some session related info. My doubt is , if this > object is per session or per LSP, because name suggest that it is per > session, but holding/setup priorities are the attributes of a LSP. so > basically where to keep this Object,?? in PSB or Session??? > > Khuzema. > > > > From owner-mpls@UU.NET Tue Jul 17 17:22: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 RAA17343 for ; Tue, 17 Jul 2001 17:22: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 QQkycr24275; Tue, 17 Jul 2001 21:22:01 GMT Received: by mail-control.mail.uu.net id QQkycr11218 for mpls-outgoing; Tue, 17 Jul 2001 21:21: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 QQkycr11154 for ; Tue, 17 Jul 2001 21:21: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 QQkycr07993 for ; Tue, 17 Jul 2001 21:21:03 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 QQkycr23012 for ; Tue, 17 Jul 2001 21:21:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA22125 for mpls@uu.net; Tue, 17 Jul 2001 17:21:02 -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 QQkycr11022 for ; Tue, 17 Jul 2001 21:20:12 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 QQkycr00204 for ; Tue, 17 Jul 2001 21:19:54 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkycr21511 for ; Tue, 17 Jul 2001 21:19:54 GMT Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HLJqH68517; Tue, 17 Jul 2001 14:19:52 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B54ABF8.854B0983@juniper.net> Date: Tue, 17 Jul 2001 14:19:52 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Punj, Arun" CC: mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <4FBEA8857476D311A03300204840E1CF01B0BCA4@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 "Punj, Arun" wrote: > > > > > What prevents a packet with a router alert flag set from > > being sent over an > > LSP? I don't recall anything in the specs that specifies > > router alter packets > > can't be LSP'd. > > > Eric Rosen wrote: > > > > > George> The mechanism is intentionally tied to the control > > plane to ensure > > > George> that the source is properly informed even if the > > reverse data path > > > George> may be broken. > > > > > > If the reply is encapsulated in a UDP packet which is > > addressed to the > > > tunnel head and has router alert set, isn't this just as > > effective, without > > > the dependence on the control plane? > > > > Interesting.. Should it not be in the spec? If not, than > are you not changing the meaning of router alert. If yes, > Eric's solution seems perfectly OK, although it would > require some sort of additional support on the intermediate > nodes. > Arun, In fact, this idea of using IP Router Alert option had been discussed extensively before the submission of the LSP-ping draft. The problem with this approach is: there is no guarantee that the returning path (with or without IP Router Alert) won't go over an LSP. If that LSP is bad, we are in trouble. > Presumably router alert is the reason why the RSVP messages > are finding the way back in reverse direction!! > No. RSVP messages find the way back in reverse based on PHOP installed at each LSR by RSVP Path, and has nothing to do with IP Router Alert. - Ping From owner-mpls@UU.NET Tue Jul 17 18:11: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 SAA25738 for ; Tue, 17 Jul 2001 18:11: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 QQkych08525; Tue, 17 Jul 2001 18:51:19 GMT Received: by mail-control.mail.uu.net id QQkych23889 for mpls-outgoing; Tue, 17 Jul 2001 18:50:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkych23855 for ; Tue, 17 Jul 2001 18:50:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkych04141 for ; Tue, 17 Jul 2001 18:48:21 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkych05700 for ; Tue, 17 Jul 2001 18:48:21 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18631; Tue, 17 Jul 2001 14:47:34 -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 OAA02575; Tue, 17 Jul 2001 14:47:35 -0400 (EDT) Message-ID: <3B54884D.ED67276B@marconi.com> Date: Tue, 17 Jul 2001 14:47:41 -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: Rajesh P Jain CC: mpls@UU.NET, abhay , Madhu Babu Brahmanapally , "'Feng, Mark'" Subject: Re: Some Doubts References: <00d801c10e28$420614a0$c500a8c0@MBRAHMANAPALLY> <3B53BC09.8CA5ECB8@multitech.co.in> <3B53CCFD.7644B3A9@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 respect to the discussion, I would like to > ask the following question. > > In the diagram below, Let us consider that MPLS domain is from R3 > to R7 > > Sender---R1---R2---R3---R4---R5---R6---R7---R8---Receiver > > In the routers R3 to R7, RSVP-TE is supported in the > MPLS domain. In the routers R1,R2 and R8, RSVP is suppported but not > MPLS. > > Now, The Sender sends a Path message towards the > receiver along the path R1 to R8. R8 will reject the Path message, because it will include a LABEL_REQUEST object, which a non-MPLS router will not be able to process. It will probably also reject the SESSION object, since a non-MPLS router won't understand the MPLS-specific C-Type of LSP_TUNNEL_IPv4 > > Will the router R3 (the first MPLS node on the path -- > that is, the sender node with respect to the path -- creates an RSVP > Path message with a session type of LSP_TUNNEL_IPv4 or > LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path > message. - Section 2.2 - Operation od LSP tunnel in the Draft of > RSVP extension for LSP tunnel) insert the LABEL Request Object???? > > Is it possible to establish the LSP tunnel in the > MPLS domain (R3 to R7) or should all the nodes (i.e R1, R2 and R8 > also) along the path from Sender to Receiver support MPLS ?? Sender and receiver, as far as RSVP-TE are concerned, refer to the endpoints of the LSP. Sender will be R3, and receiver will be R7, since that is the extent of MPLS. Any attempt to signal the LSP beyond the edge of the MPLS cloud will fail. -- David From owner-mpls@UU.NET Tue Jul 17 18:33: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 SAA29210 for ; Tue, 17 Jul 2001 18:33: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 QQkycw24035; Tue, 17 Jul 2001 22:32:56 GMT Received: by mail-control.mail.uu.net id QQkycw07045 for mpls-outgoing; Tue, 17 Jul 2001 22:32: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 QQkycw07027 for ; Tue, 17 Jul 2001 22:32: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 QQkycv18971 for ; Tue, 17 Jul 2001 22:20:30 GMT Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged)) id QQkycv24082 for ; Tue, 17 Jul 2001 22:20:30 GMT Received: from BLIULAPTOP ([172.16.24.62]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 17 Jul 2001 18:15:14 -0400 Message-ID: <014c01c10f0e$1cd05a60$65c4893e@movaz.com> From: "Adrian Farrel" To: "Dipak" , "Thomas D. Nadeau" Cc: References: <006a01c10ed7$40765960$753ad93f@gemplex.com> <4.3.2.7.2.20010717153802.02d0cbc0@bucket.cisco.com> <3B549889.8463D85@monmouth.com> Subject: Re: One simple question Date: Tue, 17 Jul 2001 18:16:10 -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: 17 Jul 2001 22:15:15.0445 (UTC) FILETIME=[F4854250:01C10F0D] Sender: owner-mpls@UU.NET Precedence: bulk Dipak, you're quite right. There is no scalar in the TE-MIB to state whether the LSR (LER :-) supports RSVP-TE, CR-LDP or both. Notwithstanding this, of course, an LER might support your chosen signaling protocol but fail to connect with any other LSR that supports it. You are probably best off trying to instantiate a tunnel setting mplsTunnelSignallingProto to rsvp(2) or crldp(3). As you set this field you would expect to see an error from an LER that doesn't support the signaling protocol. NB: If we were to introduce such a scalar, it might be better placed in the LSR MIB. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Dipak" To: "Thomas D. Nadeau" Cc: Sent: Tuesday, July 17, 2001 3:56 PM Subject: Re: One simple question > How can you be sure that if MPLS-TE-MIB is existing then RSVP-TE is > supported? It can only be CR-LDP to signal the LSP tunnel establishment. > Isn't it? > > Dipak > > "Thomas D. Nadeau" wrote: > > > Assuming that the MPLS-TE-MIB > > has been implemented by the vendor in question, > > you can query for any of the scalars in the > > MIB. If they are returned, you know that the > > MIB and thus RSVP-TE is supported. The MIB > > can be found here: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt > > > > Another means of telling this without doing > > the query, is to look at the vendor's > > agent capabilities statement for the MPLS-TE-MIB. > > It will tell you if the MIB has been implemented. > > > > --Tom > > > > > Can anybody suggest someway that a network manager (say, SNMP > > >manager) can discover that any MPLS enabled router in its network has > > >RSVP-TE implemented for establishing LSP tunnel? > > > > > >Thanks, > > >dipak > From owner-mpls@UU.NET Tue Jul 17 18:59: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 SAA05001 for ; Tue, 17 Jul 2001 18:59: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 QQkycx24227; Tue, 17 Jul 2001 22:59:46 GMT Received: by mail-control.mail.uu.net id QQkycx08492 for mpls-outgoing; Tue, 17 Jul 2001 22:59: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 QQkycx08483 for ; Tue, 17 Jul 2001 22:59: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 QQkycx15568 for ; Tue, 17 Jul 2001 22:58:50 GMT Received: from saga18.Stanford.EDU by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saga18.Stanford.EDU [171.64.15.148]) id QQkycx23178 for ; Tue, 17 Jul 2001 22:58:50 GMT Received: (from manish1@localhost) by saga18.Stanford.EDU (8.11.3/8.11.3) id f6HMwlR12400; Tue, 17 Jul 2001 15:58:47 -0700 (PDT) Date: Tue, 17 Jul 2001 15:58:47 -0700 (PDT) From: Manish Godara To: "Jiang, Donghua (Donghua)" cc: "'mpls@uu.net'" Subject: RE: [MPLS] Popping Multiple Labels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thanks Jane. Also, I think the BGP/MPLS VPNs may need to pop two labels at the PE router if the penultimate hop is not popping the top label, right? thanks, manish On Tue, 17 Jul 2001, Jiang, Donghua (Donghua) wrote: > > Manish, > > I could not see why it is not possible. > > Regards, > Jane > -----Original Message----- > From: wiseguy@cs.stanford.edu [mailto:wiseguy@cs.stanford.edu] > Sent: Tuesday, July 17, 2001 12:06 PM > To: mpls@UU.NET > Subject: [MPLS] Popping Multiple Labels > > > > Hi, > > I was wondering if there are any possible scenarios in which > a node might pop multiple labels from the stack. One case > I was thinking of is : a node is endpoint of a tunnel (T1) and > is also a penultimate hop for another tunnel (T2) and T2 is > tunneled over T1! Maybe this is not a valid scenario but I > would like to check. > > I appreciate any help. > > thanks, > manish > > PS: Scenario > > > +-----+ +-------+ +-------+ +------+ > | | ===~== | | ====~~=== | +---------+ | > | L1 | | L21 | | L2n | | L3 | > +-----+ +-------+ +-------+ +------+ > > <------------ T1 --------------> > <--------------------------T2----------------------> > > From owner-mpls@UU.NET Tue Jul 17 19:47: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 TAA14026 for ; Tue, 17 Jul 2001 19:47: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 QQkydb19937; Tue, 17 Jul 2001 23:47:11 GMT Received: by mail-control.mail.uu.net id QQkydb02332 for mpls-outgoing; Tue, 17 Jul 2001 23:46: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 QQkydb02255 for ; Tue, 17 Jul 2001 23:46:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkydb26007 for ; Tue, 17 Jul 2001 23:46:01 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 QQkydb04284 for ; Tue, 17 Jul 2001 23:46:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA14867 for ; Tue, 17 Jul 2001 19:45:53 -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 TAA17829 for ; Tue, 17 Jul 2001 19:45:56 -0400 (EDT) Message-ID: <3B54CE3A.F0E75234@marconi.com> Date: Tue, 17 Jul 2001 19:46:02 -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-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <4FBEA8857476D311A03300204840E1CF01B0BCA4@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 Punj, Arun wrote: > Matt Squire wrote: >> >> What prevents a packet with a router alert flag set from being >> sent over an LSP? I don't recall anything in the specs that >> specifies router alter packets can't be LSP'd. > > Interesting.. Should it not be in the spec? If not, than are you > not changing the meaning of router alert. If yes, Eric's solution > seems perfectly OK, although it would require some sort of > additional support on the intermediate nodes. Logically, it would not make sense to forward a router-alerted packet into an LSP. The purpose of router alert is so that intermediate nodes will closely examine the packet, and possibly intercept it for processing. The purpose of an LSP is to quickly forward a packet with a minimum of processing by the transit routers. These are two diametrically opposed goals. Nevertheless, I don't think there is anything forbidding a router from sending a router-alert packet into an LSP. > Presumably router alert is the reason why the RSVP messages > are finding the way back in reverse direction!! RSVP Resv messages are targetted at the PHOP router, so even if they would be sent into an LSP, they'd still arrive at the same place. Forward-going messages (Path, PathTear, ResvErr and ResvConf) are sent with router alert and have the egress router's address in the IP header. In theory, they could be forwarded into an LSP, but any router doing this wouldn't be able to process the messages and would therefore not be a useful participant in the signaling process. (Unless that LSP terminates at the next-hop router.) -- David From owner-mpls@UU.NET Tue Jul 17 19:58: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 TAA15865 for ; Tue, 17 Jul 2001 19:58: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 QQkydb12642; Tue, 17 Jul 2001 23:56:58 GMT Received: by mail-control.mail.uu.net id QQkydb03204 for mpls-outgoing; Tue, 17 Jul 2001 23:56: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 QQkydb03166 for ; Tue, 17 Jul 2001 23:56: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 QQkydb12574 for ; Tue, 17 Jul 2001 23:55:53 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQkydb00039 for ; Tue, 17 Jul 2001 23:55:53 GMT Received: from aatlas-pc (aatlas-pc.avici.com [10.2.20.92]) by mailhost.avici.com (8.11.0/8.11.0) with SMTP id f6HNsMs21651; Tue, 17 Jul 2001 19:54:22 -0400 (EDT) Message-Id: <4.1.20010717194844.00ace210@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 17 Jul 2001 19:51:49 -0500 To: David Charlap From: Alia Atlas Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Cc: mpls-list In-Reply-To: <3B54CE3A.F0E75234@marconi.com> References: <4FBEA8857476D311A03300204840E1CF01B0BCA4@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 07:46 PM 7/17/01 -0400, David Charlap wrote: >RSVP Resv messages are targetted at the PHOP router, so even if they >would be sent into an LSP, they'd still arrive at the same place. > >Forward-going messages (Path, PathTear, ResvErr and ResvConf) are sent >with router alert and have the egress router's address in the IP >header. In theory, they could be forwarded into an LSP, but any router >doing this wouldn't be able to process the messages and would therefore >not be a useful participant in the signaling process. (Unless that LSP >terminates at the next-hop router.) It can actually be useful if you want two LSRs connected by an LSP to be logical neighbors. This comes up if one is using heirarchical tunnels. For instance, consider how you would signal a backup LSP through a bypass tunnel, if the merge node's label weren't recorded... Alia From owner-mpls@UU.NET Tue Jul 17 20:00: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 UAA16332 for ; Tue, 17 Jul 2001 20:00: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 QQkydb14826; Tue, 17 Jul 2001 23:59:06 GMT Received: by mail-control.mail.uu.net id QQkydb03334 for mpls-outgoing; Tue, 17 Jul 2001 23:58: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 QQkydb03322 for ; Tue, 17 Jul 2001 23:58:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkydb15289 for ; Tue, 17 Jul 2001 23:58:13 GMT Received: from squid.squirehome.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu163-42-132.nc.rr.com [24.163.42.132]) id QQkydb14039 for ; Tue, 17 Jul 2001 23:58:13 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6HNwBt01613; Tue, 17 Jul 2001 19:58:12 -0400 Message-ID: <3B54D113.72B2119@acm.org> Date: Tue, 17 Jul 2001 19:58:11 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: David Charlap CC: mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <4FBEA8857476D311A03300204840E1CF01B0BCA4@whq-msgusr-02.pit.comms.marconi.com> <3B54CE3A.F0E75234@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David Charlap wrote: > > Punj, Arun wrote: > > Matt Squire wrote: > >> > >> What prevents a packet with a router alert flag set from being > >> sent over an LSP? I don't recall anything in the specs that > >> specifies router alter packets can't be LSP'd. > > > > Interesting.. Should it not be in the spec? If not, than are you > > not changing the meaning of router alert. If yes, Eric's solution > > seems perfectly OK, although it would require some sort of > > additional support on the intermediate nodes. > > Logically, it would not make sense to forward a router-alerted packet > into an LSP. > > The purpose of router alert is so that intermediate nodes will closely > examine the packet, and possibly intercept it for processing. The > purpose of an LSP is to quickly forward a packet with a minimum of > processing by the transit routers. These are two diametrically opposed > goals. > > Nevertheless, I don't think there is anything forbidding a router from > sending a router-alert packet into an LSP. > LSPs can be used to provide L2 VPN connectivity. LSPs can be used to provide virtual p2p connections between two virtual routers. LSRs might not even be L3 forwarders. When used in such ways, it is conceivable and probably desired that router alert messages be sent down LSP as the LSP is not spanning multiple L3 routers from the perspective of the ingress - the LSP is just a single hop. Strictly outlawing router alert messages from LSPs would not be a desirable end goal. - Matt From owner-mpls@UU.NET Tue Jul 17 20:21: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 SMTP id UAA21874 for ; Tue, 17 Jul 2001 20:21: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 QQkycq24907; Tue, 17 Jul 2001 21:09:59 GMT Received: by mail-control.mail.uu.net id QQkycq09548 for mpls-outgoing; Tue, 17 Jul 2001 21:09:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkycq09527 for ; Tue, 17 Jul 2001 21:09:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkycq14314 for ; Tue, 17 Jul 2001 21:07:40 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 QQkycq10164 for ; Tue, 17 Jul 2001 21:07:39 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 RAA05222; Tue, 17 Jul 2001 17:07:37 -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 RAA23191; Tue, 17 Jul 2001 17:07:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Jul 2001 17:07:38 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01B0BCA4@whq-msgusr-02.pit.comms.marconi.com> From: "Punj, Arun" To: "'Matt Squire'" , erosen@cisco.com, "'neil.2.harrison@bt.com'" Cc: George Swallow , mpls-list Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Date: Tue, 17 Jul 2001 17:07:35 -0400 X-MS-TNEF-Correlator: <4FBEA8857476D311A03300204840E1CF01B0BCA4@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10F04.80A72CD0" 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_01C10F04.80A72CD0 Content-Type: text/plain; charset="iso-8859-1" Eric and Matt, > -----Original Message----- > From: Matt Squire [mailto:mattsquire@acm.org] > Sent: Thursday, July 12, 2001 11:28 AM > To: erosen@cisco.com > Cc: George Swallow; Ron Bonica; mpls-list > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] > > > > What prevents a packet with a router alert flag set from > being sent over an > LSP? I don't recall anything in the specs that specifies > router alter packets > can't be LSP'd. > Eric Rosen wrote: > > > George> The mechanism is intentionally tied to the control > plane to ensure > > George> that the source is properly informed even if the > reverse data path > > George> may be broken. > > > > If the reply is encapsulated in a UDP packet which is > addressed to the > > tunnel head and has router alert set, isn't this just as > effective, without > > the dependence on the control plane? > Interesting.. Should it not be in the spec? If not, than are you not changing the meaning of router alert. If yes, Eric's solution seems perfectly OK, although it would require some sort of additional support on the intermediate nodes. Presumably router alert is the reason why the RSVP messages are finding the way back in reverse direction!! However, either way, this technique seems to be a hack. The right solution is to implement the complete OAM functionaliy as Neil as pointed out. Arun Punj Office of CTO, Marconi Networks, Ph : 724-742-7583 - Web: www.marconi.com 1000 Fore Drive, Warrandale, PA - 15086 ------_=_NextPart_000_01C10F04.80A72CD0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IicVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcHABEAEQAHACMAAgAtAQEggAMADgAAANEHBwAR ABEABwAmAAIAMAEBCYABACEAAAAwMjA2MDE5MEQxN0FENTExQTA1QTAwMjA0ODQwRTFDRgDSBgEE gAEAMAAAAFJFOiBbRndkOiBJLUQgQUNUSU9OOmRyYWZ0LXBhbi1sc3AtcGluZy0wMC50eHRdAOUO AQ2ABAACAAAAAgACAAEDkAYABAsAADMAAAADAAlZAQAAAAMA3j+vbwAAAwAAgAggBgAAAAAAwAAA AAAAAEYAAAAAUoUAACdqAQAeAAGACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAA CwACgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAB hQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAFgAggBgAAAAAAwAAAAAAA AEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAA AMAAAAAAAABGAAAAABGFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAmA CCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYA AAAAN4UAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAA AAACAQkQAQAAAD0FAAA5BQAA7AcAAExaRnUheJaGAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqA AqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3 tjsYHw4wNREiDGBjAFDzCwkBZDM2FlALpgrjCoSlCoBFBRBjIABwZAXQimECQCwc6z4gLR+Cek8F EGcLgAdABdAHkHNYYWdlH4MfBkYDYTojHjMGAHF1aRggIFtjAMADEHRvOgDAAkBzJSJjQADQbS4F sGddTx8GBmACMCHgVGgIcHMIZGF5HoBKdWx5TiAOIB6AAdAwMSYwMag6MjgQwE0fBlQjIIogBJBv FBBuQGMEAJUFoC4FoG0fBkNjIeDMR2UkMSKgU3cHQBewtxLQB/EDoEICIA3gYSqwom0LUHMtbAQA dCR3mHViagWQJSFSZSHgEFtGd2Qh4EktRAEQwENUSU9OOmRUcmEBgC0KsG4r0HOmcC7QC4BnLSaQ LgzQbnQkZzAvHxVXE+AFQHBtGCB2JQEEIGEyYADQa2UUICAD8HRoMvEDYHVfDrAFwAdABJAFQGYL YGeeIBQRNMADYTEXYmUvcfM1EQIwIG8yoDRRC5AfFSBMU1A/IC3AIGR9AiAnBUAYICtQKnAd8Xn3 M7A2UguAIDOwIqAvMAWQ/wQgM7AyQToiBpAIkAQhHxX3NAc0MjMkcx8GK1A4cjYw8TfCJ2QuHqwd swgAKEH3M4ADYA6wOjCuH2Ap1Cex7znxB4AT0QMAczWQBAA4EPcLgA6wAjBpAiAqYSYgQ6D7CYA5 0G850wWgAjADYAMhdx8VMmALYG4ioESBCfBzvQhwZUEfOnQ54whhYyKg60MCMnBvOjByJhELgAIQ 3nIHgB4gMpI5oGY4EDni/zt3MpEUAThAHlAzAjOwRv+3K4AlsD4CYgNgM1BuPpX7QXFM2ElK1Rgg C1BJwUMh+wnwK1BwRrALYA6wHiA5sfEy8VVEUEXhMzU5YBPQ80kDHwZhZC6AIHFEUUR18UzYdHVu RjADIDnwVDD/HfMT4AQgNAs1Eh6ABAA4cvM5UQQganUsAB3wO1gBEf0s4WkyoB6AM5I0EVVJOfH/ AQA6MB4QUSEioCrhRLpGA/Y/MKwc9ElDYVRhQ6AvgGwuLgYAWuFsUdEFQG7/QFA+Ajm5OABQAWDB HoA6gfc3RQrAIqB5CGBgs0KSIAHfNQA54geAQrE2YW9K0DQKq2AAUAF5B5AsHVgnBCDPSKAKQEOi NRFlbUkxBJBzWiImEU9LHoA8YVrhZ/szwGCRd2BDHPQYICJkSKD/B4BIkTShZTFUMTOgQ7M1EPh1 cHBrsznEQ1JKIgcwrw6wHPRgwAEAcz6bUFRh/nUAwAJgJiA0C0MRUERW8I8q4VMQRBE58VJTVlJw /weBIJI9JWMiOyAeEGQ2KlB/ThEzMTmiS8cigVpBAiAh+iEc+kgqkEvSHoA2QDnh/wXAdRFiYnGC QoEDACJgOgH/aCNEgT4RMwAT4DNAYABCMvtqdR/waDqxZ5ZxgkSQB3D/C1BoMDaiRLR9Qg6waQAn MM80wFXwdpMHQGl5YsUHov8DEVbxbQBDUh4gNBE+mxz0UwcQVfAgUFXwahz0T98BIA3gXJFK0C4g Tx6AHkCXSNArIQexdGoQcmtmlg5QU1Eh4AHANC03NGIyhnA1ODMfcDIQZepiIeB3h4AuAMCEkyjY tjEmkBZQRgWwIqBEBRB9WnJXCsAukB4QNHEegFCCQYcBMTUwODYc9AJ9i7AAAAAeAHAAAQAAACwA AABbRndkOiBJLUQgQUNUSU9OOmRyYWZ0LXBhbi1sc3AtcGluZy0wMC50eHRdAAIBcQABAAAAGwAA AAHBCuuvu0av5CV23RHVqZ8AIEhAM5UBBPFA8AADAC4AAAAAAAsAAgABAAAAHgBCEAEAAAAcAAAA PDNCNERDMUY5LjdCMDM1RUE4QGFjbS5vcmc+AAMA/T/kBAAAQAA5ANAsp4AED8EBAwDxPwkEAAAe ADFAAQAAAAYAAABBUFVOSgAAAAMAGkAAAAAAHgAwQAEAAAAGAAAAQVBVTkoAAAADABlAAAAAAAMA JgAAAAAAAwA2AAAAAAADAIAQ/////wsA8hABAAAAAgFHAAEAAAA0AAAAYz1VUzthPSA7cD1FTUFJ TDtsPVdIUS1NU0dVU1ItMDItMDEwNzE3MjEwNzM1Wi03NTMwAAIB+T8BAAAAQwAAAAAAAADcp0DI wEIQGrS5CAArL+GCAQAAAAAAAAAvTz1FTUFJTC9PVT1OQTEvQ049UkVDSVBJRU5UUy9DTj1BUFVO SgAAHgD4PwEAAAALAAAAUHVuaiwgQXJ1bgAAHgA4QAEAAAAGAAAAQVBVTkoAAAACAfs/AQAAAEMA AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RU1BSUwvT1U9TkExL0NOPVJFQ0lQSUVO VFMvQ049QVBVTkoAAB4A+j8BAAAACwAAAFB1bmosIEFydW4AAB4AOUABAAAABgAAAEFQVU5KAAAA QAAHMKQKoIAED8EBQAAIMIQZRoIED8EBHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAACwAAABb RndkOiBJLUQgQUNUSU9OOmRyYWZ0LXBhbi1sc3AtcGluZy0wMC50eHRdAB4ANRABAAAATwAAADw0 RkJFQTg4NTc0NzZEMzExQTAzMzAwMjA0ODQwRTFDRjAxQjBCQ0E0QHdocS1tc2d1c3ItMDIucGl0 LmNvbW1zLm1hcmNvbmkuY29tPgAACwApAAAAAAALACMAAAAAAAMABhCQnl86AwAHEH4EAAADABAQ AAAAAAMAERAAAAAAHgAIEAEAAABlAAAARVJJQ0FORE1BVFQsLS0tLS1PUklHSU5BTE1FU1NBR0Ut LS0tLUZST006TUFUVFNRVUlSRU1BSUxUTzpNQVRUU1FVSVJFQEFDTU9SR1NFTlQ6VEhVUlNEQVks SlVMWTEyLDIwMAAAAAACAX8AAQAAAE8AAAA8NEZCRUE4ODU3NDc2RDMxMUEwMzMwMDIwNDg0MEUx Q0YwMUIwQkNBNEB3aHEtbXNndXNyLTAyLnBpdC5jb21tcy5tYXJjb25pLmNvbT4AALCx ------_=_NextPart_000_01C10F04.80A72CD0-- From owner-mpls@UU.NET Tue Jul 17 21:06: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 VAA02163 for ; Tue, 17 Jul 2001 21:06: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 QQkych20696; Tue, 17 Jul 2001 18:46:47 GMT Received: by mail-control.mail.uu.net id QQkych23370 for mpls-outgoing; Tue, 17 Jul 2001 18:46: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 QQkych23293 for ; Tue, 17 Jul 2001 18:45: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 QQkych01798 for ; Tue, 17 Jul 2001 18:45:14 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 QQkych02984 for ; Tue, 17 Jul 2001 18:45:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA00053 for mpls@uu.net; Tue, 17 Jul 2001 14:45:13 -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 QQkycg22936 for ; Tue, 17 Jul 2001 18:43: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 QQkycg25611 for ; Tue, 17 Jul 2001 18:40:31 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 QQkycg13197 for ; Tue, 17 Jul 2001 18:40:31 GMT Received: (qmail 25447 invoked by uid 104); 17 Jul 2001 18:40:30 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.487876 secs); 17/07/2001 11:40:30 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 17 Jul 2001 18:40:30 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6HIeXP21181 for ; Tue, 17 Jul 2001 11:40:33 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 11:46:05 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D83@BBY1EXM01> From: Shahram Davari To: "'mpLS@UU.net'" Subject: LSP-ping Date: Tue, 17 Jul 2001 11:46:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10EF0.BBC36810" 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_01C10EF0.BBC36810 Content-Type: text/plain; charset="iso-8859-1" Hi, Could anybody explain to me what is wrong with running ICMP-ping over the both the forward and reverse LSP? This method has a number of advantages over using LSP-ping in combination with RESV message: 1) Is more generic: Can be applied to all types of LSPs; RSVP-TE LSPs, CR-LDP LSPs and static configured LSPs. 2) Can have quicker response time than RSVP, and is independent of RSVP timers. 3) Does not need a new protocol: LSP-ping. Yours, -Shahram ------_=_NextPart_000_01C10EF0.BBC36810 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C10EF0.BBC36810-- From owner-mpls@UU.NET Wed Jul 18 04:43: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 EAA00168 for ; Wed, 18 Jul 2001 04:43: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 QQkyek15841; Wed, 18 Jul 2001 08:42:58 GMT Received: by mail-control.mail.uu.net id QQkyek12249 for mpls-outgoing; Wed, 18 Jul 2001 08:42: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 QQkyek12234 for ; Wed, 18 Jul 2001 08:42:05 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 QQkyek29846 for ; Wed, 18 Jul 2001 08:41:01 GMT Received: from web13701.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13701.mail.yahoo.com [216.136.175.134]) id QQkyek14570 for ; Wed, 18 Jul 2001 08:41:00 GMT Message-ID: <20010718084100.41284.qmail@web13701.mail.yahoo.com> Received: from [210.212.215.129] by web13701.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 01:41:00 PDT Date: Wed, 18 Jul 2001 01:41:00 -0700 (PDT) From: siva Reddy Subject: doubt about implecit NULL label To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Dear all, when we use implecit NULL (label valu 3) the penultimate HOP has to pop the label insted of replacing(swapping).afterwards it will be simply IP packet only.can penultimate HOP forward the IP packet to LSR. please clarify me about this implecit NULL concept. thanks in adv. regards lonka __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 04:55: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 SMTP id EAA01554 for ; Wed, 18 Jul 2001 04:55: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 QQkyel02522; Wed, 18 Jul 2001 08:55:09 GMT Received: by mail-control.mail.uu.net id QQkyel13313 for mpls-outgoing; Wed, 18 Jul 2001 08:54: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 QQkyel13305 for ; Wed, 18 Jul 2001 08:54: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 QQkyel13805 for ; Wed, 18 Jul 2001 08:53:56 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQkyel24511 for ; Wed, 18 Jul 2001 08:53:56 GMT Received: by SANMIGUEL with Internet Mail Service (5.5.2448.0) id ; Wed, 18 Jul 2001 10:50:58 +0200 Message-ID: From: Javier Antich To: siva Reddy , mpls@UU.NET Subject: RE: doubt about implecit NULL label Date: Wed, 18 Jul 2001 10:50:55 +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 EAA01554 It works exactly as you explain. As long as the Egress LER has to do IP look-up (in case there was only one label) or other MPLS look-up (in case of a label stack), and since some machines are not able to do MPLS look-up+label poping+another IP/MPLS look-up in hardware/efficient way, it is possible to make the penultimate LSR in the LSP to pop the outermost label so that the Egress LER will do normal IP routing or will treat the packet according to the next label in the stack (i.e. MPLS VPNs). In some cases, if QoS is bein implemented based on the exp bits of the MPLS header, implicit null may break the path, so explicit null would (label 0) could be used in these cases. ^ ^ ==============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: siva Reddy [SMTP:reddy_lonka@yahoo.com] > Enviado el: miércoles 18 de julio de 2001 10:41 > Para: mpls@UU.NET > Asunto: doubt about implecit NULL label > > Dear all, > when we use implecit NULL (label valu 3) the > penultimate HOP has to pop the label insted of > replacing(swapping).afterwards it will be simply IP > packet only.can penultimate HOP forward the IP packet > to LSR. > > please clarify me about this implecit NULL concept. > thanks in adv. > regards > lonka > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 05: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 SMTP id FAA04277 for ; Wed, 18 Jul 2001 05: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 QQkyem16994; Wed, 18 Jul 2001 09:14:17 GMT Received: by mail-control.mail.uu.net id QQkyem04518 for mpls-outgoing; Wed, 18 Jul 2001 09:13: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 QQkyem04503 for ; Wed, 18 Jul 2001 09:13: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 QQkyem03495 for ; Wed, 18 Jul 2001 09:11:21 GMT Received: from [192.168.15.189] by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mimesw.globespan.net [12.40.232.2]) id QQkyem14175 for ; Wed, 18 Jul 2001 09:11:20 GMT From: Ashish Kulshreshtha To: siva Reddy , mpls@UU.NET Message-ID: <00d901c10f6a$8191f1a0$920119ac@india.ficontech.com> References: <20010718084100.41284.qmail@web13701.mail.yahoo.com> Subject: Re: doubt about implecit NULL label Date: Wed, 18 Jul 2001 14:47:45 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C10F98.9B11B880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C10F98.9B11B880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Penultimate hop doesn't need to do IP forwarding as it knows the outgoing label for egress. So it will send using that label. The advantage is that the egress doesn't need to perform a POP operation. From RFC 3031, section 3.16...... =20 From an architectural perspective, this is perfectly appropriate. The purpose of the level m label is to get the packet to Rn. Once R[n-1] = has decided to send the packet to Rn, the label no longer has any function, and need no longer be carried.=20 There is also a practical advantage to doing penultimate hop popping. = If one does not do this, then when the LSP egress receives a packet, it first looks up the top label, and determines as a result of that lookup that it is indeed the LSP egress. Then it must pop the stack, and examine what remains of the packet. If there is another label on the stack, the egress will look this up and forward the packet based on = this lookup. (In this case, the egress for the packet's level m LSP is also an intermediate node for its level m-1 LSP.) If there is no other label on the stack, then the packet is forwarded according to its network layer destination address. Note that this would require the egress to = do TWO lookups, either two label lookups or a label lookup followed by an address lookup.From an architectural perspective, this is perfectly appropriate. The purpose of the level m label is to get the packet to Rn. Once R[n-1] has decided to send the packet to Rn, the label no longer has any function, and need no longer be carried. There is also a practical advantage to doing penultimate hop popping. If one does not = do this, then when the LSP egress receives a packet, it first looks up the top label, and determines as a result of that lookup that it is indeed the LSP egress. Then it must pop the stack, and examine what remains of the packet. If there is another label on the stack, the egress will = look this up and forward the packet based on this lookup. (In this case, the egress for the packet's level m LSP is also an intermediate node for = its level m-1 LSP.) If there is no other label on the stack, then the = packet is forwarded according to its network layer destination address. Note that this would require the egress to do TWO lookups, either two label lookups or a label lookup followed by an address lookup. =20 the text in bold tells that it uses the label of outgoing interface and then POPS the label. ----- Original Message -----=20 From: siva Reddy=20 To: mpls@uu.net =20 Sent: Wednesday, July 18, 2001 2:11 PM Subject: doubt about implecit NULL label Dear all, when we use implecit NULL (label valu 3) the penultimate HOP has to pop the label insted of replacing(swapping).afterwards it will be simply IP packet only.can penultimate HOP forward the IP packet to LSR. please clarify me about this implecit NULL concept. thanks in adv. regards lonka __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ =20 ------=_NextPart_000_00D6_01C10F98.9B11B880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Penultimate hop doesn't need to = do IP=20 forwarding as it knows the outgoing label for egress. So it will send = using that=20 label.
The advantage is that the egress = doesn't need to=20 perform a POP operation.
From RFC 3031,
section 3.16......
 

From an architectural perspective, this is perfectly appropriate. = The purpose=20 of the level m label is to get the packet to Rn. Once R[n-1] = has decided=20 to send the packet to Rn, the label no longer has any = function, and=20 need no longer be carried.

There is also a practical advantage to doing penultimate hop = popping. If one=20 does not do this, then when the LSP egress receives a packet, it first = looks up=20 the top label, and determines as a result of that lookup that it is = indeed the=20 LSP egress. Then it must pop the stack, and examine what remains of the = packet.=20 If there is another label on the stack, the egress will look this up = and forward=20 the packet based on this lookup. (In this case, the egress for the = packet's=20 level m LSP is also an intermediate node for its level m-1 LSP.) If = there is no=20 other label on the stack, then the packet is forwarded according to its = network=20 layer destination address. Note that this would require the egress to = do TWO=20 lookups, either two label lookups or a label lookup followed by an = address=20 lookup.From an architectural = perspective, this=20 is perfectly appropriate. The purpose of the level m label is to get = the packet=20 to Rn. Once R[n-1] has decided to send the packet to Rn, the label no = longer has=20 any function, and need no longer be carried. There is also a practical = advantage=20 to doing penultimate hop popping. If one does not do this, then when = the LSP=20 egress receives a packet, it first looks up the top label, and = determines as a=20 result of that lookup that it is indeed the LSP egress. Then it must = pop the=20 stack, and examine what remains of the packet. If there is another = label on=20 the stack, the egress will look this up and forward the packet based on = this=20 lookup. (In this case, the egress for the packet's level m LSP is also = an=20 intermediate node for its level m-1 LSP.) If there is no other label on = the=20 stack, then the packet is forwarded according to its network layer = destination=20 address. Note that this would require the egress to do TWO lookups, = either two=20 label lookups or a label lookup followed by an address = lookup.

 

the text in bold tells that it uses the label of = outgoing=20 interface and then POPS  the label.

----- Original Message -----
From:=20 siva=20 Reddy
Sent: Wednesday, July 18, 2001 = 2:11=20 PM
Subject: doubt about implecit = NULL=20 label

Dear all,
when we use implecit NULL (label valu 3)=20 the
penultimate HOP has to pop the label insted=20 of
replacing(swapping).afterwards it will be simply IP
packet = only.can=20 penultimate HOP forward the IP packet
to LSR.

please = clarify me=20 about this implecit NULL concept.
thanks in=20 = adv.
regards
lonka

________________________________________= __________
Do=20 You Yahoo!?
Get personalized email addresses from Yahoo! = Mail
http://personal.mail.yahoo.com/=
------=_NextPart_000_00D6_01C10F98.9B11B880-- From owner-mpls@UU.NET Wed Jul 18 05:33: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 FAA08210 for ; Wed, 18 Jul 2001 05:33: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 QQkyeo14236; Wed, 18 Jul 2001 09:32:39 GMT Received: by mail-control.mail.uu.net id QQkyeo05983 for mpls-outgoing; Wed, 18 Jul 2001 09:32: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 QQkyeo05965 for ; Wed, 18 Jul 2001 09:31:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkyeo06386 for ; Wed, 18 Jul 2001 09:30:11 GMT Received: from babelfish.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: babelfish.axion.bt.co.uk [132.146.17.20]) id QQkyeo04823 for ; Wed, 18 Jul 2001 09:30:10 GMT Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) by babelfish (local) with SMTP; Wed, 18 Jul 2001 10:29:52 +0100 Received: from ip-engineering.bt.com by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id KAA00280; Wed, 18 Jul 2001 10:29:51 +0100 (BST) Message-Id: <200107180929.KAA00280@celiborn.ip-engineering.bt.com> X-Mailer: exmh version 2.0.3 9/28/98 To: Eric Gray cc: erosen@cisco.com, Shahram Davari , "'mpLS@UU.net'" Subject: Re: LSP-ping In-reply-to: Your message of "Tue, 17 Jul 2001 17:03:11 EDT." <3B54A80F.2CBEBEFD@sandburst.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jul 2001 10:29:51 +0100 From: Peter Willis Sender: owner-mpls@UU.NET Precedence: bulk Colleagues, Perhaps the draft-pan-lsp-ping-00.txt can be modified to make it more clear that this is a DIAGNOSTIC tool used AFTER the LSP has failed to deliver user traffic. The draft says this clearly in Section 4 "Motivation" but does not make this clear in the Abstract and Section 3 where it says "This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSP's" I think instead of saying "used to detect data plane failures" it should say "used to diagnose data plane failures". If this wording was changed I would be a lot happier with this draft. Then I can go on to point out that the actual DETECTION mechanism used by this draft is the customer, that is the customer notices connectivity has failed and this triggers diagnostics. So we still need a mechanism to detect LSP failure. -------------------------------------------------------------------------------- Peter Willis peter.j.willis@bt.com IP Technology Strategist Phone: +44 (0)1473 645178 Chief Technology Office Fax: +44 (0)1473 644506 BTexact Technologies. PP3, RSB10, Adastral Park, Martlesham, Ipswich IP5 3RE, UK. -------------------------------------------------------------------------------- From owner-mpls@UU.NET Wed Jul 18 06:07: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 GAA15195 for ; Wed, 18 Jul 2001 06:07: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 QQkyeq20821; Wed, 18 Jul 2001 10:05:09 GMT Received: by mail-control.mail.uu.net id QQkyeq25641 for mpls-outgoing; Wed, 18 Jul 2001 10: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 QQkyeq23223 for ; Wed, 18 Jul 2001 10:04: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 QQkyeq03110 for ; Wed, 18 Jul 2001 10:03:49 GMT Received: from web13709.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13709.mail.yahoo.com [216.136.175.251]) id QQkyeq13305 for ; Wed, 18 Jul 2001 10:03:49 GMT Message-ID: <20010718100348.5245.qmail@web13709.mail.yahoo.com> Received: from [210.212.215.129] by web13709.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 03:03:48 PDT Date: Wed, 18 Jul 2001 03:03:48 -0700 (PDT) From: siva Reddy Subject: Re: doubt about implecit NULL label To: Ashish Kulshreshtha , mpls@UU.NET In-Reply-To: <00d901c10f6a$8191f1a0$920119ac@india.ficontech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk thank you for javier and ashish for your reply , thanks once again regards lonka --- Ashish Kulshreshtha wrote: > Penultimate hop doesn't need to do IP forwarding as > it knows the > outgoing label for egress. So it will send using > that label. > The advantage is that the egress doesn't need to > perform a POP > operation. > From RFC 3031, > section 3.16...... > > From an architectural perspective, this is perfectly > appropriate. The > purpose of the level m label is to get the packet to > Rn. Once R[n-1] has > decided to send the packet to Rn, the label no > longer has any function, > and need no longer be carried. > > There is also a practical advantage to doing > penultimate hop popping. If > one does not do this, then when the LSP egress > receives a packet, it > first looks up the top label, and determines as a > result of that lookup > that it is indeed the LSP egress. Then it must pop > the stack, and > examine what remains of the packet. If there is > another label on the > stack, the egress will look this up and forward the > packet based on this > lookup. (In this case, the egress for the packet's > level m LSP is also > an intermediate node for its level m-1 LSP.) If > there is no other label > on the stack, then the packet is forwarded according > to its network > layer destination address. Note that this would > require the egress to do > TWO lookups, either two label lookups or a label > lookup followed by an > address lookup.From an architectural perspective, > this is perfectly > appropriate. The purpose of the level m label is to > get the packet to > Rn. Once R[n-1] has decided to send the packet to > Rn, the label no > longer has any function, and need no longer be > carried. There is also a > practical advantage to doing penultimate hop > popping. If one does not do > this, then when the LSP egress receives a packet, it > first looks up the > top label, and determines as a result of that lookup > that it is indeed > the LSP egress. Then it must pop the stack, and > examine what remains of > the packet. If there is another label on the stack, > the egress will look > this up and forward the packet based on this lookup. > (In this case, the > egress for the packet's level m LSP is also an > intermediate node for its > level m-1 LSP.) If there is no other label on the > stack, then the packet > is forwarded according to its network layer > destination address. Note > that this would require the egress to do TWO > lookups, either two label > lookups or a label lookup followed by an address > lookup. > > > > the text in bold tells that it uses the label of > outgoing interface and > then POPS the label. > > ----- Original Message ----- > From: siva Reddy > To: mpls@uu.net > Sent: Wednesday, July 18, 2001 2:11 PM > Subject: doubt about implecit NULL label > > Dear all, > when we use implecit NULL (label valu 3) the > penultimate HOP has to pop the label insted of > replacing(swapping).afterwards it will be simply IP > packet only.can penultimate HOP forward the IP > packet > to LSR. > > please clarify me about this implecit NULL concept. > thanks in adv. > regards > lonka > > __________________________________________________ > 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 Wed Jul 18 07:10: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 SMTP id HAA29778 for ; Wed, 18 Jul 2001 07:10: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 QQkyeu02762; Wed, 18 Jul 2001 11:09:59 GMT Received: by mail-control.mail.uu.net id QQkyeu23198 for mpls-outgoing; Wed, 18 Jul 2001 11:09:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkyeu23193 for ; Wed, 18 Jul 2001 11:09:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyeu21926 for ; Wed, 18 Jul 2001 11:09:12 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 QQkyeu02103 for ; Wed, 18 Jul 2001 11:09:11 GMT Received: from AMARHOLD ([194.230.46.1]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Wed, 18 Jul 2001 13:20:08 +0200 From: "Alexander Marhold" To: "siva Reddy" , Subject: RE: doubt about implecit NULL label Date: Wed, 18 Jul 2001 13:10:28 +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) In-Reply-To: <20010718084100.41284.qmail@web13701.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit to clarify the implicit-Null tells to POP the outermost label only it does not remove the complete label-stack if there are multiple levels of labels otherwise TE-tunnels AND MPLS/VPN could not work. So the implicit-null tells to not use a label at the corresponding stacklevel and not for all levels. 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 siva Reddy Sent: Wednesday, July 18, 2001 10:41 AM To: mpls@UU.NET Subject: doubt about implecit NULL label Dear all, when we use implecit NULL (label valu 3) the penultimate HOP has to pop the label insted of replacing(swapping).afterwards it will be simply IP packet only.can penultimate HOP forward the IP packet to LSR. please clarify me about this implecit NULL concept. thanks in adv. regards lonka __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 09:21: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 JAA19486 for ; Wed, 18 Jul 2001 09:21: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 QQkyfd00272; Wed, 18 Jul 2001 13:20:15 GMT Received: by mail-control.mail.uu.net id QQkyfd13434 for mpls-outgoing; Wed, 18 Jul 2001 13: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 QQkyfd13428 for ; Wed, 18 Jul 2001 13:19: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 QQkyfd21789 for ; Wed, 18 Jul 2001 13:18:30 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 QQkyfd03618 for ; Wed, 18 Jul 2001 13:18:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA10181 for mpls@uu.net; Wed, 18 Jul 2001 09:18:30 -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 QQkyfd13362 for ; Wed, 18 Jul 2001 13:17:54 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 QQkyfc11373 for ; Wed, 18 Jul 2001 13:12:25 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 QQkyfc20808 for ; Wed, 18 Jul 2001 13:12:24 GMT Received: (qmail 5937 invoked by uid 104); 18 Jul 2001 13:12:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.547919 secs); 18/07/2001 06:12:23 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 18 Jul 2001 13:12:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6IDCQP08399; Wed, 18 Jul 2001 06:12:26 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 06:18:01 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D8A@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" , erosen@cisco.com Cc: "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Wed, 18 Jul 2001 06:17: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 Hi Eric (Gray), Thanks for your explanation. I fully understand that LSP-ping is not used as alive protocol. As I understand it, this draft suggests ICMP-ping is used as alive protocol, in the forward direction. My suggestion was simply to use the same method (ICMP-ping) as alive protocol for the reverse direction too. I understand that this may require running ICMP-ping from every egress router to all relevant ingress routers, but it should not cause any scaling problem, because the number of reverse ICMP-pings is independent of the number of LSPs. In fact it is a small fraction of the number of LSPs. Now if there is an LSP from the egress LSR to the ingress LSR (reverse LSP), and if that LSP is also a candidate for connectivity test, then according to this draft we should run ICMP-ping over that LSP. If we do so then we don't need to run another instance of ICMP-ping on the reverse direction. In other words we could save some overload. Yours, -Shahram > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Tuesday, July 17, 2001 5:03 PM > To: erosen@cisco.com > Cc: Shahram Davari; 'mpLS@UU.net' > Subject: Re: LSP-ping > > > Eric, > > The thrust of Shahram's proposal is that the egress LSR would > normally be pinging the ingress LSR. This was why I asked him if > there wasn't a better approach than using ping as an alive protocol. > =================================================== > > Shahram, > > As I understand it (based in part on the partial dialog > between Ping > Pan and George Swallow), Ping's proposal is not an attempt to use > LSP ping as an alive protocol, but rather an additional tool > to use when > normal ping is not working. If I am mis-representing the > dialog, I offer > my apologies, but - if this is in fact what is proposed - it > at least has > this advantage over your proposal. > > -- > Eric Gray > > You wrote: > > > Shahram> My suggestion is different. The ingress LSR checks > the connectivity > > Shahram> status of the reverse LSP, by checking to > see whether it is > > Shahram> receiving ICMP-pings from the egress LSR. If > it is, then the > > Shahram> reverse LSP is fine, and any failure to receive > ICMP-Echo from the > > Shahram> egress LSR is due to forward LSP. > > > > Presumably, the egress LSR is not normally pinging the > ingress LSR, so I'm > > not sure just what you mean. (If all LSP egresses are > constantly pinging > > all LSP ingresses, then I think we have a scaling problem.) > > > > If the problem one is investigating is that there appear > to be data packets > > that reach the LSP ingress but get lost before they reach > the LSP egress, I > > don't think one wants a diagnostic tool that depends on > one's being able to > > explicitly control the egress. So telling the egress to > ping the ingress > > (and then monitoring the ingress to see if the pings are > received) doesn't > > seem like the best strategy. > From owner-mpls@UU.NET Wed Jul 18 09:51: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 JAA26342 for ; Wed, 18 Jul 2001 09:51: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 QQkyff27565; Wed, 18 Jul 2001 13:51:04 GMT Received: by mail-control.mail.uu.net id QQkyff16478 for mpls-outgoing; Wed, 18 Jul 2001 13:50:28 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 QQkyff16464 for ; Wed, 18 Jul 2001 13:50:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyff28883 for ; Wed, 18 Jul 2001 13:49:15 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 QQkyff26054 for ; Wed, 18 Jul 2001 13:49:15 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6IDnEQ28299 for ; Wed, 18 Jul 2001 09:49:14 -0400 (EDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Jul 2001 09:49:13 -0400 Message-ID: From: "Jiang, Donghua (Donghua)" To: "'wiseguy@cs.stanford.edu'" Cc: "'mpls@uu.net'" Subject: RE: [MPLS] Popping Multiple Labels Date: Wed, 18 Jul 2001 09:49:10 -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 Manish, When you say "T2 is tunneled over T1", do you mean T1 is tunneled inside T2 or T2 is tunneled inside T1? After I sent out the email yesterday, I was getting suspicious about what I said. If T1 is tunneled inside T2, then the packets are traveling from L1 to L3, the MPLS label used for T2 will always be the top label and forwarding will be based on the top label, we would not care about the existence of T1. So, T1 will not be involved when packets travels from L1 to L3. If T2 is tunneled inside T1, then from L1 to L21, packets will be forwarded based on the MPLS labels for T2. When packets get to L21, one more layer of label will be pushed on and packet forwarding will be based on the newly added label layer. When packets get to L22, the top layer will be popped as it is the end of the tunnel T1. Also, due to the negotiation between L22 and L3, the current top label should also be popped before the packets are forwarded to L3. Hope you did not mean to play the trick :-) Regards, Jane -----Original Message----- From: wiseguy@cs.stanford.edu [mailto:wiseguy@cs.stanford.edu] Sent: Tuesday, July 17, 2001 12:06 PM To: mpls@UU.NET Subject: [MPLS] Popping Multiple Labels Hi, I was wondering if there are any possible scenarios in which a node might pop multiple labels from the stack. One case I was thinking of is : a node is endpoint of a tunnel (T1) and is also a penultimate hop for another tunnel (T2) and T2 is tunneled over T1! Maybe this is not a valid scenario but I would like to check. I appreciate any help. thanks, manish PS: Scenario +-----+ +-------+ +-------+ +------+ | | ===~== | | ====~~=== | +---------+ | | L1 | | L21 | | L2n | | L3 | +-----+ +-------+ +-------+ +------+ <------------ T1 --------------> <--------------------------T2----------------------> From owner-mpls@UU.NET Wed Jul 18 09:55: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 JAA27359 for ; Wed, 18 Jul 2001 09:55:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyff07888; Wed, 18 Jul 2001 13:53:01 GMT Received: by mail-control.mail.uu.net id QQkyff16701 for mpls-outgoing; Wed, 18 Jul 2001 13:52: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 QQkyff16683 for ; Wed, 18 Jul 2001 13:52: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 QQkyff20021 for ; Wed, 18 Jul 2001 13:51:23 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 QQkyff08706 for ; Wed, 18 Jul 2001 13:51:22 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07824; Wed, 18 Jul 2001 09:51:22 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA04073; Wed, 18 Jul 2001 09:51:15 -0400 (EDT) Message-Id: <200107181351.JAA04073@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Ping Pan cc: "Punj, Arun" , mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Tue, 17 Jul 2001 14:19:52 -0700. <3B54ABF8.854B0983@juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Jul 2001 09:51:15 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Ping> The problem with this approach is: there is no guarantee that the Ping> returning path (with or without IP Router Alert) won't go over an LSP. Ping> If that LSP is bad, we are in trouble. Since tunnels can be nested, isn't is possible that in a traffic engineered path , R2 and R3, say, are IGP adjacencies over a virtual interface that is actually a pair of LSPs (one from R2 to R3, one from R3 to R2)? In such a case there is no guarantee that the control path (forward and reverse) does not include an LSP. From owner-mpls@UU.NET Wed Jul 18 09:57: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 JAA28141 for ; Wed, 18 Jul 2001 09:57:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyff02458; Wed, 18 Jul 2001 13:57:05 GMT Received: by mail-control.mail.uu.net id QQkyff17159 for mpls-outgoing; Wed, 18 Jul 2001 13:56:32 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 QQkyff17063 for ; Wed, 18 Jul 2001 13:56:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyff24766 for ; Wed, 18 Jul 2001 13:56:03 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 QQkyff13865 for ; Wed, 18 Jul 2001 13:56:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA08397; Wed, 18 Jul 2001 09:56:02 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA04094; Wed, 18 Jul 2001 09:55:55 -0400 (EDT) Message-Id: <200107181355.JAA04094@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Eric Gray'" , "'mpLS@UU.net'" Subject: Re: LSP-ping In-reply-to: Your message of Wed, 18 Jul 2001 06:17:59 -0700. <9DC5E2ABE65BD54CA9088DA3194461D6037A6D8A@BBY1EXM01> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Jul 2001 09:55:55 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Sharam> I understand that this may require running ICMP-ping from every Sharam> egress router to all relevant ingress routers, but it should not Sharam> cause any scaling problem, This is basically the procedure of having all routers in a network pinging all other routers in the network, which was first denigrated as a scaling problem about 20 years ago. I don't think it's a good idea to have a troubleshooting procedure which depends, for its utility, on this kind of continuous pinging. From owner-mpls@UU.NET Wed Jul 18 09:59: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 JAA28466 for ; Wed, 18 Jul 2001 09:59: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 QQkyff13225; Wed, 18 Jul 2001 13:58:44 GMT Received: by mail-control.mail.uu.net id QQkyff17246 for mpls-outgoing; Wed, 18 Jul 2001 13:58: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 QQkyff17225 for ; Wed, 18 Jul 2001 13:57: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 QQkyff08318 for ; Wed, 18 Jul 2001 13:56:57 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 QQkyff02284 for ; Wed, 18 Jul 2001 13:56:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA14354 for mpls@uu.net; Wed, 18 Jul 2001 09:56:56 -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 QQkyff17087 for ; Wed, 18 Jul 2001 13:56: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 QQkyff23034 for ; Wed, 18 Jul 2001 13:54:16 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 QQkyff09294 for ; Wed, 18 Jul 2001 13:54:16 GMT Received: (qmail 15536 invoked by uid 104); 18 Jul 2001 13:54:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.444815 secs); 18/07/2001 06:54:15 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 18 Jul 2001 13:54:14 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6IDsIP04064; Wed, 18 Jul 2001 06:54:18 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 06:59:52 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D8B@BBY1EXM01> From: Shahram Davari To: "'Peter Willis'" , Eric Gray , "'Ping Pan'" Cc: erosen@cisco.com, "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Wed, 18 Jul 2001 06:59:51 -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 Ping, Could you please clarify, which mechanism finds that there is a problem in the first place. Is it customer complain, or do you run ICMP-ping continuously over the life of the LSP? -Shahram > -----Original Message----- > From: Peter Willis [mailto:pjw@ip-engineering.bt.com] > Sent: Wednesday, July 18, 2001 5:30 AM > To: Eric Gray > Cc: erosen@cisco.com; Shahram Davari; 'mpLS@UU.net' > Subject: Re: LSP-ping > > > Colleagues, > > Perhaps the draft-pan-lsp-ping-00.txt can be modified to make > it more clear > that this is a DIAGNOSTIC tool used AFTER the LSP has failed > to deliver user > traffic. The draft says this clearly in Section 4 > "Motivation" but does not > make this clear in the Abstract and Section 3 where it says > "This document describes a simple and efficient mechanism that can be > used to detect data plane failures in MPLS LSP's" > > I think instead of saying "used to detect data plane > failures" it should say > "used to diagnose data plane failures". > > If this wording was changed I would be a lot happier with this draft. > > Then I can go on to point out that the actual DETECTION > mechanism used by this > draft is the customer, that is the customer notices > connectivity has failed > and this triggers diagnostics. So we still need a mechanism > to detect LSP > failure. > > > -------------------------------------------------------------- > ------------------ > Peter Willis > peter.j.willis@bt.com > IP Technology Strategist Phone: > +44 (0)1473 645178 > Chief Technology Office Fax: > +44 (0)1473 644506 > BTexact Technologies. > PP3, RSB10, Adastral Park, Martlesham, Ipswich IP5 3RE, UK. > -------------------------------------------------------------- > ------------------ > > From owner-mpls@UU.NET Wed Jul 18 10:04: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 KAA29291 for ; Wed, 18 Jul 2001 10:04:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyfg17088; Wed, 18 Jul 2001 14:02:30 GMT Received: by mail-control.mail.uu.net id QQkyfg22216 for mpls-outgoing; Wed, 18 Jul 2001 14:01: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 QQkyfg22041 for ; Wed, 18 Jul 2001 14:01:31 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 QQkyff09833 for ; Wed, 18 Jul 2001 13:58:28 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 QQkyff12737 for ; Wed, 18 Jul 2001 13:58:20 GMT Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6IDvs903140 for ; Wed, 18 Jul 2001 09:57:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 18 Jul 2001 09:57:43 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ27FWA>; Wed, 18 Jul 2001 09:57:44 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3410569E@zcard0ka.ca.nortel.com> From: "David Allan" To: Ashish Kulshreshtha , siva Reddy , mpls@UU.NET Subject: RE: doubt about implecit NULL label Date: Wed, 18 Jul 2001 09:57:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F91.9B9BAD30" 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_01C10F91.9B9BAD30 Content-Type: text/plain; charset="iso-8859-1" Ashish: you wrote.... Once R[n-1] has decided to send the packet to R[n], the label no longer has any function, and need no longer be carried. ..... IMHO this is true only if R[n] does not care about where the traffic came from, and R[n-1] can do appropriate queueing discipline without using an LSP. I can think of lots of reasons why carrying a label to R[n] would actually optimize the hardware. cheers Dave ------_=_NextPart_001_01C10F91.9B9BAD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: doubt about implecit NULL label

Ashish:

you wrote.... Once R[n-1] has decided to send the = packet to R[n], the label no longer has any function, and need no = longer be carried.  .....

IMHO this is true only if R[n] does not care about = where the traffic came from, and R[n-1] can do appropriate queueing = discipline without using an LSP.

I can think of lots of reasons why carrying a label = to R[n] would actually optimize the hardware.

cheers
Dave

------_=_NextPart_001_01C10F91.9B9BAD30-- From owner-mpls@UU.NET Wed Jul 18 10:10: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 KAA00305 for ; Wed, 18 Jul 2001 10:10: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 QQkyfg12035; Wed, 18 Jul 2001 14:08:18 GMT Received: by mail-control.mail.uu.net id QQkyfg07627 for mpls-outgoing; Wed, 18 Jul 2001 14:07: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 QQkyfg07613 for ; Wed, 18 Jul 2001 14:07:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyfg05788 for ; Wed, 18 Jul 2001 14:06: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 QQkyfg10112 for ; Wed, 18 Jul 2001 14:06:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA16628 for mpls@uu.net; Wed, 18 Jul 2001 10:06:05 -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 QQkyfg05769 for ; Wed, 18 Jul 2001 14:05: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 QQkyfg18323 for ; Wed, 18 Jul 2001 14:05:08 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 QQkyfg09232 for ; Wed, 18 Jul 2001 14:05:07 GMT Received: (qmail 16416 invoked by uid 104); 18 Jul 2001 14:05:06 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.392251 secs); 18/07/2001 07:05:06 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 18 Jul 2001 14:05:06 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6IE59P10221; Wed, 18 Jul 2001 07:05:10 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 07:10:44 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D8C@BBY1EXM01> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Eric Gray'" , "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Wed, 18 Jul 2001 07:10:44 -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 Eric, My understanding from this draft was that ICMP-ping is used as alive protocol (running it continuously over the life of an LSP), and is used to detect that a failure has occurred. If this is not true, in order words if the customer or some other procedure is used to detect that a fault has occurred in the first place, then you are correct. -Shahram > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, July 18, 2001 9:56 AM > To: Shahram Davari > Cc: 'Eric Gray'; 'mpLS@UU.net' > Subject: Re: LSP-ping > > > > Sharam> I understand that this may require running > ICMP-ping from every > Sharam> egress router to all relevant ingress routers, but > it should not > Sharam> cause any scaling problem, > > This is basically the procedure of having all routers in a > network pinging > all other routers in the network, which was first > denigrated as a scaling > problem about 20 years ago. I don't think it's a good > idea to have a > troubleshooting procedure which depends, for its utility, > on this kind of > continuous pinging. > > > > From owner-mpls@UU.NET Wed Jul 18 10:45: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 KAA08314 for ; Wed, 18 Jul 2001 10:45: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 QQkyfi21141; Wed, 18 Jul 2001 14:43:16 GMT Received: by mail-control.mail.uu.net id QQkyfi10928 for mpls-outgoing; Wed, 18 Jul 2001 14:42: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 QQkyfi10923 for ; Wed, 18 Jul 2001 14:42: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 QQkyfi13149 for ; Wed, 18 Jul 2001 14:39:48 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 QQkyfi08700 for ; Wed, 18 Jul 2001 14:39:43 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13980 for ; Wed, 18 Jul 2001 10:39:43 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA04337 for mpls@uu.net; Wed, 18 Jul 2001 10:39:36 -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 QQkyfi10291 for ; Wed, 18 Jul 2001 14:32: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 QQkyfi18864 for ; Wed, 18 Jul 2001 14:31:58 GMT From: Aditya@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 QQkyfi02312 for ; Wed, 18 Jul 2001 14:31:57 GMT Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19) id <354Q6QVQ>; Wed, 18 Jul 2001 20:05:03 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C568780996C@HUAWEIMAIL> To: afarrel@movaz.com, pjb@dataconnection.com, eric.gray@sandburst.com, philipma@nortelnetworks.com, mpls@UU.NET, mpls-ops@mplsrc.com Subject: fault tolerant TCP implementation Date: Wed, 18 Jul 2001 20:05:02 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F9B.05334C40" 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_01C10F9B.05334C40 Content-Type: text/plain; charset="iso-8859-1" Dear MPLS Gurus, In the draft on ldp-FT (draft-ietf-mpls-ldp-ft-02.txt ) the authors write on Page 4, in section 2.2 that it "Notoriously Hard to provide a fault tolerant implementation of TCP"...My question is WHY ? .Why is it so difficult to recreate a TCP connection ( across a switchover from Active Board to Standby Board ) if the connection is in ESTABLISHED state ? Later they go on to say that "This is an issue familiar to implementers of other TCP applications such as BGP". If anyone could point me to any such related work,I would highly appreciate their help. I guess that the close interaction of the TCP layer, socket layer and application complicates the problem? But HOW ? If anybody is aware of any attempts to provide HotStandby for TCP,please do let me know...... Thanks in Advance, Aditya Extract from "draft-ietf-mpls-ldp-ft-02.txt" Section 2.2 Page 4 LDP and CR-LDP use TCP to provide reliable connections between LSRs over which to exchange protocol messages to distribute labels and to set up LSPs...... TCP enables LDP and CR-LDP to assume reliable transfer of protocol messages. This means that some of the messages do not need to be acknowledged (for example, Label Release). LDP and CR-LDP are defined such that if the TCP connection fails, the LSR should immediately tear down the LSPs associated with the session between the LDP peers, and release any labels and resources assigned to those LSPs. It is notoriously hard to provide a Fault Tolerant implementation of TCP. To do so might involve making copies of all data sent and received. This is an issue familiar to implementers of other TCP applications such as BGP. ------_=_NextPart_001_01C10F9B.05334C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fault tolerant TCP implementation

Dear MPLS Gurus,
In the draft on ldp-FT = (draft-ietf-mpls-ldp-ft-02.txt ) the authors write on Page 4, in = section 2.2 that it  "Notoriously Hard

to provide a fault tolerant = implementation of TCP"...My question is WHY ? .Why is it so = difficult to recreate a TCP connection ( across a switchover

from Active Board to Standby Board ) = if the connection is in ESTABLISHED state ?
Later they go on to say that  = "This is an issue familiar to implementers of other TCP = applications such as BGP".
If anyone could point me to any such = related work,I would highly appreciate their help.
I guess that the close interaction = of the TCP layer, socket layer and application complicates the problem? = But HOW ?
If anybody is aware of any attempts = to provide HotStandby for TCP,please do let me know......
Thanks in Advance,
Aditya
Extract from = "draft-ietf-mpls-ldp-ft-02.txt" Section 2.2 Page 4
LDP and CR-LDP use TCP to provide = reliable connections between LSRs over which to exchange protocol = messages to distribute labels and to set up LSPs...... TCP enables LDP = and CR-LDP to assume reliable transfer of protocol messages. This means = that some of the messages do not need to be acknowledged (for example, = Label Release). LDP and CR-LDP are defined such that if the TCP = connection fails, the LSR should immediately tear down the LSPs = associated with the session between the LDP peers, and release any = labels and resources assigned to those LSPs. It is notoriously hard = to provide a Fault Tolerant implementation of TCP. To do so might = involve making copies of all data sent and received. This is an issue = familiar to implementers of other TCP applications such as BGP. =

------_=_NextPart_001_01C10F9B.05334C40-- From owner-mpls@UU.NET Wed Jul 18 10:57: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 KAA11169 for ; Wed, 18 Jul 2001 10:57: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 QQkyfj25445; Wed, 18 Jul 2001 14:56:55 GMT Received: by mail-control.mail.uu.net id QQkyfj12766 for mpls-outgoing; Wed, 18 Jul 2001 14:56: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 QQkyfj12599 for ; Wed, 18 Jul 2001 14:56:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyfj14001 for ; Wed, 18 Jul 2001 14:54:03 GMT Received: from web11404.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11404.mail.yahoo.com [216.136.131.234]) id QQkyfj22073 for ; Wed, 18 Jul 2001 14:54:02 GMT Message-ID: <20010718145402.43604.qmail@web11404.mail.yahoo.com> Received: from [65.194.140.2] by web11404.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 07:54:02 PDT Date: Wed, 18 Jul 2001 07:54:02 -0700 (PDT) From: Sanjay Wadhwa Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: erosen@cisco.com, Ping Pan Cc: "Punj, Arun" , mpls-list In-Reply-To: <200107181351.JAA04073@erosen-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk --- Eric Rosen wrote: > > Ping> The problem with this approach is: there is no guarantee that > the > Ping> returning path (with or without IP Router Alert) won't go over > an LSP. > Ping> If that LSP is bad, we are in trouble. > > Since tunnels can be nested, isn't is possible that in a traffic > engineered > path , R2 and R3, say, are IGP adjacencies > over a > virtual interface that is actually a pair of LSPs (one from R2 to > R3, one > from R3 to R2)? In such a case there is no guarantee that the > control path > (forward and reverse) does not include an LSP. > Sure. But if the reverse LSP (virtual interface) is broken (say due to corrupted label maps along the way), then even the RESVs for the inner LSPs don't make it through, and soon enough the inner LSP will be torn down (So making echo-response live and die with rsvp resv actually will work fine with nested tunnels irrespective of RESV using a reverse LSP or native ip in the reverse direction). -Sanjay __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 11:20: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 LAA16872 for ; Wed, 18 Jul 2001 11:20: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 QQkyfj00454; Wed, 18 Jul 2001 14:55:19 GMT Received: by mail-control.mail.uu.net id QQkyfj12528 for mpls-outgoing; Wed, 18 Jul 2001 14:54: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 QQkyfj12489 for ; Wed, 18 Jul 2001 14:54: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 QQkyfj00418 for ; Wed, 18 Jul 2001 14:53:42 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkyfj29299 for ; Wed, 18 Jul 2001 14:53:42 GMT Message-ID: <3B55A2F4.964D921@sandburst.com> Date: Wed, 18 Jul 2001 10:53:40 -0400 From: Eric Gray MIME-Version: 1.0 To: erosen@cisco.com Cc: Ping Pan , mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <200107181351.JAA04073@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Yes, but there are other means to determine if there is a problem with the control path. -- Eric Gray You wrote: > Ping> The problem with this approach is: there is no guarantee that the > Ping> returning path (with or without IP Router Alert) won't go over an LSP. > Ping> If that LSP is bad, we are in trouble. > > Since tunnels can be nested, isn't is possible that in a traffic engineered > path , R2 and R3, say, are IGP adjacencies over a > virtual interface that is actually a pair of LSPs (one from R2 to R3, one > from R3 to R2)? In such a case there is no guarantee that the control path > (forward and reverse) does not include an LSP. From owner-mpls@UU.NET Wed Jul 18 11:34: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 LAA21752 for ; Wed, 18 Jul 2001 11:34: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 QQkyfm07063; Wed, 18 Jul 2001 15:32:37 GMT Received: by mail-control.mail.uu.net id QQkyfm09379 for mpls-outgoing; Wed, 18 Jul 2001 15:32: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 QQkyfm09369 for ; Wed, 18 Jul 2001 15:31:54 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 QQkyfl01800 for ; Wed, 18 Jul 2001 15:29:19 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkyfl28971 for ; Wed, 18 Jul 2001 15:29:14 GMT Message-ID: <3B55AB48.EB68612E@sandburst.com> Date: Wed, 18 Jul 2001 11:29:12 -0400 From: Eric Gray MIME-Version: 1.0 To: Aditya@in.huawei.com Cc: danny@ambernetworks.com, afarrel@movaz.com, pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: fault tolerant TCP implementation References: <200107181452.f6IEqhC21212@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Aditya, A big part of the difficulty may not be superficially obvious. TCP has to maintain synchronization state on all unacknowledged packets as well as which packets it has already acknowledged for each entity with which it has established sockets. Keeping synchroniztion across multiple redundant TCP implementations can keep a set of CPUs fairly busy. What Danny is alluding to in his somewhat unsubtle plug is that you can come up with several architectural approaches to make it a little easier to do this. However, the extent of dynamism involved in keeping even two redundant local TCP instances in synch (without involving any remote TCP instances) can make it difficult to architect a system that does this without coupling the two instances to such a high degree that many (if not most) of the things that would make one fail would have the same effect on the other. -- Eric Gray Danny McPherson wrote: > > Dear MPLS Gurus, > > In the draft on ldp-FT (draft-ietf-mpls-ldp-ft-02.txt ) the authors > > write on Page 4, in section 2.2 that it "Notoriously Hard > > > > to provide a fault tolerant implementation of TCP"...My question is WHY > > ? .Why is it so difficult to recreate a TCP connection ( across a > > switchover > > > > from Active Board to Standby Board ) if the connection is in ESTABLISHED > > state ? > > Later they go on to say that "This is an issue familiar to implementers > > of other TCP applications such as BGP". > > If anyone could point me to any such related work,I would highly > > appreciate their help. > > I know of at least one vendor (deployed in production networks) that > provides this (i.e., stateful TCP failover for BGP, LDP, etc..). It's > not impossible, it's just not "easy", especially when the system isn't > designed from the start to support it. > > -danny From owner-mpls@UU.NET Wed Jul 18 11:41:53 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 LAA24152 for ; Wed, 18 Jul 2001 11:41: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 QQkyfm17591; Wed, 18 Jul 2001 15:41:10 GMT Received: by mail-control.mail.uu.net id QQkyfm10119 for mpls-outgoing; Wed, 18 Jul 2001 15:40: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 QQkyfm10107 for ; Wed, 18 Jul 2001 15:40:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyfm24780 for ; Wed, 18 Jul 2001 15:40:00 GMT Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged)) id QQkyfm26467 for ; Wed, 18 Jul 2001 15:40:00 GMT Received: from BLIULAPTOP ([172.16.8.181]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 11:34:42 -0400 Message-ID: <01f701c10f9f$53181b30$65c4893e@movaz.com> From: "Adrian Farrel" To: "Eric Gray" , Cc: , , , , References: <200107181452.f6IEqhC21212@tcb.net> <3B55AB48.EB68612E@sandburst.com> Subject: Re: fault tolerant TCP implementation Date: Wed, 18 Jul 2001 11:35:44 -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: 18 Jul 2001 15:34:44.0565 (UTC) FILETIME=[2B69B850:01C10F9F] Sender: owner-mpls@UU.NET Precedence: bulk In deed! For example, a naïf implementer would look at the problem and decide that the way to achieve TCP FT is to replicate the data in each packet between the two TCP stacks. Now depending on the hardware architecture, this may require a significant amount of data shuffling across the backplane. This is likely to have some impact on performance. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Eric Gray" To: Cc: ; ; ; ; ; Sent: Wednesday, July 18, 2001 11:29 AM Subject: Re: fault tolerant TCP implementation > Aditya, > > A big part of the difficulty may not be superficially obvious. TCP > has to maintain synchronization state on all unacknowledged packets > as well as which packets it has already acknowledged for each entity > with which it has established sockets. Keeping synchroniztion across > multiple redundant TCP implementations can keep a set of CPUs fairly > busy. > > What Danny is alluding to in his somewhat unsubtle plug is that you > can come up with several architectural approaches to make it a little > easier to do this. However, the extent of dynamism involved in keeping > even two redundant local TCP instances in synch (without involving any > remote TCP instances) can make it difficult to architect a system that > does this without coupling the two instances to such a high degree that > many (if not most) of the things that would make one fail would have the > same effect on the other. > > -- > Eric Gray > > Danny McPherson wrote: > > > > Dear MPLS Gurus, > > > In the draft on ldp-FT (draft-ietf-mpls-ldp-ft-02.txt ) the authors > > > write on Page 4, in section 2.2 that it "Notoriously Hard > > > > > > to provide a fault tolerant implementation of TCP"...My question is WHY > > > ? .Why is it so difficult to recreate a TCP connection ( across a > > > switchover > > > > > > from Active Board to Standby Board ) if the connection is in ESTABLISHED > > > state ? > > > Later they go on to say that "This is an issue familiar to implementers > > > of other TCP applications such as BGP". > > > If anyone could point me to any such related work,I would highly > > > appreciate their help. > > > > I know of at least one vendor (deployed in production networks) that > > provides this (i.e., stateful TCP failover for BGP, LDP, etc..). It's > > not impossible, it's just not "easy", especially when the system isn't > > designed from the start to support it. > > > > -danny > From owner-mpls@UU.NET Wed Jul 18 11:47:47 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 LAA25682 for ; Wed, 18 Jul 2001 11:47: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 QQkyfj24303; Wed, 18 Jul 2001 14:58:25 GMT Received: by mail-control.mail.uu.net id QQkyfj12963 for mpls-outgoing; Wed, 18 Jul 2001 14:57:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkyfj12831 for ; Wed, 18 Jul 2001 14:56:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyfj07687 for ; Wed, 18 Jul 2001 14:55:10 GMT Received: from tcb.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQkyfj21655 for ; Wed, 18 Jul 2001 14:55:10 GMT Received: from nut.tcb.net (danny@localhost) by tcb.net (8.11.4/8.11.4) with ESMTP id f6IEqhC21212; Wed, 18 Jul 2001 08:52:44 -0600 Message-Id: <200107181452.f6IEqhC21212@tcb.net> X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 To: Aditya@in.huawei.com cc: afarrel@movaz.com, pjb@dataconnection.com, eric.gray@sandburst.com, philipma@nortelnetworks.com, mpls@UU.NET, mpls-ops@mplsrc.com From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: fault tolerant TCP implementation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jul 2001 08:52:43 -0600 Sender: owner-mpls@UU.NET Precedence: bulk > Dear MPLS Gurus, > In the draft on ldp-FT (draft-ietf-mpls-ldp-ft-02.txt ) the authors > write on Page 4, in section 2.2 that it "Notoriously Hard > > to provide a fault tolerant implementation of TCP"...My question is WHY > ? .Why is it so difficult to recreate a TCP connection ( across a > switchover > > from Active Board to Standby Board ) if the connection is in ESTABLISHED > state ? > Later they go on to say that "This is an issue familiar to implementers > of other TCP applications such as BGP". > If anyone could point me to any such related work,I would highly > appreciate their help. I know of at least one vendor (deployed in production networks) that provides this (i.e., stateful TCP failover for BGP, LDP, etc..). It's not impossible, it's just not "easy", especially when the system isn't designed from the start to support it. -danny From owner-mpls@UU.NET Wed Jul 18 12:27:41 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 MAA06228 for ; Wed, 18 Jul 2001 12:27: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 QQkyfp12334; Wed, 18 Jul 2001 16:26:44 GMT Received: by mail-control.mail.uu.net id QQkyfp06620 for mpls-outgoing; Wed, 18 Jul 2001 16:25: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 QQkyfp06577 for ; Wed, 18 Jul 2001 16:24: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 QQkyfp22436 for ; Wed, 18 Jul 2001 16:21:37 GMT Received: from web20104.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20104.mail.yahoo.com [216.136.226.41]) id QQkyfp02214 for ; Wed, 18 Jul 2001 16:21:37 GMT Message-ID: <20010718162136.32169.qmail@web20104.mail.yahoo.com> Received: from [134.56.103.118] by web20104.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 09:21:36 PDT Date: Wed, 18 Jul 2001 09:21:36 -0700 (PDT) From: Manish Godara Subject: RE: [MPLS] Popping Multiple Labels To: "\ Jiang, Donghua \(Donghua\)" Cc: "\ 'mpls@uu.net'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Jane, Apologies for the confusion. I meant T2 is tunneled inside T2. Thanks for the clarification. So it is possible to pop two labels at one LSR. Now I wonder if it is efficient to implement this in hardware. thanks, manish ------------- your mail ---------------- Manish, When you say "T2 is tunneled over T1", do you mean T1 is tunneled inside T2 or T2 is tunneled inside T1? After I sent out the email yesterday, I was getting suspicious about what I said. If T1 is tunneled inside T2, then the packets are traveling from L1 to L3, the MPLS label used for T2 will always be the top label and forwarding will be based on the top label, we would not care about the existence of T1. So, T1 will not be involved when packets travels from L1 to L3. If T2 is tunneled inside T1, then from L1 to L21, packets will be forwarded based on the MPLS labels for T2. When packets get to L21, one more layer of label will be pushed on and packet forwarding will be based on the newly added label layer. When packets get to L22, the top layer will be popped as it is the end of the tunnel T1. Also, due to the negotiation between L22 and L3, the current top label should also be popped before the packets are forwarded to L3. Hope you did not mean to play the trick :-) Regards, Jane -----Original Message----- From: wiseguy@cs.stanford.edu [mailto:wiseguy@cs.stanford.edu] Sent: Tuesday, July 17, 2001 12:06 PM To: mpls@UU.NET Subject: [MPLS] Popping Multiple Labels Hi, I was wondering if there are any possible scenarios in which a node might pop multiple labels from the stack. One case I was thinking of is : a node is endpoint of a tunnel (T1) and is also a penultimate hop for another tunnel (T2) and T2 is tunneled over T1! Maybe this is not a valid scenario but I would like to check. I appreciate any help. thanks, manish PS: Scenario +-----+ +-------+ +-------+ +------+ | | ===~== | | ====~~=== | +---------+ | | L1 | | L21 | | L2n | | L3 | +-----+ +-------+ +-------+ +------+ <------------ T1 --------------> <--------------------------T2----------------------> __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 12:45: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 MAA10023 for ; Wed, 18 Jul 2001 12:45: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 QQkyfq26393; Wed, 18 Jul 2001 16:44:31 GMT Received: by mail-control.mail.uu.net id QQkyfq08514 for mpls-outgoing; Wed, 18 Jul 2001 16:43:56 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 QQkyfq08489 for ; Wed, 18 Jul 2001 16:43: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 QQkyfq13427 for ; Wed, 18 Jul 2001 16:41:51 GMT Received: from ganymede.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns01.or.intel.com [134.134.248.3]) id QQkyfq19153 for ; Wed, 18 Jul 2001 16:41:51 GMT Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA21110; Wed, 18 Jul 2001 16:41:50 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 16:41:50 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id <3X1Y1D0R>; Wed, 18 Jul 2001 09:41:48 -0700 Message-ID: From: "Feng, Mark" To: "'Ping Pan'" Cc: "'mpls@uu.net'" Subject: RE: Session Attributes Date: Wed, 18 Jul 2001 09:41: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 Ping, I know the name implies the attributes belong to the session. But does it mean all senders, i.e. ingress routers, need to have the same session attributes? Should the transit nodes reject the new Path message, if the session attributes are different from other senders of the same session, because there is no rule on "merging" the session attributes? Thanks. - Mark > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Tuesday, July 17, 2001 9:37 PM > To: Khuzema Pithewan > Cc: rsvp@ISI.EDU > Subject: Re: Session Attributes > > > Khuzema, > > First, this question should go to the mpls list. Please forward the > discussion to that list. Second, the question itself is implementation > dependent. Finally, since the Session Attribute object is to describe > the properties of a RSVP session, in a normal implementation, > it should > be kept where you keep the session. > > - Ping > > Khuzema Pithewan wrote: > > > > Hi, > > > > Session Attribute Object in RSVP-TE contains some flags , setup and > > holding priority and some session related info. > > > > My doubt is , if this object is per session or per LSP, > because name > > suggest > > that it is per session, but holding/setup priorities are > the attributes > > of a LSP. > > so basically where to keep this Object,?? in PSB or Session??? > > > > Khuzema. > From owner-mpls@UU.NET Wed Jul 18 13:23: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 SMTP id NAA16572 for ; Wed, 18 Jul 2001 13:23: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 QQkyft10336; Wed, 18 Jul 2001 17:22:55 GMT Received: by mail-control.mail.uu.net id QQkyft03044 for mpls-outgoing; Wed, 18 Jul 2001 17:22: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 QQkyft03014 for ; Wed, 18 Jul 2001 17:22:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyft17048 for ; Wed, 18 Jul 2001 17:17:45 GMT Received: from web11706.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11706.mail.yahoo.com [216.136.172.72]) id QQkyft05137 for ; Wed, 18 Jul 2001 17:17:45 GMT Message-ID: <20010718171744.67644.qmail@web11706.mail.yahoo.com> Received: from [24.12.61.77] by web11706.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 10:17:44 PDT Date: Wed, 18 Jul 2001 10:17:44 -0700 (PDT) From: vola ray Subject: RE: doubt about implecit NULL label To: Javier Antich , mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkyft10336 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16572 Javier, As U wrote...... > "if QoS is bein implemented based on the exp bits of the MPLS header, > implicit null may break the path, so explicit null would (label 0) could be > used in these cases." Can U Clarify the above; Thanks in Advance, vola --- Javier Antich wrote: > It works exactly as you explain. As long as the Egress LER has to do IP > look-up (in case there was only one label) or other MPLS look-up (in case of > a label stack), and since some machines are not able to do MPLS > look-up+label poping+another IP/MPLS look-up in hardware/efficient way, it > is possible to make the penultimate LSR in the LSP to pop the outermost > label so that the Egress LER will do normal IP routing or will treat the > packet according to the next label in the stack (i.e. MPLS VPNs). In some > cases, if QoS is bein implemented based on the exp bits of the MPLS header, > implicit null may break the path, so explicit null would (label 0) could be > used in these cases. > > > ^ ^ > ==============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: siva Reddy [SMTP:reddy_lonka@yahoo.com] > > Enviado el: miércoles 18 de julio de 2001 10:41 > > Para: mpls@UU.NET > > Asunto: doubt about implecit NULL label > > > > Dear all, > > when we use implecit NULL (label valu 3) the > > penultimate HOP has to pop the label insted of > > replacing(swapping).afterwards it will be simply IP > > packet only.can penultimate HOP forward the IP packet > > to LSR. > > > > please clarify me about this implecit NULL concept. > > thanks in adv. > > regards > > lonka > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail > > http://personal.mail.yahoo.com/ ===== __________________________________________________________ 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 Jul 18 14:43: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 OAA02432 for ; Wed, 18 Jul 2001 14:43: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 QQkyfy06094; Wed, 18 Jul 2001 18:43:09 GMT Received: by mail-control.mail.uu.net id QQkyfy01584 for mpls-outgoing; Wed, 18 Jul 2001 18:42: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 QQkyfy01568 for ; Wed, 18 Jul 2001 18:42: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 QQkyfy18185 for ; Wed, 18 Jul 2001 18:41:28 GMT Received: from web20105.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20105.mail.yahoo.com [216.136.226.42]) id QQkyfy25281 for ; Wed, 18 Jul 2001 18:41:27 GMT Message-ID: <20010718184122.57151.qmail@web20105.mail.yahoo.com> Received: from [64.217.72.224] by web20105.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 11:41:22 PDT Date: Wed, 18 Jul 2001 11:41:22 -0700 (PDT) From: chaos is Subject: LDP question To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Greetings WG. I have a question that needs your enlightened opinion. Let's assume some core device (or P device) implements (or just activates) IS-IS TE and RSVP-TE. Now let's assume a network provider wants to provide RFC 2547-based VPNs or some other similar application requiring LDP utilizing the above core (or P) device. Does the core (or P) device need to implement (or activate) LDP? Lets assume the provider network consists of typical PE devices and perhaps another layer of P devices that support full functionality. If my question is not clear, I can restate. Cheers! __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 14:51:53 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 OAA03872 for ; Wed, 18 Jul 2001 14:51: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 QQkyfz14435; Wed, 18 Jul 2001 18:50:17 GMT Received: by mail-control.mail.uu.net id QQkyfz02500 for mpls-outgoing; Wed, 18 Jul 2001 18:49: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 QQkyfz02487 for ; Wed, 18 Jul 2001 18:49: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 QQkyfz01569 for ; Wed, 18 Jul 2001 18:49:08 GMT Received: from cod.ece.ucdavis.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cod.ece.ucdavis.edu [169.237.32.89]) id QQkyfz13151 for ; Wed, 18 Jul 2001 18:49:07 GMT Received: from localhost (wswen@localhost) by cod.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id LAA08162; Wed, 18 Jul 2001 11:48:51 -0700 (PDT) Date: Wed, 18 Jul 2001 11:48:51 -0700 (PDT) From: Wushao Wen To: chaos is cc: mpls@UU.NET Subject: Re: LDP question In-Reply-To: <20010718184122.57151.qmail@web20105.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Chaos, I think for the VPN, it only rely on the mpls switching table. LDP is not a requirement as long as we have some mechanism to distribute and setup label mapping table. In light of this, LDP is not a requirement because you have the RSVP-TE. Thanks! Wushao > Greetings WG. I have a question that needs your > enlightened opinion. Let's assume some core device (or > P device) implements (or just activates) IS-IS TE and > RSVP-TE. > > Now let's assume a network provider wants to provide > RFC 2547-based VPNs or some other similar application > requiring LDP utilizing the above core (or P) device. > > Does the core (or P) device need to implement (or > activate) LDP? Lets assume the provider network > consists of typical PE devices and perhaps another > layer of P devices that support full functionality. > > If my question is not clear, I can restate. > > Cheers! > > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > From owner-mpls@UU.NET Wed Jul 18 15:41: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 PAA14244 for ; Wed, 18 Jul 2001 15:41: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 QQkygc06462; Wed, 18 Jul 2001 19:40:25 GMT Received: by mail-control.mail.uu.net id QQkygc27474 for mpls-outgoing; Wed, 18 Jul 2001 19:39: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 QQkygc27460 for ; Wed, 18 Jul 2001 19:39: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 QQkygc23948 for ; Wed, 18 Jul 2001 19:38:54 GMT Received: from web20109.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20109.mail.yahoo.com [216.136.226.46]) id QQkygc11872 for ; Wed, 18 Jul 2001 19:38:54 GMT Message-ID: <20010718193853.64005.qmail@web20109.mail.yahoo.com> Received: from [64.217.72.224] by web20109.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 12:38:53 PDT Date: Wed, 18 Jul 2001 12:38:53 -0700 (PDT) From: chaos is Subject: Re: LDP question To: Wushao Wen 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 I understand your point and feel my question was not clear. Lets assume the servive provider MUST implement an LDP application PE to PE. Now lets assume there are two layers of P devices, core and distribution. Naturally the distribution P devices support LDP. So my question is this: Does the core P device need to support LDP? Or can this device function as a pure layer-2.5 switch without LDP enabled or implemented. Anyone? --- Wushao Wen wrote: > Chaos, > > I think for the VPN, it only rely on the mpls > switching table. LDP is not > a requirement as long as we have some mechanism to > distribute and setup > label mapping table. In light of this, LDP is not a > requirement because > you have the RSVP-TE. > > Thanks! > > > > Wushao > > > Greetings WG. I have a question that needs your > > enlightened opinion. Let's assume some core device > (or > > P device) implements (or just activates) IS-IS TE > and > > RSVP-TE. > > > > Now let's assume a network provider wants to > provide > > RFC 2547-based VPNs or some other similar > application > > requiring LDP utilizing the above core (or P) > device. > > > > Does the core (or P) device need to implement (or > > activate) LDP? Lets assume the provider network > > consists of typical PE devices and perhaps another > > layer of P devices that support full > functionality. > > > > If my question is not clear, I can restate. > > > > Cheers! > > > > > > > > __________________________________________________ > > 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 Wed Jul 18 15:51: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 SMTP id PAA17384 for ; Wed, 18 Jul 2001 15:51: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 QQkygd00128; Wed, 18 Jul 2001 19:50:37 GMT Received: by mail-control.mail.uu.net id QQkygd28756 for mpls-outgoing; Wed, 18 Jul 2001 19:49: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 QQkygd28735 for ; Wed, 18 Jul 2001 19:49: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 QQkygd06359 for ; Wed, 18 Jul 2001 19:46:38 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkygd17763 for ; Wed, 18 Jul 2001 19:46:38 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA26663 for ; Wed, 18 Jul 2001 15:46:37 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA05264 for mpls@uu.net; Wed, 18 Jul 2001 15:46:30 -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 QQkyfz02618 for ; Wed, 18 Jul 2001 18:50: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 QQkyfz24483 for ; Wed, 18 Jul 2001 18:47:54 GMT Received: from web14808.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14808.mail.yahoo.com [216.136.224.224]) id QQkyfz24290 for ; Wed, 18 Jul 2001 18:47:53 GMT Message-ID: <20010718184753.26594.qmail@web14808.mail.yahoo.com> Received: from [216.174.224.251] by web14808.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 11:47:53 PDT Date: Wed, 18 Jul 2001 11:47:53 -0700 (PDT) From: Vikas D Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. To: mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <20010717051426.5237.qmail@web14808.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk All, A small doubt in Section 2.5.2, "Transport Connection Establishment" of LDP RFC. It says: .............snip.................. "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency." .............snip.................... Now, under what circumstances would two LSRs, having multiple hello adjacencies , using same label spaces on all adjacencies try to establish multiple TCP sessions? Is this not already precluded by the following rule in the same section (Sec 2.5.2 of RFC 3036): .............snip.................. " 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b it attempts to open a TCP connection for a new LDP session with LSR2." .............snip.................. Thanks - Vikas __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 18:24:41 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 SAA20100 for ; Wed, 18 Jul 2001 18: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 QQkygn22533; Wed, 18 Jul 2001 22:22:48 GMT Received: by mail-control.mail.uu.net id QQkygn14223 for mpls-outgoing; Wed, 18 Jul 2001 22:21: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 QQkygn14215 for ; Wed, 18 Jul 2001 22:21: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 QQkygn24931 for ; Wed, 18 Jul 2001 22:21:35 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 QQkygn13810 for ; Wed, 18 Jul 2001 22:21:35 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 SAA17843 for ; Wed, 18 Jul 2001 18:19:49 -0400 (EDT) Subject: RSVP-TE and cr-ldp To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 18 Jul 2001 18:19:05 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/18/2001 06:19:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is there anyone can tell me if there is any LSR can support RSVP-TE and cr-ldp? Thanks in an advance. Julia From owner-mpls@UU.NET Wed Jul 18 19:10: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 TAA29012 for ; Wed, 18 Jul 2001 19:10: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 QQkygq28195; Wed, 18 Jul 2001 23:09:18 GMT Received: by mail-control.mail.uu.net id QQkygq07595 for mpls-outgoing; Wed, 18 Jul 2001 23:08: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 QQkygq07395 for ; Wed, 18 Jul 2001 23:07:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkygq21574 for ; Wed, 18 Jul 2001 23:06:36 GMT Received: from ganymede.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns01.or.intel.com [134.134.248.3]) id QQkygq26768 for ; Wed, 18 Jul 2001 23:06:36 GMT Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA23013; Wed, 18 Jul 2001 23:06:29 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 23:06:29 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id <3X1YFD1W>; Wed, 18 Jul 2001 16:06:27 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8900655DE32@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: rap@ops.ietf.org, mpls@UU.NET, te-wg@ops.ietf.org Subject: FW: I-D ACTION:draft-hegde-mpls-setup-pib-00.txt Date: Wed, 18 Jul 2001 16:06:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10FDE.417AD590" 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_01C10FDE.417AD590 Content-Type: text/plain; charset="iso-8859-1" Hi, Here is a way to setup MPLS LSPs. thanks, harsha -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 18, 2001 4:00 AM Subject: I-D ACTION:draft-hegde-mpls-setup-pib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MultiProtocol Label Switching (MPLS) Setup Policy Information Base Author(s) : H. Hegde, R. Sahita Filename : draft-hegde-mpls-setup-pib-00.txt Pages : 32 Date : 17-Jul-01 This document specifies a set of provisioning classes (PRC) for configuring a MultiProtocol Label Switching (MPLS) router. Instances of these classes reside in a virtual information store called MPLS Setup Policy Information Base (PIB). COPS protocol [COPS] with the extensions for provisioning [COPS-PR] is used to transmit this MPLS Setup policy information to MPLS Routers. The PRCs defined in this MPLS Setup PIB are intended for use by the COPS-PR MPLS client type. They complement the PRCs defined in the Framework PIB [FR-PIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hegde-mpls-setup-pib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hegde-mpls-setup-pib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hegde-mpls-setup-pib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C10FDE.417AD590 Content-Type: message/rfc822 To: Subject: Date: Wed, 18 Jul 2001 16:06:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C10FDE.417AD590" ------_=_NextPart_002_01C10FDE.417AD590 Content-Type: text/plain ------_=_NextPart_002_01C10FDE.417AD590 Content-Type: application/octet-stream; name="ATT10250" Content-Disposition: attachment; filename="ATT10250" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717133252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hegde-mpls-setup-pib-00.txt ------_=_NextPart_002_01C10FDE.417AD590 Content-Type: message/external-body; site="internet-drafts"; dir="draft-hegde-mpls-setup-pib-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C10FDE.417AD590-- ------_=_NextPart_000_01C10FDE.417AD590-- From owner-mpls@UU.NET Wed Jul 18 19:32: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 TAA06431 for ; Wed, 18 Jul 2001 19:32: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 QQkygq09067; Wed, 18 Jul 2001 23:07:52 GMT Received: by mail-control.mail.uu.net id QQkygq06261 for mpls-outgoing; Wed, 18 Jul 2001 23:07: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 QQkygq05603 for ; Wed, 18 Jul 2001 23:07: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 QQkygq09628 for ; Wed, 18 Jul 2001 23:06:52 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 QQkygq07706 for ; Wed, 18 Jul 2001 23:06:51 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 TAA27499; Wed, 18 Jul 2001 19:01:05 -0400 (EDT) Subject: RE: RSVP-TE and cr-ldp To: De Leo Walter Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 18 Jul 2001 19:00:21 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/18/2001 07:00:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA06431 Thanks, Julia De Leo Walter CA.COM.AR> cc: (bcc: Hong Liao/Telcordia) Subject: RE: RSVP-TE and cr-ldp 07/18/01 06:33 PM Unisphere ER-700 and ER-1400 > -----Mensaje original----- > De: Hong Liao [SMTP:hliao@telcordia.com] > Enviado el: Miércoles 18 de Julio de 2001 19:19 > Para: mpls@UU.NET > Asunto: RSVP-TE and cr-ldp > > Hi, > > Is there anyone can tell me if there is any LSR can support RSVP-TE and > cr-ldp? > > Thanks in an advance. > > Julia From owner-mpls@UU.NET Wed Jul 18 23:35: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 SMTP id XAA22215 for ; Wed, 18 Jul 2001 23:35: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 QQkyhi09174; Thu, 19 Jul 2001 03:35:26 GMT Received: by mail-control.mail.uu.net id QQkyhi24249 for mpls-outgoing; Thu, 19 Jul 2001 03:34: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 QQkyhi24240 for ; Thu, 19 Jul 2001 03:34:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyhi09429 for ; Thu, 19 Jul 2001 03:34:18 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 QQkyhi07817 for ; Thu, 19 Jul 2001 03:34:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA13378 for mpls@uu.net; Wed, 18 Jul 2001 23:34: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 QQkyhi24177 for ; Thu, 19 Jul 2001 03:33:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkyhi16518 for ; Thu, 19 Jul 2001 03:32:13 GMT Received: from thalia.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQkyhi29897 for ; Thu, 19 Jul 2001 03:32:13 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id DAA24615; Thu, 19 Jul 2001 03:32:03 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Jul 2001 03:32:03 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3ZBJJ3Q7>; Wed, 18 Jul 2001 20:32:01 -0700 Message-ID: From: "Sharma, Prem" To: "'Vikas D'" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: RFC : 3036 : Session establishment for multiple adjacencies. Date: Wed, 18 Jul 2001 20:31: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 Vikas, TCP connections are established between peer sessions and there could be multiple adjacencies under per session. The very fact the multiple adjacencies are control of one session implies that hellos sent over the adjacencies have the same LDP identifier. Irrespective of the no. of adjacencies, one TCP connection is good enough between peer sessions. If there is a one to one mapping between the physical interfaces of the machine and hello adjacencies, the label exchanged are applicable for all the interfaces under the control of session. Hope it clarifies. Prem -----Original Message----- From: Vikas D [mailto:vikdw@yahoo.com] Sent: Wednesday, July 18, 2001 11:48 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. All, A small doubt in Section 2.5.2, "Transport Connection Establishment" of LDP RFC. It says: .............snip.................. "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency." .............snip.................... Now, under what circumstances would two LSRs, having multiple hello adjacencies , using same label spaces on all adjacencies try to establish multiple TCP sessions? Is this not already precluded by the following rule in the same section (Sec 2.5.2 of RFC 3036): .............snip.................. " 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b it attempts to open a TCP connection for a new LDP session with LSR2." .............snip.................. Thanks - Vikas __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 18 23:41: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 XAA23555 for ; Wed, 18 Jul 2001 23:40: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 QQkyhi05462; Thu, 19 Jul 2001 03:40:56 GMT Received: by mail-control.mail.uu.net id QQkyhi24817 for mpls-outgoing; Thu, 19 Jul 2001 03:40: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 QQkyhi24807 for ; Thu, 19 Jul 2001 03:40: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 QQkyhi17179 for ; Thu, 19 Jul 2001 03:39:36 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 QQkyhi14529 for ; Thu, 19 Jul 2001 03:39:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA14007 for mpls@uu.net; Wed, 18 Jul 2001 23:39:35 -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 QQkyhi24655 for ; Thu, 19 Jul 2001 03:38: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 QQkyhi13269 for ; Thu, 19 Jul 2001 03:36:39 GMT Received: from rumor.cps.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rumor.cps.intel.com [192.102.198.242]) id QQkyhi02841 for ; Thu, 19 Jul 2001 03:36:38 GMT Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id DAA07180; Thu, 19 Jul 2001 03:36:18 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Jul 2001 03:36:20 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 20:36:19 -0700 Message-ID: From: "Sharma, Prem" To: "'Hong Liao'" , mpls@UU.NET Subject: RE: RSVP-TE and cr-ldp Date: Wed, 18 Jul 2001 20:36:18 -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 feel, it's very much possible for an LSR to support both RSVP-TE and CR-LDP signalling protocols but one would have to take care of resource partitioning (assignment of label ranges) between the signalling modules. Prem -----Original Message----- From: Hong Liao [mailto:hliao@telcordia.com] Sent: Wednesday, July 18, 2001 3:19 PM To: mpls@UU.NET Subject: RSVP-TE and cr-ldp Hi, Is there anyone can tell me if there is any LSR can support RSVP-TE and cr-ldp? Thanks in an advance. Julia From owner-mpls@UU.NET Wed Jul 18 23:57: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 XAA27593 for ; Wed, 18 Jul 2001 23:57: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 QQkyhj16492; Thu, 19 Jul 2001 03:56:53 GMT Received: by mail-control.mail.uu.net id QQkyhj26748 for mpls-outgoing; Thu, 19 Jul 2001 03:56: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 QQkyhj26691 for ; Thu, 19 Jul 2001 03:56:05 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 QQkyhj11975 for ; Thu, 19 Jul 2001 03:55:52 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 QQkyhj18738 for ; Thu, 19 Jul 2001 03:55:51 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6J9Yiu24205 for ; Thu, 19 Jul 2001 09:34:45 GMT Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GGPCJ800.S08; Thu, 19 Jul 2001 09:31:56 +0530 Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id EAA15554; Thu, 19 Jul 2001 04:34:55 +0530 Date: Thu, 19 Jul 2001 09:32:39 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: Vikas D cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. In-Reply-To: <20010718184753.26594.qmail@web14808.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 18 Jul 2001, Vikas D wrote: Hi Vinod, LSR will not try to establish multiple sessions for the multiple adjacencies under no conditions. The requirement for "An LSR MUST advertise the same transport address in all Hellos" is due to the fact if the LSR advertises diff transport address in diff hello adjacencies, the role of the LSR will not be defined same on all adjacencies, it may be active on one while on the other it may be passive. Now when the LSR is passive on other adjacencies, the peer may try to establish the session, which may result in setting up multiple session. Hope this clears ur doubts.. Thanks Chetan S > All, > > A small doubt in Section 2.5.2, "Transport Connection > Establishment" > of LDP RFC. It says: > > .............snip.................. > "An LSR MUST advertise the same transport address in all Hellos that > advertise the same label space. This requirement ensures that two > LSRs linked by multiple Hello adjacencies using the same label > spaces > play the same connection establishment role for each adjacency." > .............snip.................... > > > > Now, under what circumstances would two LSRs, having multiple > hello adjacencies , using same label spaces on all adjacencies > try to establish multiple TCP sessions? > > Is this not already precluded by the following rule in the same > section (Sec 2.5.2 of RFC 3036): > > .............snip.................. > " 1. If LSR1 does not already have an LDP session for the exchange > of label spaces LSR1:a and LSR2:b it attempts to open a TCP > connection for a new LDP session with LSR2." > .............snip.................. > > > Thanks > - Vikas > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > From owner-mpls@UU.NET Thu Jul 19 00:25: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 AAA04002 for ; Thu, 19 Jul 2001 00:25: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 QQkyhl11263; Thu, 19 Jul 2001 04:25:24 GMT Received: by mail-control.mail.uu.net id QQkyhl19459 for mpls-outgoing; Thu, 19 Jul 2001 04:24: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 QQkyhl19451 for ; Thu, 19 Jul 2001 04:24:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyhl20977 for ; Thu, 19 Jul 2001 04:21:24 GMT From: Vijayamrit@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 QQkyhl08724 for ; Thu, 19 Jul 2001 04:21:22 GMT Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19) id <354Q6S39>; Thu, 19 Jul 2001 09:54:25 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C5687809BFF@HUAWEIMAIL> To: ml_manishg@yahoo.com Cc: mpls@UU.NET Subject: RE: [MPLS] Popping Multiple Labels Date: Thu, 19 Jul 2001 09:54:24 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1100E.E1C8E2F0" 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_01C1100E.E1C8E2F0 Content-Type: text/plain; charset="iso-8859-1" Hi, I am not sure if this will help you but this is what I once thought to avoid multiple lookup in the table. If the problem in multi-level pop is looking up the table after each pop the algorithm below might help you. (In this multi-level pop I am not talking about the penultimate popping) This is the algorithm, I thought: The labels that are popped have the following nature: The label terminates a LSP at the router assigning them. The action associated with the top label, is to pop the label and examine the inner header. The inner header may be an MPLS label which might be of the same type i.e. pop the label and examine the inner header for next action. This may go on, until we reach a label which need to be swapped or need to be popped and forwarded or we end up with an IP header. All such labels which are being popped this way have few things in common: --They are assigned by the router popping them. -- The LSP terminates at the router that is popping them. -- Action associated with the label is to examine the inner header. (If you are not concerned about debugability, indeed you can use just one label value for all such labels.) Since the router is assigning the label, it can reserve a range say 10000-20000 for all such labels. When Router receives an MPLS packet with label between 10000-20000, it can just pop it and examine if the inner label. If the inner label is again in the range 10000-20000 it can again pop it. This way Router can avoid a table lookup for popping multiple labels and can just examine the range which I assumed would be faster. Note: This will interoperate even if some other router is assigning label from the same range i.e. say there is another router which assigns a label 10001. This should not concern the router as it is only going to decide things based on the labels assigned by it and not by some other router. Vijay -----Original Message----- From: Manish Godara [mailto:ml_manishg@yahoo.com] Sent: Wednesday, July 18, 2001 9:22 PM To: Jiang, Donghua (Donghua) Cc: 'mpls@uu.net' Subject: RE: [MPLS] Popping Multiple Labels Hi Jane, Apologies for the confusion. I meant T2 is tunneled inside T2. Thanks for the clarification. So it is possible to pop two labels at one LSR. Now I wonder if it is efficient to implement this in hardware. thanks, manish ------------- your mail ---------------- Manish, When you say "T2 is tunneled over T1", do you mean T1 is tunneled inside T2 or T2 is tunneled inside T1? After I sent out the email yesterday, I was getting suspicious about what I said. If T1 is tunneled inside T2, then the packets are traveling from L1 to L3, the MPLS label used for T2 will always be the top label and forwarding will be based on the top label, we would not care about the existence of T1. So, T1 will not be involved when packets travels from L1 to L3. If T2 is tunneled inside T1, then from L1 to L21, packets will be forwarded based on the MPLS labels for T2. When packets get to L21, one more layer of label will be pushed on and packet forwarding will be based on the newly added label layer. When packets get to L22, the top layer will be popped as it is the end of the tunnel T1. Also, due to the negotiation between L22 and L3, the current top label should also be popped before the packets are forwarded to L3. Hope you did not mean to play the trick :-) Regards, Jane -----Original Message----- From: wiseguy@cs.stanford.edu [mailto:wiseguy@cs.stanford.edu] Sent: Tuesday, July 17, 2001 12:06 PM To: mpls@UU.NET Subject: [MPLS] Popping Multiple Labels Hi, I was wondering if there are any possible scenarios in which a node might pop multiple labels from the stack. One case I was thinking of is : a node is endpoint of a tunnel (T1) and is also a penultimate hop for another tunnel (T2) and T2 is tunneled over T1! Maybe this is not a valid scenario but I would like to check. I appreciate any help. thanks, manish PS: Scenario +-----+ +-------+ +-------+ +------+ | | ===~== | | ====~~=== | +---------+ | | L1 | | L21 | | L2n | | L3 | +-----+ +-------+ +-------+ +------+ <------------ T1 --------------> <--------------------------T2----------------------> __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ------_=_NextPart_001_01C1100E.E1C8E2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MPLS] Popping Multiple Labels

Hi,
I am not sure if this will help you but this is what = I once thought to avoid multiple lookup in the table. If the problem in = multi-level pop is looking up the table after each pop the algorithm = below might help you. (In this multi-level pop I am not talking about = the penultimate popping)

This is the algorithm, I thought:
The labels that are popped have the following = nature:
The label terminates a LSP at the router assigning = them. The action associated with the top label, is to pop the label and = examine the inner header.

The inner header may be an MPLS label which might be = of the same type i.e. pop the label and examine the inner header for = next action. This may go on, until we reach a label which need to be = swapped or need to be popped and forwarded or we end up with an IP = header.

All such labels which are being popped this way have = few things in common:
--They are assigned by the router popping = them.
-- The LSP terminates at the router that is popping = them.
-- Action associated with the label is to examine = the inner header.
(If you are not concerned about debugability, indeed = you can use just one label value for all such labels.)
Since the router is assigning the label, it can = reserve a range say 10000-20000 for all such labels.
When Router receives an MPLS packet with label = between 10000-20000, it can just pop it and examine if the inner label. = If the inner label is again in the range 10000-20000 it can again pop = it. This way Router can avoid a table lookup for popping multiple = labels and can just examine the range which I assumed would be = faster.

Note: This will interoperate even if some other = router is assigning label from the same range i.e. say there is another = router which assigns a label 10001. This should not concern the router = as it is only going to decide things based on the labels assigned by it = and not by some other router.

Vijay
-----Original Message-----
From: Manish Godara [mailto:ml_manishg@yahoo.com]
Sent: Wednesday, July 18, 2001 9:22 PM
To: Jiang, Donghua (Donghua)
Cc: 'mpls@uu.net'
Subject: RE: [MPLS] Popping Multiple Labels



Hi Jane,

Apologies for the confusion.  I meant T2 is = tunneled
inside T2.  Thanks for the clarification.  = So it is
possible to pop two labels at one LSR.  Now I = wonder
if it is efficient to implement this in = hardware.

thanks,
manish

------------- your mail ----------------

Manish,

When you say "T2 is tunneled over T1", do = you mean T1
is tunneled inside T2
or T2 is tunneled inside T1?

After I sent out the email yesterday, I was = getting
suspicious about what I
said.  If T1 is tunneled inside T2, then the = packets
are traveling from L1
to L3, the MPLS label used for T2 will always be = the
top label and
forwarding will be based on the top label, we = would
not care about the
existence of T1.  So, T1 will not be involved = when
packets travels from L1
to L3.  If T2 is tunneled inside T1, then from = L1 to
L21, packets will be
forwarded based on the MPLS labels for T2.  = When
packets get to L21, one
more layer of label will be pushed on and = packet
forwarding will be based on
the newly added label layer.  When packets get = to L22,
the top layer will be
popped as it is the end of the tunnel T1.  = Also, due
to the negotiation
between L22 and L3, the current top label should = also
be popped before the
packets are forwarded to L3.

Hope you did not mean to play the trick :-)

Regards,
Jane

-----Original Message-----
From: wiseguy@cs.stanford.edu
[mailto:wiseguy@cs.stanford.edu]
Sent: Tuesday, July 17, 2001 12:06 PM
To: mpls@UU.NET
Subject: [MPLS] Popping Multiple Labels



Hi,

I was wondering if there are any possible scenarios = in
which
a node might pop multiple labels from the = stack.  One
case
I was thinking of is : a node is endpoint of a = tunnel
(T1) and
is also a penultimate hop for another tunnel (T2) = and
T2 is
tunneled over T1!  Maybe this is not a valid = scenario
but I
would like to check.

I appreciate any help.

thanks,
manish

PS: Scenario


  = +-----+         = +-------+          &nb= sp;    +-------+  
     +------+
  |     | = =3D=3D=3D~=3D=3D  |       |  = =3D=3D=3D=3D~~=3D=3D=3D    = |     
+---------+      |
  | L1  = |         | L21   = |            = ;   | L2n   |  
     | L3   |
  = +-----+         = +-------+          &nb= sp;    +-------+  
     +------+

          &nb= sp;       <------------  T1 = -------------->
       
<--------------------------T2---------------------= ->



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

------_=_NextPart_001_01C1100E.E1C8E2F0-- From owner-mpls@UU.NET Thu Jul 19 01:12: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 BAA11642 for ; Thu, 19 Jul 2001 01:12: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 QQkyho24010; Thu, 19 Jul 2001 05:12:04 GMT Received: by mail-control.mail.uu.net id QQkyho13486 for mpls-outgoing; Thu, 19 Jul 2001 05:11: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 QQkyho13426 for ; Thu, 19 Jul 2001 05:11:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyho10677 for ; Thu, 19 Jul 2001 05:10:16 GMT Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkyho21940 for ; Thu, 19 Jul 2001 05:10:13 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6J563608132; Thu, 19 Jul 2001 10:36:03 +0530 Message-ID: <3B566C92.A3E55DDA@multitech.co.in> Date: Thu, 19 Jul 2001 10:43:54 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sharma, Prem" CC: "'Hong Liao'" , mpls@UU.NET Subject: Re: RSVP-TE and cr-ldp References: Content-Type: multipart/alternative; boundary="------------68F7D526EE92258815DC4D21" Sender: owner-mpls@UU.NET Precedence: bulk --------------68F7D526EE92258815DC4D21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julia, I guess yes,but maybe one should have separate label pools. I also remember one can do Interworking between CR-LDP and RSVP-TE ,each running on separate routers. Regards, Abhay "Sharma, Prem" wrote: > Hi, > > I feel, it's very much possible for an LSR to support both RSVP-TE and > CR-LDP signalling protocols but one would have to take care of resource > partitioning (assignment of label ranges) between the signalling modules. > > Prem > > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: Wednesday, July 18, 2001 3:19 PM > To: mpls@UU.NET > Subject: RSVP-TE and cr-ldp > > Hi, > > Is there anyone can tell me if there is any LSR can support RSVP-TE and > cr-ldp? > > Thanks in an advance. > > Julia --------------68F7D526EE92258815DC4D21 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Julia,
     I guess yes,but maybe one should have separate label pools.
     I also remember one can do Interworking between CR-LDP and RSVP-TE ,each running on separate
     routers.
     Regards,
     Abhay
 


"Sharma, Prem" wrote:

Hi,

I feel, it's very much possible for an LSR to support both RSVP-TE and
CR-LDP signalling protocols but one would have to take care of resource
partitioning (assignment of label ranges) between the signalling modules.

Prem

-----Original Message-----
From: Hong Liao [mailto:hliao@telcordia.com]
Sent: Wednesday, July 18, 2001 3:19 PM
To: mpls@UU.NET
Subject: RSVP-TE and cr-ldp

Hi,

Is there anyone can tell me if there is any LSR can support RSVP-TE and
cr-ldp?

Thanks in an advance.

Julia

--------------68F7D526EE92258815DC4D21-- From owner-mpls@UU.NET Thu Jul 19 02:01: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 CAA00158 for ; Thu, 19 Jul 2001 02:01:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyhs29610; Thu, 19 Jul 2001 06:01:34 GMT Received: by mail-control.mail.uu.net id QQkyhs22274 for mpls-outgoing; Thu, 19 Jul 2001 06:01:01 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 QQkyhs21640 for ; Thu, 19 Jul 2001 06:00: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 QQkyhs26873 for ; Thu, 19 Jul 2001 06:00:10 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 QQkyhs22484 for ; Thu, 19 Jul 2001 06:00:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA21681 for mpls@uu.net; Thu, 19 Jul 2001 02:00:09 -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 QQkyhr18675 for ; Thu, 19 Jul 2001 05:59: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 QQkyhr09819 for ; Thu, 19 Jul 2001 05:58:59 GMT Received: from hebe.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns02.or.intel.com [134.134.248.4]) id QQkyhr27696 for ; Thu, 19 Jul 2001 05:58:58 GMT Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id FAA06675; Thu, 19 Jul 2001 05:58:42 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Jul 2001 05:58:42 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id <3X14R56Q>; Wed, 18 Jul 2001 22:58:40 -0700 Message-ID: From: "Sharma, Prem" To: "'Vikas D'" Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: RFC : 3036 : Session establishment for multiple adjacencies. Date: Wed, 18 Jul 2001 22:58:37 -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 Vikas, As Chetan has also correctly pointed out in his mail that transport address plays a vital role in establishing "active"/"passive" relationship between nodes and establishment of TCP connection. The lines you mentioned should be read in totality with reference to transport address. As the Transport addresses are going to be the same, carried in each hello over each adjacency, each adjacency would be aware which is the active (or passive) node. Otherwise, for some adjacencies, the node might have acted as active and for others, the node have acted passive - slightly unmanageable/un-necessary complex situation. Prem -----Original Message----- From: Vikas D [mailto:vikdw@yahoo.com] Sent: Wednesday, July 18, 2001 8:55 PM To: Sharma, Prem Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: RFC : 3036 : Session establishment for multiple adjacencies. Prem, That's what my question is. We both agree that if the LDP identifier is same, there needs to be one session. Then, why does the LDP RFC talk about trying to establish multiple sessions for two LSRs linked by multiple Hello adjacencies using the same label spaces. Read the following line carefully: "This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency." I was thinking about it and the only reason (it is a very good reason though) I could think of was to take care of the race condition that may arise when both the transport addresses on the hello adjacencies are different and each of them acts as master for one of the adjacencies. Hope I got it right. Thanks - Vikas --- "Sharma, Prem" wrote: > Hi Vikas, > > TCP connections are established between peer sessions and there > could be > multiple adjacencies under per session. The very fact the multiple > adjacencies are control of one session implies that hellos sent > over the > adjacencies have the same LDP identifier. Irrespective of the no. > of > adjacencies, one TCP connection is good enough between peer > sessions. If > there is a one to one mapping between the physical interfaces of > the machine > and hello adjacencies, the label exchanged are applicable for all > the > interfaces under the control of session. > > Hope it clarifies. > Prem > > > > -----Original Message----- > From: Vikas D [mailto:vikdw@yahoo.com] > Sent: Wednesday, July 18, 2001 11:48 AM > To: mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: RFC : 3036 : Session establishment for multiple > adjacencies. > > > All, > > A small doubt in Section 2.5.2, "Transport Connection > Establishment" > of LDP RFC. It says: > > .............snip.................. > "An LSR MUST advertise the same transport address in all Hellos > that > advertise the same label space. This requirement ensures that > two > LSRs linked by multiple Hello adjacencies using the same label > spaces > play the same connection establishment role for each adjacency." > .............snip.................... > > > > Now, under what circumstances would two LSRs, having multiple > hello adjacencies , using same label spaces on all adjacencies > try to establish multiple TCP sessions? > > Is this not already precluded by the following rule in the same > section (Sec 2.5.2 of RFC 3036): > > .............snip.................. > " 1. If LSR1 does not already have an LDP session for the > exchange > of label spaces LSR1:a and LSR2:b it attempts to open a TCP > connection for a new LDP session with LSR2." > .............snip.................. > > > Thanks > - Vikas > > > __________________________________________________ > 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 Thu Jul 19 03:36: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 DAA23931 for ; Thu, 19 Jul 2001 03:36: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 QQkyhy12739; Thu, 19 Jul 2001 07:36:04 GMT Received: by mail-control.mail.uu.net id QQkyhy07750 for mpls-outgoing; Thu, 19 Jul 2001 07:35: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 QQkyhy07733 for ; Thu, 19 Jul 2001 07:35:18 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 QQkyhy13492 for ; Thu, 19 Jul 2001 07:34:59 GMT Received: from samar.sasken.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkyhy11542 for ; Thu, 19 Jul 2001 07:34:56 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f6J7YWg20368; Thu, 19 Jul 2001 13:04:32 +0530 (IST) Received: from sasken.com (pcka172.sasi.com [10.0.82.172]) by sunk3.sasi.com (8.9.3/8.9.3) with ESMTP id NAA06397; Thu, 19 Jul 2001 13:04:28 +0530 (IST) Message-ID: <3B568DBA.1B65F986@sasken.com> Date: Thu, 19 Jul 2001 13:05:22 +0530 From: Rajesh P Jain Organization: SASKEN Communication Technologies Ltd X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls@uu.net'" CC: "Feng, Mark" , "'Ping Pan'" Subject: Re: Session Attributes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Hi", I would also like to know if this Session Attribute OBJECT anyway helpful in Rerouting Traffic Engineered Tunnels?? Is the information present in this object anyway useful in "make-before-break" concept? TIA Rajesh P Jain "Feng, Mark" wrote: > Ping, > > I know the name implies the attributes belong to the session. But does it > mean all senders, i.e. ingress routers, need to have the same session > attributes? Should the transit nodes reject the new Path message, if the > session attributes are different from other senders of the same session, > because there is no rule on "merging" the session attributes? > > Thanks. > > - Mark > > > -----Original Message----- > > From: Ping Pan [mailto:pingpan@juniper.net] > > Sent: Tuesday, July 17, 2001 9:37 PM > > To: Khuzema Pithewan > > Cc: rsvp@ISI.EDU > > Subject: Re: Session Attributes > > > > > > Khuzema, > > > > First, this question should go to the mpls list. Please forward the > > discussion to that list. Second, the question itself is implementation > > dependent. Finally, since the Session Attribute object is to describe > > the properties of a RSVP session, in a normal implementation, > > it should > > be kept where you keep the session. > > > > - Ping > > > > Khuzema Pithewan wrote: > > > > > > Hi, > > > > > > Session Attribute Object in RSVP-TE contains some flags , setup and > > > holding priority and some session related info. > > > > > > My doubt is , if this object is per session or per LSP, > > because name > > > suggest > > > that it is per session, but holding/setup priorities are > > the attributes > > > of a LSP. > > > so basically where to keep this Object,?? in PSB or Session??? > > > > > > Khuzema. > > From owner-mpls@UU.NET Thu Jul 19 04:23: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 EAA29159 for ; Thu, 19 Jul 2001 04:23: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 QQkyib02995; Thu, 19 Jul 2001 08:22:50 GMT Received: by mail-control.mail.uu.net id QQkyib02562 for mpls-outgoing; Thu, 19 Jul 2001 08:22: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 QQkyib02555 for ; Thu, 19 Jul 2001 08:22: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 QQkyib14343 for ; Thu, 19 Jul 2001 08:19:22 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 QQkyib28307 for ; Thu, 19 Jul 2001 08:19:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA27631 for mpls@uu.net; Thu, 19 Jul 2001 04:19:21 -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 QQkyib02205 for ; Thu, 19 Jul 2001 08:18: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 QQkyib26371 for ; Thu, 19 Jul 2001 08:18:36 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQkyib17601 for ; Thu, 19 Jul 2001 08:18:36 GMT Received: from amsterdam.cisco.com (amsterdam.cisco.com [144.254.74.238]) by ogma.cisco.com (Postfix) with ESMTP id CC280F1; Thu, 19 Jul 2001 10:18:35 +0200 (MET DST) Received: from WDEC-W2K.cisco.com (wdec-isdn-home4.cisco.com [10.49.72.21]) by amsterdam.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA23374; Thu, 19 Jul 2001 10:18:34 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010719100525.055f0ee0@amsterdam.cisco.com> X-Sender: wdec@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 10:18:21 +0200 To: chaos is , Wushao Wen From: Wojciech Dec Subject: Re: LDP question Cc: mpls@UU.NET In-Reply-To: <20010718193853.64005.qmail@web20109.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Theoretically the VPN will work as long as you do not uncover the VPN label anywhere but the destination PE. Now in your scheme the source PE will impose a VPN label + a label (distributed by LDP) corresponding to the destination PE. This will get sent out. From hereon I'm still not clear about your question. The only reasonable possibility that come to my mind is: The LDP capable P devices are doing TE (across the non LDP enabled network), and have LDP sessions running between TE head and tail ends. The TE head-end should thus be able to add a 3rd label to the stack (the TE label). Regards, Woj. At 12:38 18/07/2001 -0700, chaos is wrote: >I understand your point and feel my question was not >clear. Lets assume the servive provider MUST implement >an LDP application PE to PE. Now lets assume there are >two layers of P devices, core and distribution. >Naturally the distribution P devices support LDP. So >my question is this: > >Does the core P device need to support LDP? Or can >this device function as a pure layer-2.5 switch >without LDP enabled or implemented. > >Anyone? > > >--- Wushao Wen wrote: > > Chaos, > > > > I think for the VPN, it only rely on the mpls > > switching table. LDP is not > > a requirement as long as we have some mechanism to > > distribute and setup > > label mapping table. In light of this, LDP is not a > > requirement because > > you have the RSVP-TE. > > > > Thanks! > > > > > > > > Wushao > > > > > Greetings WG. I have a question that needs your > > > enlightened opinion. Let's assume some core device > > (or > > > P device) implements (or just activates) IS-IS TE > > and > > > RSVP-TE. > > > > > > Now let's assume a network provider wants to > > provide > > > RFC 2547-based VPNs or some other similar > > application > > > requiring LDP utilizing the above core (or P) > > device. > > > > > > Does the core (or P) device need to implement (or > > > activate) LDP? Lets assume the provider network > > > consists of typical PE devices and perhaps another > > > layer of P devices that support full > > functionality. > > > > > > If my question is not clear, I can restate. > > > > > > Cheers! > > > > > > > > > > > > __________________________________________________ > > > 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/ _________________________________________________________ Wojciech Dec CCIE# 5563 Phone: +31 (0)20 342 3034 Network Consulting Engineer Mobile: +31 (0)622 466 802 Cisco Systems, E-Mail: wdec@cisco.com PO Box 22514, 1100 DA Amsterdam The Netherlands From owner-mpls@UU.NET Thu Jul 19 07:10: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 HAA29805 for ; Thu, 19 Jul 2001 07:10:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyim06646; Thu, 19 Jul 2001 11:10:10 GMT Received: by mail-control.mail.uu.net id QQkyim18064 for mpls-outgoing; Thu, 19 Jul 2001 11:09:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkyim17873 for ; Thu, 19 Jul 2001 11:09:06 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 QQkyim10818 for ; Thu, 19 Jul 2001 11:07: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 QQkyim26424 for ; Thu, 19 Jul 2001 11:07:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA03974 for mpls@uu.net; Thu, 19 Jul 2001 07:07: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 QQkyim12498 for ; Thu, 19 Jul 2001 11:06:27 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 QQkyim00817 for ; Thu, 19 Jul 2001 11:05:22 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkyim29886 for ; Thu, 19 Jul 2001 11:05:21 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27793; Thu, 19 Jul 2001 07:04:25 -0400 (EDT) Message-Id: <200107191104.HAA27793@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-atlas-rsvp-local-protect-interop-00.txt Date: Thu, 19 Jul 2001 07:04:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute Author(s) : A. Atlas et al. Filename : draft-atlas-rsvp-local-protect-interop-00.txt Pages : 15 Date : 18-Jul-01 Routers implementing the local protection enhancements given in [draft-ietf-mpls-rsvp-lsp-tunnel-08.txt], whose usage is clarified in [draft-swallow-rsvp-bypass-label-01.txt], and routers implementing solely [draft-gan-fast-reroute-00.txt] do not interoperate to provide local protection. Those routers which follow the guidelines given in this draft should be able to interoperate with either type of implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-atlas-rsvp-local-protect-interop-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atlas-rsvp-local-protect-interop-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-atlas-rsvp-local-protect-interop-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010718141956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-atlas-rsvp-local-protect-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-atlas-rsvp-local-protect-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718141956.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 19 08:43: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 SMTP id IAA15680 for ; Thu, 19 Jul 2001 08:43: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 QQkyis25487; Thu, 19 Jul 2001 12:42:59 GMT Received: by mail-control.mail.uu.net id QQkyis17789 for mpls-outgoing; Thu, 19 Jul 2001 12:42: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 QQkyis17783 for ; Thu, 19 Jul 2001 12:42: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 QQkyis29314 for ; Thu, 19 Jul 2001 12:40:46 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkyis07510 for ; Thu, 19 Jul 2001 12:40:45 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 IAA23456; Thu, 19 Jul 2001 08:36:13 -0400 (EDT) Subject: Re: RSVP-TE and cr-ldp To: abhay Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 19 Jul 2001 08:35:29 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/19/2001 08:35:31 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=85256A8E00450B348f9e8a93df938690918c85256A8E00450B34" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=85256A8E00450B348f9e8a93df938690918c85256A8E00450B34 Content-type: text/plain; charset=us-ascii Abhay, Can you tell me if there is any vendor who can support RSVP-TE? Thanks in an advance. Julia abhay ech.co.in> cc: "'Hong Liao'" , mpls@UU.NET, (bcc: Hong Liao/Telcordia) 07/19/01 Subject: Re: RSVP-TE and cr-ldp 01:13 AM Julia, I guess yes,but maybe one should have separate label pools. I also remember one can do Interworking between CR-LDP and RSVP-TE ,each running on separate routers. Regards, Abhay "Sharma, Prem" wrote: > Hi, > > I feel, it's very much possible for an LSR to support both RSVP-TE and > CR-LDP signalling protocols but one would have to take care of resource > partitioning (assignment of label ranges) between the signalling modules. > > Prem > > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: Wednesday, July 18, 2001 3:19 PM > To: mpls@UU.NET > Subject: RSVP-TE and cr-ldp > > Hi, > > Is there anyone can tell me if there is any LSR can support RSVP-TE and > cr-ldp? > > Thanks in an advance. > > Julia --0__=85256A8E00450B348f9e8a93df938690918c85256A8E00450B34 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KDQo8cHJlPkp1bGlhLDwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBJIGd1ZXNzIHllcyxidXQgbWF5YmUgb25lIHNob3VsZCBoYXZlIHNlcGFyYXRl IGxhYmVsIHBvb2xzLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGFs c28gcmVtZW1iZXIgb25lIGNhbiBkbyBJbnRlcndvcmtpbmcgYmV0d2VlbiBDUi1MRFAgYW5kIFJT VlAtVEUgLGVhY2ggcnVubmluZyBvbiBzZXBhcmF0ZTwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyByb3V0ZXJzLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBSZWdhcmRzLDwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBYmhh eTwvcHJlPg0KDQo8cHJlPiZuYnNwOzwvcHJlPg0KDQo8cD48YnI+IlNoYXJtYSwgUHJlbSIgd3Jv dGU6DQo8YmxvY2txdW90ZSBUWVBFPUNJVEU+SGksDQo8cD5JIGZlZWwsIGl0J3MgdmVyeSBtdWNo IHBvc3NpYmxlIGZvciBhbiBMU1IgdG8gc3VwcG9ydCBib3RoIFJTVlAtVEUgYW5kDQo8YnI+Q1It TERQIHNpZ25hbGxpbmcgcHJvdG9jb2xzIGJ1dCBvbmUgd291bGQgaGF2ZSB0byB0YWtlIGNhcmUg b2YgcmVzb3VyY2UNCjxicj5wYXJ0aXRpb25pbmcgKGFzc2lnbm1lbnQgb2YgbGFiZWwgcmFuZ2Vz KSBiZXR3ZWVuIHRoZSBzaWduYWxsaW5nIG1vZHVsZXMuDQo8cD5QcmVtDQo8cD4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPGJyPkZyb206IEhvbmcgTGlhbyBbPGEgaHJlZj0ibWFpbHRvOmhs aWFvQHRlbGNvcmRpYS5jb20iPm1haWx0bzpobGlhb0B0ZWxjb3JkaWEuY29tPC9hPl0NCjxicj5T ZW50OiBXZWRuZXNkYXksIEp1bHkgMTgsIDIwMDEgMzoxOSBQTQ0KPGJyPlRvOiBtcGxzQFVVLk5F VA0KPGJyPlN1YmplY3Q6IFJTVlAtVEUgYW5kIGNyLWxkcA0KPHA+SGksDQo8cD5JcyB0aGVyZSBh bnlvbmUgY2FuIHRlbGwgbWUgaWYgdGhlcmUgaXMgYW55IExTUiBjYW4gc3VwcG9ydCBSU1ZQLVRF DQphbmQNCjxicj5jci1sZHA/DQo8cD5UaGFua3MgaW4gYW4gYWR2YW5jZS4NCjxwPkp1bGlhPC9i bG9ja3F1b3RlPg0KPC9odG1sPg0KDQo= --0__=85256A8E00450B348f9e8a93df938690918c85256A8E00450B34-- From owner-mpls@UU.NET Thu Jul 19 10:23: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 SMTP id KAA10714 for ; Thu, 19 Jul 2001 10:23: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 QQkyiz09680; Thu, 19 Jul 2001 14:22:42 GMT Received: by mail-control.mail.uu.net id QQkyiz08167 for mpls-outgoing; Thu, 19 Jul 2001 14: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 QQkyiz08130 for ; Thu, 19 Jul 2001 14:21: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 QQkyiz14009 for ; Thu, 19 Jul 2001 14:19:47 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 QQkyiz00766 for ; Thu, 19 Jul 2001 14:19:46 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14535 for ; Thu, 19 Jul 2001 10:19:46 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08096 for mpls@uu.net; Thu, 19 Jul 2001 10:19:38 -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 QQkyhk01622 for ; Thu, 19 Jul 2001 04:01:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyhj15407 for ; Thu, 19 Jul 2001 03:58:08 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQkyhj18030 for ; Thu, 19 Jul 2001 03:58:06 GMT Received: from netbrahma.com (khuzema.netbrahma.com [172.16.72.170]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBLHLJG; Thu, 19 Jul 2001 09:26:02 +0530 Message-ID: <3B565A6E.3CA17D38@netbrahma.com> Date: Thu, 19 Jul 2001 09:26:30 +0530 From: Khuzema Pithewan Organization: Netbrahma Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Feng, Mark" CC: "'Ping Pan'" , "'mpls@uu.net'" Subject: Re: Session Attributes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am given to understand that, when RSVP-TE works with MPLS, the LSP setup is control driven, means, there should be some Administrator which is responsible to configure the session attributes for the session, if administrator wants to give different session attributes for the path messages grouped on per ingress basis, then Extended tunnel Id can be used. Now if there is case of reception of PATH messages with different session attributes in same session, then its a result of mis-configuration and I believe in that case path message should be dropped. But again if(?) we say setup/holding priorities are attributes of LSP then what is significance of keeping them per session? Khuzema. Feng, Mark" wrote: > > Ping, > > I know the name implies the attributes belong to the session. But does it > mean all senders, i.e. ingress routers, need to have the same session > attributes? Should the transit nodes reject the new Path message, if the > session attributes are different from other senders of the same session, > because there is no rule on "merging" the session attributes? > > Thanks. > > - Mark > > > -----Original Message----- > > From: Ping Pan [mailto:pingpan@juniper.net] > > Sent: Tuesday, July 17, 2001 9:37 PM > > To: Khuzema Pithewan > > Cc: rsvp@ISI.EDU > > Subject: Re: Session Attributes > > > > > > Khuzema, > > > > First, this question should go to the mpls list. Please forward the > > discussion to that list. Second, the question itself is implementation > > dependent. Finally, since the Session Attribute object is to describe > > the properties of a RSVP session, in a normal implementation, > > it should > > be kept where you keep the session. > > > > - Ping > > > > Khuzema Pithewan wrote: > > > > > > Hi, > > > > > > Session Attribute Object in RSVP-TE contains some flags , setup and > > > holding priority and some session related info. > > > > > > My doubt is , if this object is per session or per LSP, > > because name > > > suggest > > > that it is per session, but holding/setup priorities are > > the attributes > > > of a LSP. > > > so basically where to keep this Object,?? in PSB or Session??? > > > > > > Khuzema. > > From owner-mpls@UU.NET Thu Jul 19 10:24: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 KAA10902 for ; Thu, 19 Jul 2001 10:24: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 QQkyiz11392; Thu, 19 Jul 2001 14:23:49 GMT Received: by mail-control.mail.uu.net id QQkyiz08170 for mpls-outgoing; Thu, 19 Jul 2001 14:22: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 QQkyiz08131 for ; Thu, 19 Jul 2001 14:21: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 QQkyiz13857 for ; Thu, 19 Jul 2001 14:19:37 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 QQkyiz00640 for ; Thu, 19 Jul 2001 14:19:36 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14524 for ; Thu, 19 Jul 2001 10:19:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08092 for mpls@uu.net; Thu, 19 Jul 2001 10:19: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 QQkyhj26774 for ; Thu, 19 Jul 2001 03:56: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 QQkyhj07782 for ; Thu, 19 Jul 2001 03:54:40 GMT Received: from web14807.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14807.mail.yahoo.com [216.136.224.223]) id QQkyhj17561 for ; Thu, 19 Jul 2001 03:54:40 GMT Message-ID: <20010719035439.13440.qmail@web14807.mail.yahoo.com> Received: from [216.174.224.251] by web14807.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 20:54:39 PDT Date: Wed, 18 Jul 2001 20:54:39 -0700 (PDT) From: Vikas D Subject: RE: RFC : 3036 : Session establishment for multiple adjacencies. To: "Sharma, Prem" Cc: mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Prem, That's what my question is. We both agree that if the LDP identifier is same, there needs to be one session. Then, why does the LDP RFC talk about trying to establish multiple sessions for two LSRs linked by multiple Hello adjacencies using the same label spaces. Read the following line carefully: "This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency." I was thinking about it and the only reason (it is a very good reason though) I could think of was to take care of the race condition that may arise when both the transport addresses on the hello adjacencies are different and each of them acts as master for one of the adjacencies. Hope I got it right. Thanks - Vikas --- "Sharma, Prem" wrote: > Hi Vikas, > > TCP connections are established between peer sessions and there > could be > multiple adjacencies under per session. The very fact the multiple > adjacencies are control of one session implies that hellos sent > over the > adjacencies have the same LDP identifier. Irrespective of the no. > of > adjacencies, one TCP connection is good enough between peer > sessions. If > there is a one to one mapping between the physical interfaces of > the machine > and hello adjacencies, the label exchanged are applicable for all > the > interfaces under the control of session. > > Hope it clarifies. > Prem > > > > -----Original Message----- > From: Vikas D [mailto:vikdw@yahoo.com] > Sent: Wednesday, July 18, 2001 11:48 AM > To: mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: RFC : 3036 : Session establishment for multiple > adjacencies. > > > All, > > A small doubt in Section 2.5.2, "Transport Connection > Establishment" > of LDP RFC. It says: > > .............snip.................. > "An LSR MUST advertise the same transport address in all Hellos > that > advertise the same label space. This requirement ensures that > two > LSRs linked by multiple Hello adjacencies using the same label > spaces > play the same connection establishment role for each adjacency." > .............snip.................... > > > > Now, under what circumstances would two LSRs, having multiple > hello adjacencies , using same label spaces on all adjacencies > try to establish multiple TCP sessions? > > Is this not already precluded by the following rule in the same > section (Sec 2.5.2 of RFC 3036): > > .............snip.................. > " 1. If LSR1 does not already have an LDP session for the > exchange > of label spaces LSR1:a and LSR2:b it attempts to open a TCP > connection for a new LDP session with LSR2." > .............snip.................. > > > Thanks > - Vikas > > > __________________________________________________ > 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 Thu Jul 19 10:25: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 KAA11060 for ; Thu, 19 Jul 2001 10:25:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyiz05064; Thu, 19 Jul 2001 14:24:54 GMT Received: by mail-control.mail.uu.net id QQkyiz08200 for mpls-outgoing; Thu, 19 Jul 2001 14:22: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 QQkyiz08172 for ; Thu, 19 Jul 2001 14:22: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 QQkyiz19097 for ; Thu, 19 Jul 2001 14:19:30 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 QQkyiz05557 for ; Thu, 19 Jul 2001 14:19:29 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA07266 for ; Thu, 19 Jul 2001 10:19:29 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08088 for mpls@uu.net; Thu, 19 Jul 2001 10:19:21 -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 QQkyfz02618 for ; Wed, 18 Jul 2001 18:50: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 QQkyfz24483 for ; Wed, 18 Jul 2001 18:47:54 GMT Received: from web14808.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14808.mail.yahoo.com [216.136.224.224]) id QQkyfz24290 for ; Wed, 18 Jul 2001 18:47:53 GMT Message-ID: <20010718184753.26594.qmail@web14808.mail.yahoo.com> Received: from [216.174.224.251] by web14808.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 11:47:53 PDT Date: Wed, 18 Jul 2001 11:47:53 -0700 (PDT) From: Vikas D Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. To: mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <20010717051426.5237.qmail@web14808.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk All, A small doubt in Section 2.5.2, "Transport Connection Establishment" of LDP RFC. It says: .............snip.................. "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency." .............snip.................... Now, under what circumstances would two LSRs, having multiple hello adjacencies , using same label spaces on all adjacencies try to establish multiple TCP sessions? Is this not already precluded by the following rule in the same section (Sec 2.5.2 of RFC 3036): .............snip.................. " 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b it attempts to open a TCP connection for a new LDP session with LSR2." .............snip.................. Thanks - Vikas __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Jul 19 10:26: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 KAA11281 for ; Thu, 19 Jul 2001 10:26: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 QQkyiz06470; Thu, 19 Jul 2001 14:26:17 GMT Received: by mail-control.mail.uu.net id QQkyiz08211 for mpls-outgoing; Thu, 19 Jul 2001 14:22:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkyiz08177 for ; Thu, 19 Jul 2001 14:22: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 QQkyiz19996 for ; Thu, 19 Jul 2001 14:20:05 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 QQkyiz01074 for ; Thu, 19 Jul 2001 14:20:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14561 for ; Thu, 19 Jul 2001 10:20:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08102 for mpls@uu.net; Thu, 19 Jul 2001 10:19:56 -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 QQkyid05433 for ; Thu, 19 Jul 2001 08:52: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 QQkyid08053 for ; Thu, 19 Jul 2001 08:50:26 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQkyid12529 for ; Thu, 19 Jul 2001 08:50:21 GMT Received: from netbrahma.com (khuzema.netbrahma.com [172.16.72.170]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBLHL7D; Thu, 19 Jul 2001 14:18:13 +0530 Message-ID: <3B569EFA.B136E3DA@netbrahma.com> Date: Thu, 19 Jul 2001 14:18:58 +0530 From: Khuzema Pithewan Organization: Netbrahma Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "'mpls@uu.net'" Subject: Re: Session Attributes References: <3B568DBA.1B65F986@sasken.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit SE Desired flag can be set in Session Attribute if Ingress is willing to use make-before-break of LSPs... Khuzema. Rajesh P Jain wrote: > > "Hi", > I would also like to know if this Session Attribute OBJECT > anyway helpful in Rerouting Traffic Engineered Tunnels?? Is the information > present in this object anyway useful in "make-before-break" concept? > > TIA > Rajesh P Jain > > "Feng, Mark" wrote: > > > Ping, > > > > I know the name implies the attributes belong to the session. But does it > > mean all senders, i.e. ingress routers, need to have the same session > > attributes? Should the transit nodes reject the new Path message, if the > > session attributes are different from other senders of the same session, > > because there is no rule on "merging" the session attributes? > > > > Thanks. > > > > - Mark > > > > > -----Original Message----- > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > Sent: Tuesday, July 17, 2001 9:37 PM > > > To: Khuzema Pithewan > > > Cc: rsvp@ISI.EDU > > > Subject: Re: Session Attributes > > > > > > > > > Khuzema, > > > > > > First, this question should go to the mpls list. Please forward the > > > discussion to that list. Second, the question itself is implementation > > > dependent. Finally, since the Session Attribute object is to describe > > > the properties of a RSVP session, in a normal implementation, > > > it should > > > be kept where you keep the session. > > > > > > - Ping > > > > > > Khuzema Pithewan wrote: > > > > > > > > Hi, > > > > > > > > Session Attribute Object in RSVP-TE contains some flags , setup and > > > > holding priority and some session related info. > > > > > > > > My doubt is , if this object is per session or per LSP, > > > because name > > > > suggest > > > > that it is per session, but holding/setup priorities are > > > the attributes > > > > of a LSP. > > > > so basically where to keep this Object,?? in PSB or Session??? > > > > > > > > Khuzema. > > > From owner-mpls@UU.NET Thu Jul 19 10:34: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 KAA12449 for ; Thu, 19 Jul 2001 10:34:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyja07220; Thu, 19 Jul 2001 14:34:37 GMT Received: by mail-control.mail.uu.net id QQkyja09375 for mpls-outgoing; Thu, 19 Jul 2001 14:34: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 QQkyja09353 for ; Thu, 19 Jul 2001 14:33: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 QQkyja27495 for ; Thu, 19 Jul 2001 14:32:54 GMT Received: from smtp.monmouth.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.monmouth.com [209.191.58.6]) id QQkyja05456 for ; Thu, 19 Jul 2001 14:32:54 GMT Received: from monmouth.com ([64.19.191.1]) by smtp.monmouth.com (8.11.4/8.11.4) with ESMTP id f6JEWQm23355; Thu, 19 Jul 2001 10:32:26 -0400 (EDT) Message-ID: <3B56E177.732FD021@monmouth.com> Date: Thu, 19 Jul 2001 09:32:40 -0400 From: Dipak X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: abhay CC: "Sharma, Prem" , "'Hong Liao'" , mpls@UU.NET Subject: Re: RSVP-TE and cr-ldp References: <3B566C92.A3E55DDA@multitech.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Why one need to have seperate label space for CR-LDP and RSVP-TE? In the MPLS-TE-MIB, the object mplsTunnelSignallingProto in mplsTunnelTable is enough to identify the controlling signalling protocol in use in each LSR. One doesn't need to know while doing Label swapping or popping or pushing that which signalling has been used to acquire the Label. And when there is interworking between CR-LDP and RSVP-TE, then parts of tunnel will be owned by corresponding signalling protocols. regards, dipak abhay wrote: > > > Julia, > > I guess yes,but maybe one should have separate label pools. > > I also remember one can do Interworking between CR-LDP and RSVP-TE ,each running on separate > > routers. > > Regards, > > Abhay > > > > > "Sharma, Prem" wrote: > >> Hi, >> >> I feel, it's very much possible for an LSR to support both RSVP-TE >> and >> CR-LDP signalling protocols but one would have to take care of >> resource >> partitioning (assignment of label ranges) between the signalling >> modules. >> >> Prem >> >> -----Original Message----- >> From: Hong Liao [mailto:hliao@telcordia.com] >> Sent: Wednesday, July 18, 2001 3:19 PM >> To: mpls@UU.NET >> Subject: RSVP-TE and cr-ldp >> >> Hi, >> >> Is there anyone can tell me if there is any LSR can support RSVP-TE >> and >> cr-ldp? >> >> Thanks in an advance. >> >> Julia > From owner-mpls@UU.NET Thu Jul 19 10:47: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 KAA14614 for ; Thu, 19 Jul 2001 10:47: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 QQkyjb11916; Thu, 19 Jul 2001 14:47:53 GMT Received: by mail-control.mail.uu.net id QQkyjb11120 for mpls-outgoing; Thu, 19 Jul 2001 14:47: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 QQkyjb11103 for ; Thu, 19 Jul 2001 14:47: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 QQkyjb28412 for ; Thu, 19 Jul 2001 14:46:53 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 QQkyjb28190 for ; Thu, 19 Jul 2001 14:46:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA19317 for mpls@uu.net; Thu, 19 Jul 2001 10:46:43 -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 QQkyjb10991 for ; Thu, 19 Jul 2001 14:46: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 QQkyja18593 for ; Thu, 19 Jul 2001 14:42:40 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 QQkyja05757 for ; Thu, 19 Jul 2001 14:42:39 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 KAA09900; Thu, 19 Jul 2001 10:42:38 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225]) by bucket.cisco.com (Mirapoint) with ESMTP id ADT01599; Thu, 19 Jul 2001 10:42:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719104631.017bc7c0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 10:47:36 -0400 To: Dipak , abhay From: "Thomas D. Nadeau" Subject: Re: RSVP-TE and cr-ldp Cc: "Sharma, Prem" , "'Hong Liao'" , mpls@UU.NET In-Reply-To: <3B56E177.732FD021@monmouth.com> References: <3B566C92.A3E55DDA@multitech.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > Why one need to have seperate label space for CR-LDP and RSVP-TE? >In the MPLS-TE-MIB, the object mplsTunnelSignallingProto in >mplsTunnelTable is enough to identify the controlling signalling >protocol in use in each LSR. This is correct. Within the context of the mpls-te-mib, when configuring te tunnels it is not important to know where the labels are coming from to signal the tunnels. This information is provided by the LSR/LDP MIBs. --Tom > One doesn't need to know while doing Label >swapping or popping or pushing that which signalling has been used to >acquire the Label. And when there is interworking between CR-LDP and >RSVP-TE, then parts of tunnel will be owned by corresponding signalling >protocols. > >regards, >dipak > >abhay wrote: > > > > > > > Julia, > > > > I guess yes,but maybe one should have separate label pools. > > > > I also remember one can do Interworking between CR-LDP and RSVP-TE > ,each running on separate > > > > routers. > > > > Regards, > > > > Abhay > > > > > > > > > > "Sharma, Prem" wrote: > > > >> Hi, > >> > >> I feel, it's very much possible for an LSR to support both RSVP-TE > >> and > >> CR-LDP signalling protocols but one would have to take care of > >> resource > >> partitioning (assignment of label ranges) between the signalling > >> modules. > >> > >> Prem > >> > >> -----Original Message----- > >> From: Hong Liao [mailto:hliao@telcordia.com] > >> Sent: Wednesday, July 18, 2001 3:19 PM > >> To: mpls@UU.NET > >> Subject: RSVP-TE and cr-ldp > >> > >> Hi, > >> > >> Is there anyone can tell me if there is any LSR can support RSVP-TE > >> and > >> cr-ldp? > >> > >> Thanks in an advance. > >> > >> Julia > > From owner-mpls@UU.NET Thu Jul 19 10:52: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 KAA15331 for ; Thu, 19 Jul 2001 10:52: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 QQkyjb18054; Thu, 19 Jul 2001 14:52:22 GMT Received: by mail-control.mail.uu.net id QQkyjb11557 for mpls-outgoing; Thu, 19 Jul 2001 14:51: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 QQkyjb11524 for ; Thu, 19 Jul 2001 14:51:27 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 QQkyjb27041 for ; Thu, 19 Jul 2001 14:50:16 GMT Received: from smtp.monmouth.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.monmouth.com [209.191.58.6]) id QQkyjb23571 for ; Thu, 19 Jul 2001 14:50:15 GMT Received: from monmouth.com ([64.19.191.1]) by smtp.monmouth.com (8.11.4/8.11.4) with ESMTP id f6JEoFm27021; Thu, 19 Jul 2001 10:50:15 -0400 (EDT) Message-ID: <3B56E5A5.D90081D5@monmouth.com> Date: Thu, 19 Jul 2001 09:50:29 -0400 From: Dipak X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Hong Liao CC: mpls@UU.NET Subject: Re: RSVP-TE and cr-ldp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Check www.mplsrc.com/vendor.shtml Hong Liao wrote: > Abhay, > > Can you tell me if there is any vendor who can support RSVP-TE? > > Thanks in an advance. > > Julia > > > abhay > > ech.co.in> cc: "'Hong Liao'" , mpls@UU.NET, (bcc: Hong > Liao/Telcordia) > 07/19/01 Subject: Re: RSVP-TE and cr-ldp > 01:13 AM > > > > Julia, > > I guess yes,but maybe one should have separate label pools. > > I also remember one can do Interworking between CR-LDP and RSVP-TE > ,each running on separate > > routers. > > Regards, > > Abhay > > "Sharma, Prem" wrote: > > > Hi, > > > > I feel, it's very much possible for an LSR to support both RSVP-TE and > > CR-LDP signalling protocols but one would have to take care of resource > > partitioning (assignment of label ranges) between the signalling modules. > > > > Prem > > > > -----Original Message----- > > From: Hong Liao [mailto:hliao@telcordia.com] > > Sent: Wednesday, July 18, 2001 3:19 PM > > To: mpls@UU.NET > > Subject: RSVP-TE and cr-ldp > > > > Hi, > > > > Is there anyone can tell me if there is any LSR can support RSVP-TE and > > cr-ldp? > > > > Thanks in an advance. > > > > Julia > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 From owner-mpls@UU.NET Thu Jul 19 10:55: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 KAA15763 for ; Thu, 19 Jul 2001 10:55: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 QQkyjb27129; Thu, 19 Jul 2001 14:53:58 GMT Received: by mail-control.mail.uu.net id QQkyjb11790 for mpls-outgoing; Thu, 19 Jul 2001 14:53: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 QQkyjb11730 for ; Thu, 19 Jul 2001 14:52: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 QQkyjb29128 for ; Thu, 19 Jul 2001 14:52:06 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQkyjb04134 for ; Thu, 19 Jul 2001 14:52:06 GMT Received: from aatlas-pc (aatlas-pc.avici.com [10.2.20.92]) by mailhost.avici.com (8.11.0/8.11.0) with SMTP id f6JEoPs24647 for ; Thu, 19 Jul 2001 10:50:25 -0400 (EDT) Message-Id: <4.1.20010719104740.00ac4ea0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 19 Jul 2001 10:47:57 -0500 To: mpls@UU.NET From: Alia Atlas Subject: Fwd: I-D ACTION:draft-atlas-rsvp-local-protect-interop-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk >To: IETF-Announce:; >CC: mpls@UU.NET >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-atlas-rsvp-local-protect-interop-00.txt >Date: Thu, 19 Jul 2001 07:04:24 -0400 >Sender: owner-mpls@UU.NET > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : MPLS RSVP-TE Interoperability for Local > Protection/Fast Reroute > Author(s) : A. Atlas et al. > Filename : draft-atlas-rsvp-local-protect-interop-00.txt > Pages : 15 > Date : 18-Jul-01 > >Routers implementing the local protection enhancements given in >[draft-ietf-mpls-rsvp-lsp-tunnel-08.txt], whose usage is clarified in >[draft-swallow-rsvp-bypass-label-01.txt], and routers implementing >solely [draft-gan-fast-reroute-00.txt] do not interoperate to provide >local protection. Those routers which follow the guidelines given in >this draft should be able to interoperate with either type of >implementation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-atlas-rsvp-local-protect-interop-0 >0.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-atlas-rsvp-local-protect-interop-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-atlas-rsvp-local-protect-interop-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010718141956.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-atlas-rsvp-local-protect-interop-00.txt > >0.txt> From owner-mpls@UU.NET Thu Jul 19 10:55: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 KAA15856 for ; Thu, 19 Jul 2001 10:55: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 QQkyjb21920; Thu, 19 Jul 2001 14:55:11 GMT Received: by mail-control.mail.uu.net id QQkyjb11850 for mpls-outgoing; Thu, 19 Jul 2001 14:53: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 QQkyjb11823 for ; Thu, 19 Jul 2001 14:53:27 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 QQkyjb28766 for ; Thu, 19 Jul 2001 14:51:23 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkyjb16799 for ; Thu, 19 Jul 2001 14:51:22 GMT Message-ID: <3B56F3E3.D697973F@sandburst.com> Date: Thu, 19 Jul 2001 10:51:15 -0400 From: Eric Gray MIME-Version: 1.0 To: "Sharma, Prem" , Chetan Kumar S Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. References: <20010719035439.13440.qmail@web14807.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 Prem/Chetan, I feel certain that the real misunderstanding here is in the fact that use of "transport address" in a hello message has little to do with the LDP ID and even less with establishing muliple sessions between two LSRs that are both using per-platform label space. As Chetan points out, these addresses are used to determine who plays what role in a single LDP session. What may not have been made clear in this thread is that 'roles' refers to active/passive - or who it will be that is responsible for initiating the single session. If you don't require both LSRs to use no more than one transport address each, then you have to define a determintistic mechanism for ensuring that they will both come to the same conclusion as to who plays the active role. -- Eric Gray Vikas D wrote: > Prem, > > That's what my question is. We both agree that if the LDP identifier > is same, there needs to be one session. Then, why does the LDP RFC > talk about trying to establish multiple sessions for two LSRs linked > by multiple Hello adjacencies using the same label spaces. Read the > following line carefully: > > "This requirement ensures that two LSRs linked by multiple Hello > adjacencies using the same label spaces play the same connection > establishment role for each adjacency." > > I was thinking about it and the only reason (it is a very good reason > though) I could think of was to take care of the race condition that > may arise when both the transport addresses on the hello adjacencies > are different and each of them acts as master for one of the > adjacencies. > > Hope I got it right. > > Thanks > - Vikas > > --- "Sharma, Prem" wrote: > > Hi Vikas, > > > > TCP connections are established between peer sessions and there > > could be multiple adjacencies under per session. The very fact the > > multiple adjacencies are control of one session implies that hellos > > sent over the adjacencies have the same LDP identifier. Irrespective > > of the no. of adjacencies, one TCP connection is good enough between > > peer sessions. If there is a one to one mapping between the physical > > interfaces of the machine and hello adjacencies, the label exchanged > > are applicable for all the interfaces under the control of session. > > > > Hope it clarifies. > > Prem > > > > > > > > -----Original Message----- > > From: Vikas D [mailto:vikdw@yahoo.com] > > Sent: Wednesday, July 18, 2001 11:48 AM > > To: mpls-ops@mplsrc.com; mpls@UU.NET > > Subject: Re: RFC : 3036 : Session establishment for multiple > > adjacencies. > > > > > > All, > > > > A small doubt in Section 2.5.2, "Transport Connection > > Establishment" > > of LDP RFC. It says: > > > > .............snip.................. > > "An LSR MUST advertise the same transport address in all Hellos > > that advertise the same label space. This requirement ensures that > > two LSRs linked by multiple Hello adjacencies using the same label > > spaces play the same connection establishment role for each adjacency." > > .............snip.................... > > > > > > > > Now, under what circumstances would two LSRs, having multiple > > hello adjacencies , using same label spaces on all adjacencies > > try to establish multiple TCP sessions? > > > > Is this not already precluded by the following rule in the same > > section (Sec 2.5.2 of RFC 3036): > > > > .............snip.................. > > " 1. If LSR1 does not already have an LDP session for the > > exchange > > of label spaces LSR1:a and LSR2:b it attempts to open a TCP > > connection for a new LDP session with LSR2." > > .............snip.................. > > > > > > Thanks > > - Vikas > > > > > > __________________________________________________ > > 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 Thu Jul 19 11:00:20 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 LAA16564 for ; Thu, 19 Jul 2001 11:00: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 QQkyjb11955; Thu, 19 Jul 2001 14:59:44 GMT Received: by mail-control.mail.uu.net id QQkyjb12592 for mpls-outgoing; Thu, 19 Jul 2001 14:59: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 QQkyjb12536 for ; Thu, 19 Jul 2001 14:58:53 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 QQkyjb20435 for ; Thu, 19 Jul 2001 14:57:48 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQkyjb09796 for ; Thu, 19 Jul 2001 14:57:47 GMT Received: from aatlas-pc (aatlas-pc.avici.com [10.2.20.92]) by mailhost.avici.com (8.11.0/8.11.0) with SMTP id f6JEtms25510; Thu, 19 Jul 2001 10:55:48 -0400 (EDT) Message-Id: <4.1.20010719104852.00ac0100@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 19 Jul 2001 10:53:20 -0500 To: Khuzema Pithewan From: Alia Atlas Subject: Re: Session Attributes Cc: "Feng, Mark" , "'Ping Pan'" , "'mpls@uu.net'" In-Reply-To: <3B565A6E.3CA17D38@netbrahma.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk The SESSION_ATTRIBUTES are per LSP. Consider the case where the operator decides to change the holding & reserving priority used for the tunnel. Then a make-before-break is done, where the new LSP is signalled with the new priorities in the SESSION_ATTRIBUTES object before the old LSP is torn down. Also, consider the case of doing fast-reroute, where the backup LSP belongs to the same session as the primary LSP, but may have a different holding and reserving priority than the primary (whether due to the contents of the FAST_REROUTE object, if used, or to operator configuration at the potential PLR). Dropping a PATH message because it has different information in its SESSION_ATTRIBUTES object than a previous PATH message for the same SESSION does not make sense for either of the above scenarios. Alia At 09:26 AM 7/19/01 +0530, Khuzema Pithewan wrote: >Hi, > >I am given to understand that, when RSVP-TE works with MPLS, the LSP >setup is control driven, means, there should be some Administrator which >is responsible to configure the session attributes for the session, if >administrator wants to give different session attributes for the path >messages grouped on per ingress basis, then Extended tunnel Id can be >used. Now if there is case of reception of PATH messages with different >session attributes in same session, then its a result of >mis-configuration and I believe in that case path message should be >dropped. But again if(?) we say setup/holding priorities are attributes >of LSP then what is significance of keeping them per session? > >Khuzema. > >Feng, Mark" wrote: >> >> Ping, >> >> I know the name implies the attributes belong to the session. But does it >> mean all senders, i.e. ingress routers, need to have the same session >> attributes? Should the transit nodes reject the new Path message, if the >> session attributes are different from other senders of the same session, >> because there is no rule on "merging" the session attributes? >> >> Thanks. >> >> - Mark >> >> > -----Original Message----- >> > From: Ping Pan [mailto:pingpan@juniper.net] >> > Sent: Tuesday, July 17, 2001 9:37 PM >> > To: Khuzema Pithewan >> > Cc: rsvp@ISI.EDU >> > Subject: Re: Session Attributes >> > >> > >> > Khuzema, >> > >> > First, this question should go to the mpls list. Please forward the >> > discussion to that list. Second, the question itself is implementation >> > dependent. Finally, since the Session Attribute object is to describe >> > the properties of a RSVP session, in a normal implementation, >> > it should >> > be kept where you keep the session. >> > >> > - Ping >> > >> > Khuzema Pithewan wrote: >> > > >> > > Hi, >> > > >> > > Session Attribute Object in RSVP-TE contains some flags , setup and >> > > holding priority and some session related info. >> > > >> > > My doubt is , if this object is per session or per LSP, >> > because name >> > > suggest >> > > that it is per session, but holding/setup priorities are >> > the attributes >> > > of a LSP. >> > > so basically where to keep this Object,?? in PSB or Session??? >> > > >> > > Khuzema. >> > > From owner-mpls@UU.NET Thu Jul 19 11:04: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 LAA17186 for ; Thu, 19 Jul 2001 11:04: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 QQkyjc02675; Thu, 19 Jul 2001 15:04:03 GMT Received: by mail-control.mail.uu.net id QQkyjc18580 for mpls-outgoing; Thu, 19 Jul 2001 15:03:29 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 QQkyjc18502 for ; Thu, 19 Jul 2001 15:03:25 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 QQkyjc25271 for ; Thu, 19 Jul 2001 15:02:28 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 QQkyjc15386 for ; Thu, 19 Jul 2001 15:02:27 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA19699; Thu, 19 Jul 2001 11:02:27 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA08296; Thu, 19 Jul 2001 11:02:19 -0400 (EDT) Message-Id: <200107191502.LAA08296@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Sanjay Wadhwa cc: Ping Pan , "Punj, Arun" , mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] In-reply-to: Your message of Wed, 18 Jul 2001 07:54:02 -0700. <20010718145402.43604.qmail@web11404.mail.yahoo.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, 19 Jul 2001 11:02:19 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Sanjay> if the reverse LSP (virtual interface) is broken (say due to Sanjay> corrupted label maps along the way), then even the RESVs for the Sanjay> inner LSPs don't make it through, and soon enough the inner LSP will Sanjay> be torn down (So making echo-response live and die with rsvp resv Sanjay> actually will work fine with nested tunnels irrespective of RESV Sanjay> using a reverse LSP or native ip in the reverse direction). Excellent point. So then I think then the base requirement for the routing of the response from the egress is that it be reverse-path-forwarded back to the ingress, i.e., that it follow the path of label distribution from egress to ingress. From owner-mpls@UU.NET Thu Jul 19 11:13: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 LAA19224 for ; Thu, 19 Jul 2001 11:13: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 QQkyjc13804; Thu, 19 Jul 2001 15:12:33 GMT Received: by mail-control.mail.uu.net id QQkyjc02928 for mpls-outgoing; Thu, 19 Jul 2001 15:11: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 QQkyjc02665 for ; Thu, 19 Jul 2001 15:11: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 QQkyjc02347 for ; Thu, 19 Jul 2001 15:09:55 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkyjc23403 for ; Thu, 19 Jul 2001 15:09:54 GMT Message-ID: <3B56F840.472FD2F0@sandburst.com> Date: Thu, 19 Jul 2001 11:09:52 -0400 From: Eric Gray MIME-Version: 1.0 To: "Thomas D. Nadeau" Cc: Dipak , abhay , "Sharma, Prem" , "'Hong Liao'" , mpls@UU.NET Subject: Re: RSVP-TE and cr-ldp References: <3B566C92.A3E55DDA@multitech.co.in> <4.3.2.7.2.20010719104631.017bc7c0@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom/Abhay/Dipak, I think we may always regret the choice of naming that led to the name 'label space'. What Tom and Dipak say is true in the sense that there is no different labeling context associated with how the labels are assigned. In fact, barring some sort of demux point, there cannot be. But it is distinctly possible that Abhay is making the point that two or more label distirbution mechanisms must take some sort of step to make sure that they don't issue the same label with more than one meaning. One approach might be to partition the 'label space' into ranges assigned to each protocol - but how an LSR does this is strictly a local matter. The fact that this is required follows directly from the arguments that Tom and Dipak make. Therefore, I suspect that you are all in violent agreement. -- Eric Gray "Thomas D. Nadeau" wrote: > > Why one need to have seperate label space for CR-LDP and RSVP-TE? > >In the MPLS-TE-MIB, the object mplsTunnelSignallingProto in > >mplsTunnelTable is enough to identify the controlling signalling > >protocol in use in each LSR. > > This is correct. Within the context of the mpls-te-mib, > when configuring te tunnels it is not important to know where > the labels are coming from to signal the tunnels. This > information is provided by the LSR/LDP MIBs. > > --Tom > > > One doesn't need to know while doing Label > >swapping or popping or pushing that which signalling has been used to > >acquire the Label. And when there is interworking between CR-LDP and > >RSVP-TE, then parts of tunnel will be owned by corresponding signalling > >protocols. > > > >regards, > >dipak > > > >abhay wrote: > > > > > > > > > > > Julia, > > > > > > I guess yes,but maybe one should have separate label pools. > > > > > > I also remember one can do Interworking between CR-LDP and RSVP-TE > > ,each running on separate > > > > > > routers. > > > > > > Regards, > > > > > > Abhay > > > > > > > > > > > > > > > "Sharma, Prem" wrote: > > > > > >> Hi, > > >> > > >> I feel, it's very much possible for an LSR to support both RSVP-TE > > >> and > > >> CR-LDP signalling protocols but one would have to take care of > > >> resource > > >> partitioning (assignment of label ranges) between the signalling > > >> modules. > > >> > > >> Prem > > >> > > >> -----Original Message----- > > >> From: Hong Liao [mailto:hliao@telcordia.com] > > >> Sent: Wednesday, July 18, 2001 3:19 PM > > >> To: mpls@UU.NET > > >> Subject: RSVP-TE and cr-ldp > > >> > > >> Hi, > > >> > > >> Is there anyone can tell me if there is any LSR can support RSVP-TE > > >> and > > >> cr-ldp? > > >> > > >> Thanks in an advance. > > >> > > >> Julia > > > From owner-mpls@UU.NET Thu Jul 19 11:47: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 LAA28637 for ; Thu, 19 Jul 2001 11:47: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 QQkyjf19101; Thu, 19 Jul 2001 15:47:36 GMT Received: by mail-control.mail.uu.net id QQkyjf07655 for mpls-outgoing; Thu, 19 Jul 2001 15:46: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 QQkyjf07645 for ; Thu, 19 Jul 2001 15:46: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 QQkyje22130 for ; Thu, 19 Jul 2001 15:43: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 QQkyje22185 for ; Thu, 19 Jul 2001 15:43:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA26175 for mpls@uu.net; Thu, 19 Jul 2001 11:43:04 -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 QQkyje06708 for ; Thu, 19 Jul 2001 15:37: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 QQkyje13335 for ; Thu, 19 Jul 2001 15:37:00 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 QQkyje16218 for ; Thu, 19 Jul 2001 15:37:00 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 LAA17069; Thu, 19 Jul 2001 11:37:00 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225]) by bucket.cisco.com (Mirapoint) with ESMTP id ADT02452; Thu, 19 Jul 2001 11:36:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719114117.02708d68@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 11:41:58 -0400 To: Eric Gray From: "Thomas D. Nadeau" Subject: Re: RSVP-TE and cr-ldp Cc: Dipak , abhay , "Sharma, Prem" , "'Hong Liao'" , mpls@UU.NET In-Reply-To: <3B56F840.472FD2F0@sandburst.com> References: <3B566C92.A3E55DDA@multitech.co.in> <4.3.2.7.2.20010719104631.017bc7c0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:09 AM 7/19/2001 -0400, Eric Gray wrote: >Tom/Abhay/Dipak, > > I think we may always regret the choice of naming that led to >the name 'label space'. What Tom and Dipak say is true in the >sense that there is no different labeling context associated with >how the labels are assigned. In fact, barring some sort of demux >point, there cannot be. But it is distinctly possible that Abhay is >making the point that two or more label distirbution mechanisms >must take some sort of step to make sure that they don't issue >the same label with more than one meaning. One approach might >be to partition the 'label space' into ranges assigned to each >protocol - but how an LSR does this is strictly a local matter. Eric is correct here; implementation issue. The standard specifications do not mention this anywhere from what I recall. >The fact that this is required follows directly from the arguments that >Tom and Dipak make. > > Therefore, I suspect that you are all in violent agreement. Yup. --Tom >-- >Eric Gray > > >"Thomas D. Nadeau" wrote: > > > > Why one need to have seperate label space for CR-LDP and RSVP-TE? > > >In the MPLS-TE-MIB, the object mplsTunnelSignallingProto in > > >mplsTunnelTable is enough to identify the controlling signalling > > >protocol in use in each LSR. > > > > This is correct. Within the context of the mpls-te-mib, > > when configuring te tunnels it is not important to know where > > the labels are coming from to signal the tunnels. This > > information is provided by the LSR/LDP MIBs. > > > > --Tom > > > > > One doesn't need to know while doing Label > > >swapping or popping or pushing that which signalling has been used to > > >acquire the Label. And when there is interworking between CR-LDP and > > >RSVP-TE, then parts of tunnel will be owned by corresponding signalling > > >protocols. > > > > > >regards, > > >dipak > > > > > >abhay wrote: > > > > > > > > > > > > > > > Julia, > > > > > > > > I guess yes,but maybe one should have separate label pools. > > > > > > > > I also remember one can do Interworking between CR-LDP and RSVP-TE > > > ,each running on separate > > > > > > > > routers. > > > > > > > > Regards, > > > > > > > > Abhay > > > > > > > > > > > > > > > > > > > > "Sharma, Prem" wrote: > > > > > > > >> Hi, > > > >> > > > >> I feel, it's very much possible for an LSR to support both RSVP-TE > > > >> and > > > >> CR-LDP signalling protocols but one would have to take care of > > > >> resource > > > >> partitioning (assignment of label ranges) between the signalling > > > >> modules. > > > >> > > > >> Prem > > > >> > > > >> -----Original Message----- > > > >> From: Hong Liao [mailto:hliao@telcordia.com] > > > >> Sent: Wednesday, July 18, 2001 3:19 PM > > > >> To: mpls@UU.NET > > > >> Subject: RSVP-TE and cr-ldp > > > >> > > > >> Hi, > > > >> > > > >> Is there anyone can tell me if there is any LSR can support RSVP-TE > > > >> and > > > >> cr-ldp? > > > >> > > > >> Thanks in an advance. > > > >> > > > >> Julia > > > > From owner-mpls@UU.NET Thu Jul 19 12:16: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 MAA04666 for ; Thu, 19 Jul 2001 12:16:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyjh08283; Thu, 19 Jul 2001 16:16:18 GMT Received: by mail-control.mail.uu.net id QQkyjh00800 for mpls-outgoing; Thu, 19 Jul 2001 16:15: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 QQkyjh00769 for ; Thu, 19 Jul 2001 16:15:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyjg01860 for ; Thu, 19 Jul 2001 16:11:42 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 QQkyjg02517 for ; Thu, 19 Jul 2001 16:11: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 MAA03444 for ; Thu, 19 Jul 2001 12:11: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 MAA05646 for ; Thu, 19 Jul 2001 12:11:41 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Jul 2001 12:11:38 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5537DD6B@VIE-MSGUSR-01> From: "Ju, Yu" To: "'mpls@uu.net'" Subject: LDP mib question Date: Thu, 19 Jul 2001 12:11: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 several questions regarding draft-ietf-mpls-ldp-mib-07.txt. 1) When mplsLdpEntityIndex is needed to identify an LDP entity? It looks to me that mplsLdpEntityLdpId itself is good enough. 2) mplsLdpEntityConfGenericIfIndexOrZero represents either the InterfaceIndex of the 'ifLayer" where there Generic Label would be created. What if there are multiple interfaces that use the same label range? mplsLdpEntityConfGenericIfIndexOrZero can only hold one interfaceIndex value. 3) Isn't mplsLdpPeerId itself good enough to identify a LDP peer? Why mplsLdpEntityLdpId and mplsLDPEntityIndex are also part of the index of mplsLdpPeerEntry? Thanks, Yu From owner-mpls@UU.NET Thu Jul 19 12:19: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 MAA05472 for ; Thu, 19 Jul 2001 12:19:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyjh24314; Thu, 19 Jul 2001 16:19:37 GMT Received: by mail-control.mail.uu.net id QQkyjh01281 for mpls-outgoing; Thu, 19 Jul 2001 16: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 QQkyjh01224 for ; Thu, 19 Jul 2001 16:18: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 QQkyjg27173 for ; Thu, 19 Jul 2001 16:14:28 GMT Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.246.129]) id QQkyjg13469 for ; Thu, 19 Jul 2001 16:14:27 GMT content-class: urn:content-classes:message Subject: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt Date: Thu, 19 Jul 2001 19:14:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt Thread-Index: AcEQbeEoPGOvcorMQ6idjfq5uF9XgQ== From: "Amir Hermelin" To: Cc: "MPLS-wg (E-mail)" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA05472 Kireeti, A few comments regarding your proposal: 1) it seems there is a typo in your draft, section 7.3. The last two lines in the section read: reserved[p] := reserved[p] + B' unreserved[q] := unreserved[q] - B' for q >= p and they should read: reserved[p] := reserved[p] - B' unreserved[q] := unreserved[q] + B' for q >= p 2) The current approach supports configuration changes without "losing the math". However, in your proposal, if the administrator changes the subscription factor after some LSPs were set up at that priority, it would mean that when one of these LSPs were removed you can't properly calculate which B' to use in the math. If you were to correct this by adjusting unreserved[p] and reserved[p] when the configuration of subscr[p] takes place, you'd still have a problem of what to do in the lower priorities (q > p), since their values could be a mixture of other priorities as well. 3) With your proposal, it is possible to model the current approach with over-subscription (with necessary modifications to TE extensions and CSPF code). However, under-subscription can't be modeled (due to the restriction in 7.1). What are the reasons for this decision? 4) It seems that this proposal (as well as others before it) doesn't fully address considerations for (Diffserv) inter-class(type) pre-emption. Since B' is computed using subscr[p], and is used at lower priorities (q > p) for pre-emption, IMHO an explanation of how this is sensible for pre-empting between classes should be accompanied. 5) Your "Current Approach" explanation is IMO the clearest and most concise out there. Regards, Amir. -- Amir Hermelin Charlotte's Web Networks Inc. From owner-mpls@UU.NET Thu Jul 19 13:27:25 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 NAA16236 for ; Thu, 19 Jul 2001 13:27: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 QQkyjl20465; Thu, 19 Jul 2001 17:26:48 GMT Received: by mail-control.mail.uu.net id QQkyjl28752 for mpls-outgoing; Thu, 19 Jul 2001 17:26: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 QQkyjl28720 for ; Thu, 19 Jul 2001 17:25: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 QQkyjl11280 for ; Thu, 19 Jul 2001 17:24:36 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 QQkyjl21853 for ; Thu, 19 Jul 2001 17:24:35 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA06618 for ; Thu, 19 Jul 2001 13:24:35 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA08844 for mpls@uu.net; Thu, 19 Jul 2001 13:24:27 -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 QQkyjk11336 for ; Thu, 19 Jul 2001 17:02: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 QQkyjj04975 for ; Thu, 19 Jul 2001 16:57:37 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 QQkyjj22135 for ; Thu, 19 Jul 2001 16:57:35 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 f6JGsDo03218; Thu, 19 Jul 2001 09:54:13 -0700 (PDT) Reply-To: From: "HariKishan" To: "Ju, Yu" , "'mpls@uu.net'" Subject: RE: LDP mib question Date: Thu, 19 Jul 2001 09:52: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) In-Reply-To: <39469E08BD83D411A3D900204840EC5537DD6B@VIE-MSGUSR-01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yu, Here are some reasons for this !! 1) The tables are designed so that Multiple LDP entities exist on a single interface.( e.g. Ethernet ). One would want to configure the label distribution mode per LSR reachable on an interface (e.g. Ethernet using per plat form label space). 2) Multiple LDP entities can exist with the same label space(LDP ID); Each entity refers to exactly one label space(LDP ID), but several entities may refer to the same LDP ID 3) Multiple LDP entities can exist on a single interface ( typically a multi-access interface such as Ethernet); The case 2 in your e-mail :- I think there will be 2 different entities with same label space id (may/may not be with same label range) and each one pointing to it's own interface index. thanks, Kishan > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Ju, Yu > Sent: Thursday, July 19, 2001 9:12 AM > To: 'mpls@uu.net' > Subject: LDP mib question > > > Hi, > > I have several questions regarding draft-ietf-mpls-ldp-mib-07.txt. > > 1) When mplsLdpEntityIndex is needed to identify an LDP > entity? It looks to > me that mplsLdpEntityLdpId itself is good enough. > > 2) mplsLdpEntityConfGenericIfIndexOrZero represents either the > InterfaceIndex of the 'ifLayer" where there Generic Label > would be created. > What if there are multiple interfaces that use the same label range? > mplsLdpEntityConfGenericIfIndexOrZero can only hold one > interfaceIndex > value. > > 3) Isn't mplsLdpPeerId itself good enough to identify a LDP > peer? Why > mplsLdpEntityLdpId and mplsLDPEntityIndex are also part of > the index of > mplsLdpPeerEntry? > > > Thanks, > > Yu > From owner-mpls@UU.NET Thu Jul 19 14:08: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 OAA28953 for ; Thu, 19 Jul 2001 14:08: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 QQkyjo12000; Thu, 19 Jul 2001 18:07:54 GMT Received: by mail-control.mail.uu.net id QQkyjo15247 for mpls-outgoing; Thu, 19 Jul 2001 18:07:21 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 QQkyjo15188 for ; Thu, 19 Jul 2001 18:07: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 QQkyjo06484 for ; Thu, 19 Jul 2001 18:06:49 GMT Received: from hebe.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns02.or.intel.com [134.134.248.4] (may be forged)) id QQkyjo22511 for ; Thu, 19 Jul 2001 18:06:49 GMT Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA04689; Thu, 19 Jul 2001 18:06:18 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Jul 2001 18:06:15 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 11:06:13 -0700 Message-ID: From: "Feng, Mark" To: "'Khuzema Pithewan'" Cc: "'mpls@uu.net'" Subject: RE: Session Attributes Date: Thu, 19 Jul 2001 11:06:11 -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 the "local protecion" flag is useful in term of re-routing LSPs in case of downstream node failure. The resource affinity related vectors are useful regarding constraint-based routing... - Mark > -----Original Message----- > From: Khuzema Pithewan [mailto:khuzema@netbrahma.com] > Sent: Thursday, July 19, 2001 1:49 AM > Cc: 'mpls@uu.net' > Subject: Re: Session Attributes > > > SE Desired flag can be set in Session Attribute if Ingress is > willing to > use make-before-break of LSPs... > > Khuzema. > > > Rajesh P Jain wrote: > > > > "Hi", > > I would also like to know if this Session > Attribute OBJECT > > anyway helpful in Rerouting Traffic Engineered Tunnels?? Is > the information > > present in this object anyway useful in "make-before-break" concept? > > > > TIA > > Rajesh P Jain > > > > "Feng, Mark" wrote: > > > > > Ping, > > > > > > I know the name implies the attributes belong to the > session. But does it > > > mean all senders, i.e. ingress routers, need to have the > same session > > > attributes? Should the transit nodes reject the new Path > message, if the > > > session attributes are different from other senders of > the same session, > > > because there is no rule on "merging" the session attributes? > > > > > > Thanks. > > > > > > - Mark > > > > > > > -----Original Message----- > > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > > Sent: Tuesday, July 17, 2001 9:37 PM > > > > To: Khuzema Pithewan > > > > Cc: rsvp@ISI.EDU > > > > Subject: Re: Session Attributes > > > > > > > > > > > > Khuzema, > > > > > > > > First, this question should go to the mpls list. Please > forward the > > > > discussion to that list. Second, the question itself is > implementation > > > > dependent. Finally, since the Session Attribute object > is to describe > > > > the properties of a RSVP session, in a normal implementation, > > > > it should > > > > be kept where you keep the session. > > > > > > > > - Ping > > > > > > > > Khuzema Pithewan wrote: > > > > > > > > > > Hi, > > > > > > > > > > Session Attribute Object in RSVP-TE contains some > flags , setup and > > > > > holding priority and some session related info. > > > > > > > > > > My doubt is , if this object is per session or per LSP, > > > > because name > > > > > suggest > > > > > that it is per session, but holding/setup priorities are > > > > the attributes > > > > > of a LSP. > > > > > so basically where to keep this Object,?? in PSB or > Session??? > > > > > > > > > > Khuzema. > > > > > > From owner-mpls@UU.NET Thu Jul 19 14:59: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 SMTP id OAA14289 for ; Thu, 19 Jul 2001 14:59: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 QQkyjr11677; Thu, 19 Jul 2001 18:58:04 GMT Received: by mail-control.mail.uu.net id QQkyjr00057 for mpls-outgoing; Thu, 19 Jul 2001 18:57: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 QQkyjr00049 for ; Thu, 19 Jul 2001 18:57:22 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 QQkyjr01241 for ; Thu, 19 Jul 2001 18:57:03 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 QQkyjr10491 for ; Thu, 19 Jul 2001 18:57:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA11847 for mpls@uu.net; Thu, 19 Jul 2001 14:57:00 -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 QQkyjr29978 for ; Thu, 19 Jul 2001 18:56: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 QQkyjr10132 for ; Thu, 19 Jul 2001 18:55:02 GMT Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.186.47.7]) id QQkyjr20724 for ; Thu, 19 Jul 2001 18:55:02 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 P1CGD49Y; Thu, 19 Jul 2001 11:56:16 -0700 From: "Vincent Hamrick" To: "'Thomas D. Nadeau'" , "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: LSR MIB question Date: Thu, 19 Jul 2001 15:02:13 -0400 Message-ID: <00bc01c11085$52786040$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: <4.3.2.7.2.20010507085305.018f9ac8@bucket.cisco.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dredging this conversation back up .... To clarify, there are three labels being tracked here, right? LSR inbound stats for the label (which will be removed, in theory) that arrived at the LSR. LSR outbound stats for the label that replaces the incoming label. And finally, LSR outbound stats for the label pushed. Have I correctly summarized? Thanks, -V -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. Nadeau Sent: Monday, May 07, 2001 8:54 AM To: Shahram Davari; 'mpls@uu.net' Subject: Re: LSR MIB question Both. You should keep track of information for both of the labels involved. --Tom >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 > > From owner-mpls@UU.NET Thu Jul 19 15:11: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 SMTP id PAA17423 for ; Thu, 19 Jul 2001 15:11: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 QQkyjs06602; Thu, 19 Jul 2001 19:01:36 GMT Received: by mail-control.mail.uu.net id QQkyjs01443 for mpls-outgoing; Thu, 19 Jul 2001 19:00:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkyjs01224 for ; Thu, 19 Jul 2001 19:00:43 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 QQkyjs02955 for ; Thu, 19 Jul 2001 19:00:17 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 QQkyjs14661 for ; Thu, 19 Jul 2001 19:00:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA12196 for mpls@uu.net; Thu, 19 Jul 2001 15:00:16 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkyjr00402 for ; Thu, 19 Jul 2001 18:59:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyjr14351 for ; Thu, 19 Jul 2001 18:57:56 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 QQkyjr23148 for ; Thu, 19 Jul 2001 18:57:55 GMT Received: (qmail 3690 invoked by uid 104); 19 Jul 2001 18:57:55 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.397983 secs); 19/07/2001 11:57:54 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 19 Jul 2001 18:57:54 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6JIvwP10835; Thu, 19 Jul 2001 11:57:58 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 12:03:37 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D95@BBY1EXM01> From: Shahram Davari To: "'Vincent Hamrick'" , "'Thomas D. Nadeau'" , "'mpls@uu.net'" Subject: RE: LSR MIB question Date: Thu, 19 Jul 2001 12:03:35 -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 Yes. -Shahram > -----Original Message----- > From: Vincent Hamrick [mailto:hamrick@coronanetworks.com] > Sent: Thursday, July 19, 2001 3:02 PM > To: 'Thomas D. Nadeau'; Shahram Davari; 'mpls@uu.net' > Subject: RE: LSR MIB question > > > Dredging this conversation back up .... > > To clarify, there are three labels being tracked here, right? > LSR inbound > stats for the label (which will be removed, in theory) that > arrived at the > LSR. LSR outbound stats for the label that replaces the > incoming label. > And finally, LSR outbound stats for the label pushed. > > Have I correctly summarized? > > Thanks, > -V > > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Thomas D. > Nadeau > Sent: Monday, May 07, 2001 8:54 AM > To: Shahram Davari; 'mpls@uu.net' > Subject: Re: LSR MIB question > > > > Both. You should keep track of information for both of > the labels involved. > > --Tom > > > >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 > > > > > From owner-mpls@UU.NET Thu Jul 19 16:40: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 QAA10136 for ; Thu, 19 Jul 2001 16:40: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 QQkyjy23055; Thu, 19 Jul 2001 20:39:06 GMT Received: by mail-control.mail.uu.net id QQkyjy23236 for mpls-outgoing; Thu, 19 Jul 2001 20:38: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 QQkyjy23221 for ; Thu, 19 Jul 2001 20:38: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 QQkyjy27668 for ; Thu, 19 Jul 2001 20:37:44 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 QQkyjy00818 for ; Thu, 19 Jul 2001 20:37:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA20954 for mpls@uu.net; Thu, 19 Jul 2001 16:37: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 QQkyjy23118 for ; Thu, 19 Jul 2001 20:36:57 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 QQkyjy17061 for ; Thu, 19 Jul 2001 20:35:15 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 QQkyjy27937 for ; Thu, 19 Jul 2001 20:35:15 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 QAA26364; Thu, 19 Jul 2001 16:35:04 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225]) by bucket.cisco.com (Mirapoint) with ESMTP id ADT07249; Thu, 19 Jul 2001 16:35:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719163951.02739c68@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 16:40:01 -0400 To: "Vincent Hamrick" , "'Shahram Davari'" , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: RE: LSR MIB question In-Reply-To: <00bc01c11085$52786040$0808650a@coronanetworks.com> References: <4.3.2.7.2.20010507085305.018f9ac8@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Dredging this conversation back up .... > >To clarify, there are three labels being tracked here, right? LSR inbound >stats for the label (which will be removed, in theory) that arrived at the >LSR. LSR outbound stats for the label that replaces the incoming label. >And finally, LSR outbound stats for the label pushed. > >Have I correctly summarized? I believe that is correct. --Tom >Thanks, >-V > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. >Nadeau >Sent: Monday, May 07, 2001 8:54 AM >To: Shahram Davari; 'mpls@uu.net' >Subject: Re: LSR MIB question > > > > Both. You should keep track of information for both of >the labels involved. > > --Tom > > > >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 > > > > From owner-mpls@UU.NET Thu Jul 19 17:06: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 RAA13624 for ; Thu, 19 Jul 2001 17:06: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 QQkyka15393; Thu, 19 Jul 2001 21:05:50 GMT Received: by mail-control.mail.uu.net id QQkyka06316 for mpls-outgoing; Thu, 19 Jul 2001 21:05: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 QQkyka06294 for ; Thu, 19 Jul 2001 21:05:12 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 QQkyka29056 for ; Thu, 19 Jul 2001 21:02:55 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 QQkyka24734 for ; Thu, 19 Jul 2001 21:02:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA22941 for mpls@uu.net; Thu, 19 Jul 2001 17:02: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 QQkyka26697 for ; Thu, 19 Jul 2001 21:00:27 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 QQkyjz24334 for ; Thu, 19 Jul 2001 20:59:39 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQkyjz10042 for ; Thu, 19 Jul 2001 20:59:38 GMT Received: (qmail 28975 invoked from network); 19 Jul 2001 20:57:38 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 19 Jul 2001 20:57:38 -0000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Thu, 19 Jul 2001 16:57:55 -0400 Received: from alcatel.com ([138.120.63.49]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA45E7 for ; Thu, 19 Jul 2001 16:57:54 -0400 Message-Id: <3B5749AD.B3EA5369@alcatel.com> Date: Thu, 19 Jul 2001 16:57:17 -0400 From: "STEVE HAWKINS" Organization: Newbridge Networks Corp. X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit subscribe From owner-mpls@UU.NET Thu Jul 19 17:24: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 RAA16191 for ; Thu, 19 Jul 2001 17:24: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 QQkykb04673; Thu, 19 Jul 2001 21:24:14 GMT Received: by mail-control.mail.uu.net id QQkykb18478 for mpls-outgoing; Thu, 19 Jul 2001 21:23: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 QQkykb18467 for ; Thu, 19 Jul 2001 21:23: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 QQkykb26388 for ; Thu, 19 Jul 2001 21:20:47 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 QQkykb14069 for ; Thu, 19 Jul 2001 21:20:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA24695 for mpls@uu.net; Thu, 19 Jul 2001 17:20: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 QQkykb18133 for ; Thu, 19 Jul 2001 21:20:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkykb05084 for ; Thu, 19 Jul 2001 21:19:02 GMT Received: from hawk.CrescentNetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.crescentnetworks.com [64.64.148.44]) id QQkykb24188 for ; Thu, 19 Jul 2001 21:19:02 GMT Received: from crescentnetworks.com (dhcp60.in.crescentnets.com [192.168.29.60]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id RAA22643; Thu, 19 Jul 2001 17:18:42 -0400 (EDT) Message-ID: <3B574EDF.836F43F3@crescentnetworks.com> Date: Thu, 19 Jul 2001 17:19:27 -0400 From: Joan Cucchiara Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ju, Yu" CC: "'mpls@uu.net'" Subject: Re: LDP mib question References: <39469E08BD83D411A3D900204840EC5537DD6B@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 "Ju, Yu" wrote: > > Hi, Hi Yu, > > I have several questions regarding draft-ietf-mpls-ldp-mib-07.txt. > > 1) When mplsLdpEntityIndex is needed to identify an LDP entity? It looks to > me that mplsLdpEntityLdpId itself is good enough. At one point we had only one index and were asked to add a second index (particularly for PPP). In order to allow the LDP MIB to be supported by the different implementations (such as PPP) a second index was added. If your implementation doesn't make use of this second index, it does still need to be supported for SNMP. > > 2) mplsLdpEntityConfGenericIfIndexOrZero represents either the > InterfaceIndex of the 'ifLayer" where there Generic Label would be created. > What if there are multiple interfaces that use the same label range? > mplsLdpEntityConfGenericIfIndexOrZero can only hold one interfaceIndex > value. Yes, and this ifIndex value should appear in the ifStack such that the layers under this ifIndex will lead to ifIndices for the physical ports (Ethernet or whatever). That is what is meant by the InterfaceIndex of the "ifLayer" where these generic labels are created (iftype of 166). The generic labels need to be maintained and co-ordinated across more than one physical port in the perPlatform case. > > 3) Isn't mplsLdpPeerId itself good enough to identify a LDP peer? Why > mplsLdpEntityLdpId and mplsLDPEntityIndex are also part of the index of > mplsLdpPeerEntry? Peer information is learned by a specific LDP entity during session initialization so that is why it is indexed as it is. The indexes enforce this relationship of between a given entity and peer. -Joan > > Thanks, > > Yu From owner-mpls@UU.NET Thu Jul 19 17:38: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 RAA19659 for ; Thu, 19 Jul 2001 17:38: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 QQkykc11107; Thu, 19 Jul 2001 21:31:01 GMT Received: by mail-control.mail.uu.net id QQkykc19881 for mpls-outgoing; Thu, 19 Jul 2001 21:30: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 QQkykc19870 for ; Thu, 19 Jul 2001 21:30:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkykb28842 for ; Thu, 19 Jul 2001 21:28:16 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 QQkykb00537 for ; Thu, 19 Jul 2001 21:28:16 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 f6JLRq901245 for ; Thu, 19 Jul 2001 17:27:52 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 19 Jul 2001 17:27:52 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 17:27:54 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD34105D2B@zcard0ka.ca.nortel.com> From: "Mina Azad" To: mpls-list Subject: RE: draft-pan-lsp-ping-00.txt discussion Date: Thu, 19 Jul 2001 17:27:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11099.ABC32C20" 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_01C11099.ABC32C20 Content-Type: text/plain; charset="iso-8859-1" The discussion on draft-pan-lsp-ping-00.txt has been a lengthy but very fruitful - as it surfaced a number of underlying requirements. Unfortunately, the discussion lost the sight of basic issues: generality, framework, and ownership. Generality: The draft has a narrow focus (RSVP specific, requires a healthy control-plane, ...). There are now two general true user-plane solutions in front of IETF: draft-azad-mpls-oam-messaging-00.txt that proposes use of user-plane probe & loopback mechanism, and draft-harrison-mpls-oam-00.txt that proposes continuity verification. Framework: draft-allan-mpls-oam-frmwk-00.txt provides a discussion on OAM issues, and proposes a multi-operational domain framework. Ownership: Big question or a challenge?! Which working group will own MPLS user-plane OAM? Regards, Mina Azad ------_=_NextPart_001_01C11099.ABC32C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-pan-lsp-ping-00.txt discussion

The discussion on draft-pan-lsp-ping-00.txt has been = a lengthy but very fruitful - as it surfaced a number of underlying = requirements. Unfortunately, the discussion lost the sight of basic = issues: generality, framework, and ownership.

Generality: The draft has a narrow focus (RSVP = specific, requires a healthy control-plane, ...). There are now two = general true user-plane solutions in front of IETF: = draft-azad-mpls-oam-messaging-00.txt that proposes use of user-plane = probe & loopback mechanism, and draft-harrison-mpls-oam-00.txt that = proposes continuity verification.

Framework: draft-allan-mpls-oam-frmwk-00.txt provides = a discussion on OAM issues, and proposes a multi-operational domain = framework.

Ownership: Big question or a challenge?! Which = working group will own MPLS user-plane OAM?

Regards,

Mina Azad

------_=_NextPart_001_01C11099.ABC32C20-- From owner-mpls@UU.NET Thu Jul 19 19:40: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 TAA17101 for ; Thu, 19 Jul 2001 19:40: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 QQkykk05342; Thu, 19 Jul 2001 23:40:01 GMT Received: by mail-control.mail.uu.net id QQkykk09970 for mpls-outgoing; Thu, 19 Jul 2001 23:39: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 QQkykk09959 for ; Thu, 19 Jul 2001 23:39:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkykk15192 for ; Thu, 19 Jul 2001 23:34:17 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 QQkykk17238 for ; Thu, 19 Jul 2001 23:34:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA02505 for mpls@uu.net; Thu, 19 Jul 2001 19:34:17 -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 QQkykk09614 for ; Thu, 19 Jul 2001 23:33: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 QQkykk22911 for ; Thu, 19 Jul 2001 23:32:58 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkykk16533 for ; Thu, 19 Jul 2001 23:32:58 GMT Received: from mira1.cisco.com (mira1.cisco.com [171.71.208.193]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6JNWBX22303; Thu, 19 Jul 2001 16:32:12 -0700 (PDT) Received: from cisco.com (skatukam-u5.cisco.com [171.71.213.88]) by mira1.cisco.com (Mirapoint) with ESMTP id ABB06857; Thu, 19 Jul 2001 16:31:47 -0700 (PDT) Message-ID: <3B576DE3.D0BDA5AB@cisco.com> Date: Thu, 19 Jul 2001 16:31:47 -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: Shahram Davari CC: Eric Gray , "'Ping Pan'" , "'mpLS@UU.net'" Subject: Re: LSP-ping References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D8B@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping, Shahram, Is the following question in Shahram's mail answered? Thanks, Suresh Shahram Davari wrote: > > Hi Ping, > > Could you please clarify, which mechanism finds that there is a problem in the first place. Is it customer complain, or do you run ICMP-ping continuously over the life of the LSP? > > -Shahram > > > -----Original Message----- > > From: Peter Willis [mailto:pjw@ip-engineering.bt.com] > > Sent: Wednesday, July 18, 2001 5:30 AM > > To: Eric Gray > > Cc: erosen@cisco.com; Shahram Davari; 'mpLS@UU.net' > > Subject: Re: LSP-ping > > > > > > Colleagues, > > > > Perhaps the draft-pan-lsp-ping-00.txt can be modified to make > > it more clear > > that this is a DIAGNOSTIC tool used AFTER the LSP has failed > > to deliver user > > traffic. The draft says this clearly in Section 4 > > "Motivation" but does not > > make this clear in the Abstract and Section 3 where it says > > "This document describes a simple and efficient mechanism that can be > > used to detect data plane failures in MPLS LSP's" > > > > I think instead of saying "used to detect data plane > > failures" it should say > > "used to diagnose data plane failures". > > > > If this wording was changed I would be a lot happier with this draft. > > > > Then I can go on to point out that the actual DETECTION > > mechanism used by this > > draft is the customer, that is the customer notices > > connectivity has failed > > and this triggers diagnostics. So we still need a mechanism > > to detect LSP > > failure. > > > > > > -------------------------------------------------------------- > > ------------------ > > Peter Willis > > peter.j.willis@bt.com > > IP Technology Strategist Phone: > > +44 (0)1473 645178 > > Chief Technology Office Fax: > > +44 (0)1473 644506 > > BTexact Technologies. > > PP3, RSB10, Adastral Park, Martlesham, Ipswich IP5 3RE, UK. > > -------------------------------------------------------------- > > ------------------ > > > > From owner-mpls@UU.NET Thu Jul 19 20:40: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 UAA08656 for ; Thu, 19 Jul 2001 20:40: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 QQkyko09391; Fri, 20 Jul 2001 00:39:45 GMT Received: by mail-control.mail.uu.net id QQkyko05075 for mpls-outgoing; Fri, 20 Jul 2001 00:39:14 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 QQkyko05064 for ; Fri, 20 Jul 2001 00:39:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkyko05985 for ; Fri, 20 Jul 2001 00:34:12 GMT Received: from web14903.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14903.mail.yahoo.com [216.136.225.55]) id QQkyko25135 for ; Fri, 20 Jul 2001 00:34:11 GMT Message-ID: <20010720003411.12640.qmail@web14903.mail.yahoo.com> Received: from [65.194.140.2] by web14903.mail.yahoo.com via HTTP; Thu, 19 Jul 2001 17:34:11 PDT Date: Thu, 19 Jul 2001 17:34:11 -0700 (PDT) From: Ravi Shekhar Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: erosen@cisco.com, Sanjay Wadhwa Cc: Ping Pan , "Punj, Arun" , mpls-list In-Reply-To: <200107191502.LAA08296@erosen-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk > So then I think then the base requirement for the routing of the response > from the egress is that it be reverse-path-forwarded back to the ingress, > i.e., that it follow the path of label distribution from egress to ingress. That seems to be the right way to me. One possible way to achieve this is as a 4 step process - first 2 to gather the hop-by-hop path from ingress to egress node and the next 2 to do the ping on LSP: 1) Initiate a UDP packet at ingress and send it to the next hop for the LSP to be traced (i.e. destination IP address is the address of the next hop for LSP and not the egress address itself). Have enough information (like ingress router/egress router address/label) in the UDP packet to uniquely identify the LSP. Every hop(including ingress/egress) on the way appends its hop information and sends this packet to the next hop of the LSP. 2) When this UDP packet reaches egress, egress sends it back to the ingress hop-by-hop in the reverse order of the way path was traced(and recorded in the packet) in step 1. Sending it this way ensures that it reaches the ingress. 3) At this point ingress has the elaborated hop-by-hop path for the LSP from ingress to egress. It now generates a UDP packet at ingress with the destination address of the egress. Since the UDP packet's destination is egress node, it should traverse the LSP now. Inside the UDP packet fill in the path that was traced in step 1 (and received by ingress in step 2). 4) If egress receives the UDP packet sent in step 3 via LSP, it can use the hop-by-hop information contained in the packet and send a response back hop-by-hop to the ingress (the same way it sent it back in step 2). This should work independent of the protocol that sets up the LSP (and across multiple protocols). Since a unique return path for response is already recorded while traversing in the forward direction of LSP (i.e. from ingress to egress) in step 1, it would work for LDP too where same label might have been handed over to multiple upstreams. Some other useful information can also be gathered. Like protocol that set up the LSP on each hop interface / timestamp and number-of-packets-forwarded-on -the-LSP in steps 2 and 4 to calculate the rate of forwarding on LSP etc. Maximum number of hops to be traced can be specified by the ingress (and decremented at each hop) to prevent looping of message in step 1 forever. Indication of failure of LSP or reaching maximum number of hops at any hop can be put in the UDP packet and sent back to ingress in step 2. - Ravi Shekhar. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Jul 19 21:20: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 SMTP id VAA22317 for ; Thu, 19 Jul 2001 21:20: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 QQkykr20787; Fri, 20 Jul 2001 01:19:29 GMT Received: by mail-control.mail.uu.net id QQkykr28090 for mpls-outgoing; Fri, 20 Jul 2001 01:18: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 QQkykr28084 for ; Fri, 20 Jul 2001 01:18: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 QQkykr08445 for ; Fri, 20 Jul 2001 01:18:21 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 QQkykr29618 for ; Fri, 20 Jul 2001 01:18:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA08051 for mpls@uu.net; Thu, 19 Jul 2001 21:18:21 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkykr28043 for ; Fri, 20 Jul 2001 01:17:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkykr04570 for ; Fri, 20 Jul 2001 01:15:23 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkykr28200 for ; Fri, 20 Jul 2001 01:15:23 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6K1FMH15374; Thu, 19 Jul 2001 18:15:22 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B578622.BF781C3C@juniper.net> Date: Thu, 19 Jul 2001 18:15:14 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ravi Shekhar CC: mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <20010720003411.12640.qmail@web14903.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 Ravi, This is one of the many solutions we had talked about before. See below. Ravi Shekhar wrote: > > That seems to be the right way to me. One possible way to achieve this is > as a 4 step process - first 2 to gather the hop-by-hop path from ingress to > egress node and the next 2 to do the ping on LSP: > > 1) Initiate a UDP packet at ingress and send it to the next hop for the LSP to > be traced (i.e. destination IP address is the address of the next hop for > LSP and not the egress address itself). > Have enough information (like ingress router/egress router address/label) > in the UDP packet to uniquely identify the LSP. > Every hop(including ingress/egress) on the way appends its hop information > and sends this packet to the next hop of the LSP. > 2) When this UDP packet reaches egress, egress sends it back to the ingress > hop-by-hop in the reverse order of the way path was traced(and recorded in > the packet) in step 1. Sending it this way ensures that it reaches the > ingress. In RSVP-TE, this is the RRO object. For RSVP, you can even skip this two steps. > 3) At this point ingress has the elaborated hop-by-hop path for the LSP from > ingress to egress. It now generates a UDP packet at ingress with the > destination address of the egress. Since the UDP packet's destination is > egress node, it should traverse the LSP now. Inside the UDP packet fill in > the path that was traced in step 1 (and received by ingress in step 2). > 4) If egress receives the UDP packet sent in step 3 via LSP, it can use the > hop-by-hop information contained in the packet and send a response back > hop-by-hop to the ingress (the same way it sent it back in step 2). > > This should work independent of the protocol that sets up the LSP (and across > multiple protocols). Since a unique return path for response is already > recorded while traversing in the forward direction of LSP (i.e. from ingress > to egress) in step 1, it would work for LDP too where same label might have > been handed over to multiple upstreams. > Yep! This is all nice, but it is *not* backward compatible. In a network that has many routers, if one of them does not support this, the test will fail. Also this is a self supply-demand condition: with one implementation bug on one of the LSR's, a whole bunch of LSP's may get torn down. So your approach is best to debug own bugs. :-) See, the LSP-ping proposal works, because it is based on the assumption: the only working path from egress to ingress is the control path itself. It is simple (no extra signaling other than adding one object) and backward compatible (no change to the network LSR's). - Ping From owner-mpls@UU.NET Thu Jul 19 21:28: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 VAA24972 for ; Thu, 19 Jul 2001 21:28:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkykr28766; Fri, 20 Jul 2001 01:27:55 GMT Received: by mail-control.mail.uu.net id QQkykr28689 for mpls-outgoing; Fri, 20 Jul 2001 01:27: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 QQkykr28677 for ; Fri, 20 Jul 2001 01:27:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkykr12992 for ; Fri, 20 Jul 2001 01:26:44 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkykr06084 for ; Fri, 20 Jul 2001 01:26:44 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6K1QgH15975; Thu, 19 Jul 2001 18:26:42 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200107200126.f6K1QgH15975@merlot.juniper.net> To: "Mina Azad" cc: mpls-list Subject: Re: draft-pan-lsp-ping-00.txt discussion In-Reply-To: Your message of "Thu, 19 Jul 2001 17:27:54 EDT." <3549C09B853DD5119B540002A52CDD34105D2B@zcard0ka.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7221.995592402.1@juniper.net> Date: Thu, 19 Jul 2001 18:26:42 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Mina, > The discussion on draft-pan-lsp-ping-00.txt has been a lengthy but very > fruitful - as it surfaced a number of underlying requirements. > Unfortunately, the discussion lost the sight of basic issues: generality, > framework, and ownership. There is a difference of opinions on whether such issues as framework and ownership are "basic issues" - an alternative opinion is that these are irrelevant issues. > Generality: The draft has a narrow focus (RSVP specific, requires a healthy > control-plane, ...). There are now two general true user-plane solutions in > front of IETF: draft-azad-mpls-oam-messaging-00.txt that proposes use of > user-plane probe & loopback mechanism, and draft-harrison-mpls-oam-00.txt > that proposes continuity verification. It is certainly correct that the solution described in draft-pan-lsp-ping-00.txt is RSVP specific, and it does require a healthy control-plane. Therefore, this solution is certainly disqualified from being a LTSFGTC (Long Term Solutions For Generations To Come). At the same time, IMHO the efforts of the folks who are pursuing the LTSFGTC should not *in any way* be disrupted/disturbed by any solution that has "a narrow focus" (like the one described in draft-pan-lsp-ping-00.txt). The work on the LTSFGTC should continue unabated. > Framework: draft-allan-mpls-oam-frmwk-00.txt provides a discussion on OAM > issues, and proposes a multi-operational domain framework. Are there any plans to coordinate the work on the framework with other standard-making bodies, like ITU-T, ATM Forum, etc... ? > Ownership: Big question or a challenge?! Which working group will own MPLS > user-plane OAM? How about starting a new Working Group ? Then this working group would own all the OAM-related activities. Yakov. From owner-mpls@UU.NET Fri Jul 20 01:50: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 BAA27211 for ; Fri, 20 Jul 2001 01:50: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 QQkylj08201; Fri, 20 Jul 2001 05:50:20 GMT Received: by mail-control.mail.uu.net id QQkylj08279 for mpls-outgoing; Fri, 20 Jul 2001 05:49: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 QQkylj08264 for ; Fri, 20 Jul 2001 05:49:27 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 QQkylj13158 for ; Fri, 20 Jul 2001 05:48:55 GMT Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkylj00818 for ; Fri, 20 Jul 2001 05:48:51 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6K5iO612988; Fri, 20 Jul 2001 11:14:24 +0530 Message-ID: <3B57C714.E343B7A4@multitech.co.in> Date: Fri, 20 Jul 2001 11:22:20 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: Dipak , "Sharma, Prem" , "'Hong Liao'" , mpls@UU.NET Subject: Re: RSVP-TE and cr-ldp References: <3B566C92.A3E55DDA@multitech.co.in> <4.3.2.7.2.20010719104631.017bc7c0@bucket.cisco.com> Content-Type: multipart/alternative; boundary="------------892B3D4F9967A9778560DE8A" Sender: owner-mpls@UU.NET Precedence: bulk --------------892B3D4F9967A9778560DE8A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Yes,as Eric said,Label space implementations can be implementation specific. Regards, Abhay. "Thomas D. Nadeau" wrote: > > Why one need to have seperate label space for CR-LDP and RSVP-TE? > >In the MPLS-TE-MIB, the object mplsTunnelSignallingProto in > >mplsTunnelTable is enough to identify the controlling signalling > >protocol in use in each LSR. > > This is correct. Within the context of the mpls-te-mib, > when configuring te tunnels it is not important to know where > the labels are coming from to signal the tunnels. This > information is provided by the LSR/LDP MIBs. > > --Tom > > > One doesn't need to know while doing Label > >swapping or popping or pushing that which signalling has been used to > >acquire the Label. And when there is interworking between CR-LDP and > >RSVP-TE, then parts of tunnel will be owned by corresponding signalling > >protocols. > > > >regards, > >dipak > > > >abhay wrote: > > > > > > > > > > > Julia, > > > > > > I guess yes,but maybe one should have separate label pools. > > > > > > I also remember one can do Interworking between CR-LDP and RSVP-TE > > ,each running on separate > > > > > > routers. > > > > > > Regards, > > > > > > Abhay > > > > > > > > > > > > > > > "Sharma, Prem" wrote: > > > > > >> Hi, > > >> > > >> I feel, it's very much possible for an LSR to support both RSVP-TE > > >> and > > >> CR-LDP signalling protocols but one would have to take care of > > >> resource > > >> partitioning (assignment of label ranges) between the signalling > > >> modules. > > >> > > >> Prem > > >> > > >> -----Original Message----- > > >> From: Hong Liao [mailto:hliao@telcordia.com] > > >> Sent: Wednesday, July 18, 2001 3:19 PM > > >> To: mpls@UU.NET > > >> Subject: RSVP-TE and cr-ldp > > >> > > >> Hi, > > >> > > >> Is there anyone can tell me if there is any LSR can support RSVP-TE > > >> and > > >> cr-ldp? > > >> > > >> Thanks in an advance. > > >> > > >> Julia > > > --------------892B3D4F9967A9778560DE8A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi All,
       Yes,as Eric said,Label space implementations can be implementation specific.
       Regards,
       Abhay.


"Thomas D. Nadeau" wrote:

>     Why one need to have seperate label space for CR-LDP and RSVP-TE?
>In the MPLS-TE-MIB,  the object mplsTunnelSignallingProto in
>mplsTunnelTable is enough to identify the controlling signalling
>protocol in use in each LSR.

         This is correct. Within the context of the mpls-te-mib,
when configuring te tunnels it is not important to know where
the labels are coming from to signal the tunnels. This
information is provided by the LSR/LDP MIBs.

         --Tom

>  One doesn't need to know while doing Label
>swapping or popping or pushing that which signalling has been used to
>acquire the Label. And when there is interworking between CR-LDP and
>RSVP-TE, then parts of tunnel will be owned by corresponding signalling
>protocols.
>
>regards,
>dipak
>
>abhay wrote:
>
> >
> >
> > Julia,
> >
> >      I guess yes,but maybe one should have separate label pools.
> >
> >      I also remember one can do Interworking between CR-LDP and RSVP-TE
> ,each running on separate
> >
> >      routers.
> >
> >      Regards,
> >
> >      Abhay
> >
> >
> >
> >
> > "Sharma, Prem" wrote:
> >
> >> Hi,
> >>
> >> I feel, it's very much possible for an LSR to support both RSVP-TE
> >> and
> >> CR-LDP signalling protocols but one would have to take care of
> >> resource
> >> partitioning (assignment of label ranges) between the signalling
> >> modules.
> >>
> >> Prem
> >>
> >> -----Original Message-----
> >> From: Hong Liao [mailto:hliao@telcordia.com]
> >> Sent: Wednesday, July 18, 2001 3:19 PM
> >> To: mpls@UU.NET
> >> Subject: RSVP-TE and cr-ldp
> >>
> >> Hi,
> >>
> >> Is there anyone can tell me if there is any LSR can support RSVP-TE
> >> and
> >> cr-ldp?
> >>
> >> Thanks in an advance.
> >>
> >> Julia
> >

--------------892B3D4F9967A9778560DE8A-- From owner-mpls@UU.NET Fri Jul 20 02:02:26 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 CAA04230 for ; Fri, 20 Jul 2001 02: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 QQkylk20413; Fri, 20 Jul 2001 06:02:25 GMT Received: by mail-control.mail.uu.net id QQkylk15624 for mpls-outgoing; Fri, 20 Jul 2001 06:01: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 QQkylk14282 for ; Fri, 20 Jul 2001 06:01: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 QQkylk15780 for ; Fri, 20 Jul 2001 06:00:53 GMT Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkylk23071 for ; Fri, 20 Jul 2001 06:00:51 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6K5uw613460; Fri, 20 Jul 2001 11:26:58 +0530 Message-ID: <3B57CA06.CF5195AF@multitech.co.in> Date: Fri, 20 Jul 2001 11:34:54 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hong Liao CC: mpls@UU.NET Subject: Re: RSVP-TE and cr-ldp X-Priority: 2 (High) References: Content-Type: multipart/alternative; boundary="------------D8782BD8A6BFF9810DC920D3" Sender: owner-mpls@UU.NET Precedence: bulk --------------D8782BD8A6BFF9810DC920D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julia, Cisco systems,Juniper Networks,Netplane Systems,Harries and Jefferies, are a few I can remember at the moment who support RSVP-TE However they have their own implementation specifics. Regards, Abhay Hong Liao wrote: > Abhay, > > Can you tell me if there is any vendor who can support RSVP-TE? > > Thanks in an advance. > > Julia > > > abhay > > ech.co.in> cc: "'Hong Liao'" , mpls@UU.NET, (bcc: Hong > Liao/Telcordia) > 07/19/01 Subject: Re: RSVP-TE and cr-ldp > 01:13 AM > > > > Julia, > > I guess yes,but maybe one should have separate label pools. > > I also remember one can do Interworking between CR-LDP and RSVP-TE > ,each running on separate > > routers. > > Regards, > > Abhay > > "Sharma, Prem" wrote: > > > Hi, > > > > I feel, it's very much possible for an LSR to support both RSVP-TE and > > CR-LDP signalling protocols but one would have to take care of resource > > partitioning (assignment of label ranges) between the signalling modules. > > > > Prem > > > > -----Original Message----- > > From: Hong Liao [mailto:hliao@telcordia.com] > > Sent: Wednesday, July 18, 2001 3:19 PM > > To: mpls@UU.NET > > Subject: RSVP-TE and cr-ldp > > > > Hi, > > > > Is there anyone can tell me if there is any LSR can support RSVP-TE and > > cr-ldp? > > > > Thanks in an advance. > > > > Julia > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 --------------D8782BD8A6BFF9810DC920D3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Julia,
      Cisco systems,Juniper Networks,Netplane Systems,Harries and Jefferies,
      are a few I can remember at the moment who support RSVP-TE
      However they have their own implementation specifics.
      Regards,
      Abhay


Hong Liao wrote:

Abhay,

Can you tell me if there is any vendor who can support RSVP-TE?

Thanks in an advance.

Julia
 

                    abhay
                    <abhay@multit        To:     "Sharma, Prem" <p_sharma@trillium.com>
                    ech.co.in>           cc:     "'Hong Liao'" <hliao@telcordia.com>, mpls@UU.NET, (bcc: Hong
                                         Liao/Telcordia)
                    07/19/01             Subject:     Re: RSVP-TE and cr-ldp
                    01:13 AM
 
 

Julia,

     I guess yes,but maybe one should have separate label pools.

     I also remember one can do Interworking between CR-LDP and RSVP-TE
,each running on separate

     routers.

     Regards,

     Abhay

"Sharma, Prem" wrote:

> Hi,
>
> I feel, it's very much possible for an LSR to support both RSVP-TE and
> CR-LDP signalling protocols but one would have to take care of resource
> partitioning (assignment of label ranges) between the signalling modules.
>
> Prem
>
> -----Original Message-----
> From: Hong Liao [mailto:hliao@telcordia.com]
> Sent: Wednesday, July 18, 2001 3:19 PM
> To: mpls@UU.NET
> Subject: RSVP-TE and cr-ldp
>
> Hi,
>
> Is there anyone can tell me if there is any LSR can support RSVP-TE and
> cr-ldp?
>
> Thanks in an advance.
>
> Julia

  ------------------------------------------------------------------------
               Name: att1.htm
   att1.htm    Type: Hypertext Markup Language (text/html)
           Encoding: base64

--------------D8782BD8A6BFF9810DC920D3-- From owner-mpls@UU.NET Fri Jul 20 02:22: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 CAA18849 for ; Fri, 20 Jul 2001 02:22: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 QQkyll23241; Fri, 20 Jul 2001 06:22:52 GMT Received: by mail-control.mail.uu.net id QQkyll00681 for mpls-outgoing; Fri, 20 Jul 2001 06:22: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 QQkyll00676 for ; Fri, 20 Jul 2001 06:22:18 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 QQkyll18638 for ; Fri, 20 Jul 2001 06:21:24 GMT Received: from samar.sasken.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkyll07608 for ; Fri, 20 Jul 2001 06:20:08 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f6K6ILg17210; Fri, 20 Jul 2001 11:48:21 +0530 (IST) Received: from sasken.com (pcka172.sasi.com [10.0.82.172]) by sunk3.sasi.com (8.9.3/8.9.3) with ESMTP id LAA13115; Fri, 20 Jul 2001 11:48:19 +0530 (IST) Message-ID: <3B57CD60.3CF8940A@sasken.com> Date: Fri, 20 Jul 2001 11:49:12 +0530 From: Rajesh P Jain Organization: SASKEN Communication Technologies Ltd X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls@uu.net'" CC: "Feng, Mark" , "'Khuzema Pithewan'" Subject: Re: Session Attributes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can someone clarify where should we store the Session Attribute Object ? Also, The draft tells that Session Attribute is an Optional Object. So, Let us consider a case where a Path Message is sent without a Session Attribute Object (As a result, the PSB is set up at all the nodes etc). Now, If we send a Path Message (Of Course for Rerouting a Tunnel) with Session Attribute. So, How will the New Path Message compare Session Attribute Object Details (For the "Make Before Break" or Rerouting) the PSB of the Old Path Message. Does it mean that if we send a Path Message without a Session Attribute Object, some DEFAULT value of (Setup/ Holding Priority etc is stored). If yes, then what is the default value??? TIA Rajesh P Jain "Feng, Mark" wrote: > Also the "local protecion" flag is useful in term of re-routing LSPs in case > of downstream node failure. The resource affinity related vectors are useful > regarding constraint-based routing... > > - Mark > > > -----Original Message----- > > From: Khuzema Pithewan [mailto:khuzema@netbrahma.com] > > Sent: Thursday, July 19, 2001 1:49 AM > > Cc: 'mpls@uu.net' > > Subject: Re: Session Attributes > > > > > > SE Desired flag can be set in Session Attribute if Ingress is > > willing to > > use make-before-break of LSPs... > > > > Khuzema. > > > > > > Rajesh P Jain wrote: > > > > > > "Hi", > > > I would also like to know if this Session > > Attribute OBJECT > > > anyway helpful in Rerouting Traffic Engineered Tunnels?? Is > > the information > > > present in this object anyway useful in "make-before-break" concept? > > > > > > TIA > > > Rajesh P Jain > > > > > > "Feng, Mark" wrote: > > > > > > > Ping, > > > > > > > > I know the name implies the attributes belong to the > > session. But does it > > > > mean all senders, i.e. ingress routers, need to have the > > same session > > > > attributes? Should the transit nodes reject the new Path > > message, if the > > > > session attributes are different from other senders of > > the same session, > > > > because there is no rule on "merging" the session attributes? > > > > > > > > Thanks. > > > > > > > > - Mark > > > > > > > > > -----Original Message----- > > > > > From: Ping Pan [mailto:pingpan@juniper.net] > > > > > Sent: Tuesday, July 17, 2001 9:37 PM > > > > > To: Khuzema Pithewan > > > > > Cc: rsvp@ISI.EDU > > > > > Subject: Re: Session Attributes > > > > > > > > > > > > > > > Khuzema, > > > > > > > > > > First, this question should go to the mpls list. Please > > forward the > > > > > discussion to that list. Second, the question itself is > > implementation > > > > > dependent. Finally, since the Session Attribute object > > is to describe > > > > > the properties of a RSVP session, in a normal implementation, > > > > > it should > > > > > be kept where you keep the session. > > > > > > > > > > - Ping > > > > > > > > > > Khuzema Pithewan wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Session Attribute Object in RSVP-TE contains some > > flags , setup and > > > > > > holding priority and some session related info. > > > > > > > > > > > > My doubt is , if this object is per session or per LSP, > > > > > because name > > > > > > suggest > > > > > > that it is per session, but holding/setup priorities are > > > > > the attributes > > > > > > of a LSP. > > > > > > so basically where to keep this Object,?? in PSB or > > Session??? > > > > > > > > > > > > Khuzema. > > > > > > > > > From owner-mpls@UU.NET Fri Jul 20 05:17: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 FAA00083 for ; Fri, 20 Jul 2001 05:17: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 QQkylx24099; Fri, 20 Jul 2001 09:17:25 GMT Received: by mail-control.mail.uu.net id QQkylx13499 for mpls-outgoing; Fri, 20 Jul 2001 09:16: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 QQkylx13472 for ; Fri, 20 Jul 2001 09:16: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 QQkylx24052 for ; Fri, 20 Jul 2001 09:15:31 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkylx14161 for ; Fri, 20 Jul 2001 09:15:28 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 20 Jul 2001 14:53:48 +0530 Received: from future.futsoft.com (arumugamr.future.futsoft.com [10.20.6.33]) by kailash.future.futsoft.com (8.11.0/8.11.0) with ESMTP id f6K9EaX17095; Fri, 20 Jul 2001 14:44:36 +0530 Message-Id: <3B57F845.6010606@future.futsoft.com> Date: Fri, 20 Jul 2001 14:52:13 +0530 From: Arumugam R Organization: FSL User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: Rajesh P Jain Cc: "'mpls@uu.net'" Subject: Re: Session Attributes References: <3B57CD60.3CF8940A@sasken.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, See inline comments. Rajesh P Jain wrote: > Can someone clarify where should we store the Session Attribute Object ? ### It is left to the implementation, but usually kept in the PSB. > > > Also, The draft tells that Session Attribute is an Optional Object. So, > Let us consider a case where a Path Message is sent without a Session Attribute > Object (As a result, the PSB is set up at all the nodes etc). ### Eventhough it is optional, it is upto the implementation looking for it as a mandatory object. Coming back to you question if you receive a Path message without a Session Attribute object, you have to allocate a FF style for the flow.. > > > Now, If we send a Path Message (Of Course for Rerouting a Tunnel) with > Session Attribute. So, How will the New Path Message compare Session Attribute > Object Details (For the "Make Before Break" or Rerouting) the PSB of the Old > Path Message. ### So you can't reroute the traffic for an FF style flow > > > Does it mean that if we send a Path Message without a Session > Attribute Object, some DEFAULT value of (Setup/ Holding Priority etc is stored). > If yes, then what is the default value??? ### I think it should be your implementation's assumption. The default value can be 4. Reg Arumugam > > TIA > Rajesh P Jain > > > > "Feng, Mark" wrote: > >> Also the "local protecion" flag is useful in term of re-routing LSPs in case >> of downstream node failure. The resource affinity related vectors are useful >> regarding constraint-based routing... >> >> - Mark >> >>> -----Original Message----- >>> From: Khuzema Pithewan [mailto:khuzema@netbrahma.com] >>> Sent: Thursday, July 19, 2001 1:49 AM >>> Cc: 'mpls@uu.net' >>> Subject: Re: Session Attributes >>> >>> >>> SE Desired flag can be set in Session Attribute if Ingress is >>> willing to >>> use make-before-break of LSPs... >>> >>> Khuzema. >>> >>> >>> Rajesh P Jain wrote: >>> >>>> "Hi", >>>> I would also like to know if this Session >>> >>> Attribute OBJECT >>> >>>> anyway helpful in Rerouting Traffic Engineered Tunnels?? Is >>> >>> the information >>> >>>> present in this object anyway useful in "make-before-break" concept? >>>> >>>> TIA >>>> Rajesh P Jain >>>> >>>> "Feng, Mark" wrote: >>>> >>>>> Ping, >>>>> >>>>> I know the name implies the attributes belong to the >>>> >>> session. But does it >>> >>>>> mean all senders, i.e. ingress routers, need to have the >>>> >>> same session >>> >>>>> attributes? Should the transit nodes reject the new Path >>>> >>> message, if the >>> >>>>> session attributes are different from other senders of >>>> >>> the same session, >>> >>>>> because there is no rule on "merging" the session attributes? >>>>> >>>>> Thanks. >>>>> >>>>> - Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: Ping Pan [mailto:pingpan@juniper.net] >>>>>> Sent: Tuesday, July 17, 2001 9:37 PM >>>>>> To: Khuzema Pithewan >>>>>> Cc: rsvp@ISI.EDU >>>>>> Subject: Re: Session Attributes >>>>>> >>>>>> >>>>>> Khuzema, >>>>>> >>>>>> First, this question should go to the mpls list. Please >>>>> >>> forward the >>> >>>>>> discussion to that list. Second, the question itself is >>>>> >>> implementation >>> >>>>>> dependent. Finally, since the Session Attribute object >>>>> >>> is to describe >>> >>>>>> the properties of a RSVP session, in a normal implementation, >>>>>> it should >>>>>> be kept where you keep the session. >>>>>> >>>>>> - Ping >>>>>> >>>>>> Khuzema Pithewan wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Session Attribute Object in RSVP-TE contains some >>>>>> >>> flags , setup and >>> >>>>>>> holding priority and some session related info. >>>>>>> >>>>>>> My doubt is , if this object is per session or per LSP, >>>>>> >>>>>> because name >>>>>> >>>>>>> suggest >>>>>>> that it is per session, but holding/setup priorities are >>>>>> >>>>>> the attributes >>>>>> >>>>>>> of a LSP. >>>>>>> so basically where to keep this Object,?? in PSB or >>>>>> >>> Session??? >>> >>>>>>> Khuzema. >>>>>> From owner-mpls@UU.NET Fri Jul 20 09:28:47 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 JAA25566 for ; Fri, 20 Jul 2001 09:28: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 QQkymn25439; Fri, 20 Jul 2001 13:28:02 GMT Received: by mail-control.mail.uu.net id QQkymn22827 for mpls-outgoing; Fri, 20 Jul 2001 13:27:26 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 QQkymn22809 for ; Fri, 20 Jul 2001 13:27: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 QQkymn03517 for ; Fri, 20 Jul 2001 13:23: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 QQkymn22154 for ; Fri, 20 Jul 2001 13:23:57 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA26340 for ; Fri, 20 Jul 2001 09:23:56 -0400 (EDT) Date: Fri, 20 Jul 2001 09:23:56 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: mpls@UU.NET Subject: MPLS 2001 International Conference Registration-Oct 7-9, Washington DC. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *****************Our apologies if you receive this multiple times********* MPLS2001 International Conference 4th Annual International Conference on MPLS October 7-9, 2001 Omni Shoreham Hotel, Washington, DC. Hosted jointly by UUNET Technologies/Worldcom and Advanced Internet Laboratory Program Schedule Tutorials : October 7, 1:00 - 6:00 Conference sessions : October 8-9, 8:30 am - 6:00 pm Exhibits : October 8-9 2nd Public Inter-Op Demo: October 10-12 MPLS 2001, 4th Annual International Conference on MPLS, co-hosted by WorldCom (UUNET Technologies) and Advanced Internet Lab of GMU, is being sponsored by Agilent Technologies, Alcatel, Avici Systems, Cisco Systems, Data Connection, Ericsson, IXIA, Lucent Technologies, Metera Networks, Nortel Networks, Ocular Networks, OPNET Technologies, Spirent Communications, Unisphere Networks, and Wavesmith Networks. Sponsors will be exhibiting their products and services throughout the day Monday and Tuesday. MPLS 2001 offers an excellent blend of various topics covering important aspects of MPLS and its application in Optical Networks. The preliminary technical program has been posted at MPLS 2001 web site under technical sessions (http://www.mpls2001.com/technical.htm) and will be continuously updated. You may register for MPLS 2001 either On-line or Off-line by visiting http://www.mpls2001.com/registration.htm and following the instructions. The early registration fees are extremely attractive and we hope that you can benefit from the opportunity and pre-register for MPLS2001 soon. If you are planning to attend MPLS 2001, you may want to make your hotel reservations now as we have blocked limited number rooms at Omni Shoreham Hotel (Conference Venue and the designated hotel) at special rates. In order to benefit from the discounted conference rate, we urge you to make your reservations immediately. You may visit (http://www.mpls2001.com/hotels.htm) for more information on hotel reservations. For any additional information, please visit http://www.mpls2001.com. We look forward to seeing you in the "MPLS 2001 International Conference." Thanks. Regards, -Rajiv From owner-mpls@UU.NET Fri Jul 20 09:34: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 JAA27993 for ; Fri, 20 Jul 2001 09:34: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 QQkymo12648; Fri, 20 Jul 2001 13:34:10 GMT Received: by mail-control.mail.uu.net id QQkymo23525 for mpls-outgoing; Fri, 20 Jul 2001 13:33: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 QQkymo23511 for ; Fri, 20 Jul 2001 13:33: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 QQkymo29291 for ; Fri, 20 Jul 2001 13:30:44 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 QQkymo29544 for ; Fri, 20 Jul 2001 13:30:43 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 f6KDUZE08837; Fri, 20 Jul 2001 15:30:40 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A8F.004A325E ; Fri, 20 Jul 2001 15:30:25 +0200 X-Lotus-FromDomain: ALCATEL To: David Charlap cc: mpls@UU.NET Message-ID: Date: Fri, 20 Jul 2001 15:30:18 +0200 Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk David>> Forward-going messages (Path, PathTear, ResvErr and ResvConf) are sent David>> with router alert and have the egress router's address in the IP David>> header. David, Referring to section 3.1.8 of RFC 2205, I think the ResvErr is sent with the unicast address of a next-hop node as the IP DA. Kind regards, Francis. David Charlap on 18/07/2001 01:46:02 To: mpls-list cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] Punj, Arun wrote: > Matt Squire wrote: >> >> What prevents a packet with a router alert flag set from being >> sent over an LSP? I don't recall anything in the specs that >> specifies router alter packets can't be LSP'd. > > Interesting.. Should it not be in the spec? If not, than are you > not changing the meaning of router alert. If yes, Eric's solution > seems perfectly OK, although it would require some sort of > additional support on the intermediate nodes. Logically, it would not make sense to forward a router-alerted packet into an LSP. The purpose of router alert is so that intermediate nodes will closely examine the packet, and possibly intercept it for processing. The purpose of an LSP is to quickly forward a packet with a minimum of processing by the transit routers. These are two diametrically opposed goals. Nevertheless, I don't think there is anything forbidding a router from sending a router-alert packet into an LSP. > Presumably router alert is the reason why the RSVP messages > are finding the way back in reverse direction!! RSVP Resv messages are targetted at the PHOP router, so even if they would be sent into an LSP, they'd still arrive at the same place. Forward-going messages (Path, PathTear, ResvErr and ResvConf) are sent with router alert and have the egress router's address in the IP header. In theory, they could be forwarded into an LSP, but any router doing this wouldn't be able to process the messages and would therefore not be a useful participant in the signaling process. (Unless that LSP terminates at the next-hop router.) -- David From owner-mpls@UU.NET Fri Jul 20 11:14:32 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 LAA00213 for ; Fri, 20 Jul 2001 11:14:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkymv16147; Fri, 20 Jul 2001 15:15:24 GMT Received: by mail-control.mail.uu.net id QQkymu13431 for mpls-outgoing; Fri, 20 Jul 2001 15:14: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 QQkymu13394 for ; Fri, 20 Jul 2001 15:14: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 QQkymu07212 for ; Fri, 20 Jul 2001 15:14:36 GMT From: Umit.Inan@alcatel.com.tr 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 QQkymu23435 for ; Fri, 20 Jul 2001 15:14:35 GMT Received: from trmta001.alcatel.com.tr (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f6KFEUW27105 for ; Fri, 20 Jul 2001 17:14:31 +0200 (MET DST) Received: by trmta001.alcatel.com.tr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C2256A8F.0052B514 ; Fri, 20 Jul 2001 18:03:23 +0300 X-Lotus-FromDomain: ALCATEL To: mpls@UU.NET Message-ID: Date: Fri, 20 Jul 2001 18:07:06 +0300 Subject: RSVP-TE tunnel using static route possible ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, How to configure MPLS RSVP-TE on Cisco7513 (IOS 12.2) as PE and make it work properly with Juniper LSR? and is it possible to use static route between LER and LSR to setup RSVP-TE tunnel? Best regards, From owner-mpls@UU.NET Fri Jul 20 11:33: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 LAA03740 for ; Fri, 20 Jul 2001 11:33: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 QQkymw02598; Fri, 20 Jul 2001 15:34:18 GMT Received: by mail-control.mail.uu.net id QQkymw16464 for mpls-outgoing; Fri, 20 Jul 2001 15:33: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 QQkymw16445 for ; Fri, 20 Jul 2001 15:33:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkymw07088 for ; Fri, 20 Jul 2001 15:30:32 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkymw29728 for ; Fri, 20 Jul 2001 15:30:31 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6KFUMH51961; Fri, 20 Jul 2001 08:30:24 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id IAA03766; Fri, 20 Jul 2001 08:30:22 -0700 (PDT) Date: Fri, 20 Jul 2001 08:30:22 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107201530.IAA03766@kummer.juniper.net> To: mpls@UU.NET, Umit.Inan@alcatel.com.tr Subject: Re: RSVP-TE tunnel using static route possible ? In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Hi, It's not appropriate to use the MPLS WG mailing list for vendor-specific questions -- use the vendors' support mailing lists instead. I'll answer you off-line. Kireeti. From owner-mpls@UU.NET Fri Jul 20 11:35: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 LAA04090 for ; Fri, 20 Jul 2001 11:35: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 QQkymw04207; Fri, 20 Jul 2001 15:36:04 GMT Received: by mail-control.mail.uu.net id QQkymw16638 for mpls-outgoing; Fri, 20 Jul 2001 15:35:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkymw16601 for ; Fri, 20 Jul 2001 15:35:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkymw09628 for ; Fri, 20 Jul 2001 15:32:54 GMT Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.129.242.157]) id QQkymw06826 for ; Fri, 20 Jul 2001 15:32:53 GMT Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6KFWX923665 for ; Fri, 20 Jul 2001 11:32:33 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 20 Jul 2001 11:32:37 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 11:32:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD34105ED5@zcard0ka.ca.nortel.com> From: "Mina Azad" To: Yakov Rekhter Cc: mpls-list Subject: RE: draft-pan-lsp-ping-00.txt discussion Date: Fri, 20 Jul 2001 11:32:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11131.300F66F0" 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_01C11131.300F66F0 Content-Type: text/plain; charset="iso-8859-1" Yakov, Thank you for your response. See my comments inline ("Mina:..."). Regards, Mina > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Thursday, July 19, 2001 9:27 PM > To: Azad, Mina [CAR:CS67:EXCH] > Cc: mpls-list > Subject: Re: draft-pan-lsp-ping-00.txt discussion > > > Mina, > > > The discussion on draft-pan-lsp-ping-00.txt has been a > lengthy but very > > fruitful - as it surfaced a number of underlying requirements. > > Unfortunately, the discussion lost the sight of basic > issues: generality, > > framework, and ownership. > > There is a difference of opinions on whether such issues as > framework and ownership are "basic issues" - an alternative opinion > is that these are irrelevant issues. > > > Generality: The draft has a narrow focus (RSVP specific, > requires a healthy > > control-plane, ...). There are now two general true > user-plane solutions in > > front of IETF: draft-azad-mpls-oam-messaging-00.txt that > proposes use of > > user-plane probe & loopback mechanism, and > draft-harrison-mpls-oam-00.txt > > that proposes continuity verification. > > It is certainly correct that the solution described in > draft-pan-lsp-ping-00.txt is RSVP specific, and it does require a > healthy control-plane. Therefore, this solution is certainly > disqualified from being a LTSFGTC (Long Term Solutions For Generations > To Come). > > At the same time, IMHO the efforts of the folks who are pursuing > the LTSFGTC should not *in any way* be disrupted/disturbed by > any solution that has "a narrow focus" (like the one described in > draft-pan-lsp-ping-00.txt). The work on the LTSFGTC should continue > unabated. > Mina: The draft draft-allan-mpls-oam-frmwk-00.txt is a step forward towards making MPLS the network technology of choice by recommending a multi-operator management approach. It highlights what's doable today and what needs to be achieved in the future. The draft draft-azad-mpls-oam-messaging-00.txt focuses on a solution that can be implemented today. > > Framework: draft-allan-mpls-oam-frmwk-00.txt provides a > discussion on OAM > > issues, and proposes a multi-operational domain framework. > > Are there any plans to coordinate the work on the framework with > other standard-making bodies, like ITU-T, ATM Forum, etc... ? > Mina: Both drafts are stand alone solutions in the IETF. However we recognize the need for coordination of work across IETF and ITU-T. I am working with the ITU-T OAM sub-working group, and aim for solutions that satisfy enterprise and carrier requirements. > > Ownership: Big question or a challenge?! Which working > group will own MPLS > > user-plane OAM? > > How about starting a new Working Group ? Then this working group > would own all the OAM-related activities. > Mina: Excellent suggestion! We will propose a new working group (MPLS management WG) to the area directors in IETF-51. > Yakov. > ------_=_NextPart_001_01C11131.300F66F0 Content-Type: text/html; charset="iso-8859-1" RE: draft-pan-lsp-ping-00.txt discussion

Yakov,
Thank you for your response. See my comments inline ("Mina:...").

Regards,

Mina

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Thursday, July 19, 2001 9:27 PM
> To: Azad, Mina [CAR:CS67:EXCH]
> Cc: mpls-list
> Subject: Re: draft-pan-lsp-ping-00.txt discussion
>
>
> Mina,
>
> > The discussion on draft-pan-lsp-ping-00.txt has been a
> lengthy but very
> > fruitful - as it surfaced a number of underlying requirements.
> > Unfortunately, the discussion lost the sight of basic
> issues: generality,
> > framework, and ownership.
>
> There is a difference of opinions on whether such issues as
> framework and ownership are "basic issues" - an alternative opinion
> is that these are irrelevant issues.
>
> > Generality: The draft has a narrow focus (RSVP specific,
> requires a healthy
> > control-plane, ...). There are now two general true
> user-plane solutions in
> > front of IETF: draft-azad-mpls-oam-messaging-00.txt that
> proposes use of
> > user-plane probe & loopback mechanism, and
> draft-harrison-mpls-oam-00.txt
> > that proposes continuity verification.
>
> It is certainly correct that the solution described in
> draft-pan-lsp-ping-00.txt is RSVP specific, and it does require a
> healthy control-plane.  Therefore, this solution is certainly
> disqualified from being a LTSFGTC (Long Term Solutions For Generations
> To Come).
>
> At the same time, IMHO the efforts of the folks who are pursuing
> the LTSFGTC should not *in any way* be disrupted/disturbed by
> any solution that has "a narrow focus" (like the one described in
> draft-pan-lsp-ping-00.txt). The work on the LTSFGTC should continue
> unabated.
>
Mina: The draft draft-allan-mpls-oam-frmwk-00.txt is a step
forward towards making MPLS the network technology of choice
by recommending a multi-operator management approach. It
highlights what's doable today and what needs to be achieved
in the future. The draft draft-azad-mpls-oam-messaging-00.txt
focuses on a solution that can be implemented today.

> > Framework: draft-allan-mpls-oam-frmwk-00.txt provides a
> discussion on OAM
> > issues, and proposes a multi-operational domain framework.
>
> Are there any plans to coordinate the work on the framework with
> other standard-making bodies, like ITU-T, ATM Forum, etc... ?
>

Mina: Both drafts are stand alone solutions in the IETF. However we
recognize the need for coordination of work across IETF and ITU-T.
I am working with the ITU-T OAM sub-working group, and aim for
solutions that satisfy enterprise and carrier requirements.

> > Ownership: Big question or a challenge?! Which working
> group will own MPLS
> > user-plane OAM?
>
> How about starting a new Working Group ? Then this working group
> would own all the OAM-related activities.
>

Mina: Excellent suggestion! We will propose a new working
group (MPLS management WG) to the area directors in IETF-51.

> Yakov.
>

------_=_NextPart_001_01C11131.300F66F0-- From owner-mpls@UU.NET Fri Jul 20 12:03:30 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 MAA13631 for ; Fri, 20 Jul 2001 12: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 QQkymy00629; Fri, 20 Jul 2001 16:04:20 GMT Received: by mail-control.mail.uu.net id QQkymy26972 for mpls-outgoing; Fri, 20 Jul 2001 16:03:50 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 QQkymy26797 for ; Fri, 20 Jul 2001 16: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 QQkymy14942 for ; Fri, 20 Jul 2001 16:03:41 GMT Received: from web14911.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14911.mail.yahoo.com [216.136.225.249]) id QQkymy25442 for ; Fri, 20 Jul 2001 16:03:41 GMT Message-ID: <20010720160340.16154.qmail@web14911.mail.yahoo.com> Received: from [65.194.140.2] by web14911.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 09:03:40 PDT Date: Fri, 20 Jul 2001 09:03:40 -0700 (PDT) From: Ravi Shekhar Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: Ping Pan Cc: mpls-list In-Reply-To: <3B578622.BF781C3C@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Ping, > > In RSVP-TE, this is the RRO object. For RSVP, you can even skip this two > steps. Thats true, but I am not assuming that an LSP is signalled just using RSVP. It will work for CR-LDP, LDP which might distribute same label to multiple upstreams or any LSP setup using mix of these protocols. (I think one of your mail asked to suggest something which will work for LDP). Infact it will work for multicast(point-to-multipoint) LSPs too. > > Yep! This is all nice, but it is *not* backward compatible. In a network > that has many routers, if one of them does not support this, the test > will fail. > > Also this is a self supply-demand condition: with one implementation bug > on one of the LSR's, a whole bunch of LSP's may get torn down. So your > approach is best to debug own bugs. :-) Isnt that goodness..;-).. LSP and LSP ping assist each other in finding bugs. Anyhow, you could say the same thing for traceroute. If ICMP is not implemented correctly on one of the intermediate hops, it wont work. Infact, this argument will completely shoot down multicast traceroute where state is appended on each intermedidate router. And I bet implementations of LSP ping as you suggest wont be bug immune either..;).. > > See, the LSP-ping proposal works, because it is based on the assumption: > the only working path from egress to ingress is the control path itself. > It is simple (no extra signaling other than adding one object) and > backward compatible (no change to the network LSR's). If by backward compatible you mean that intermediate LSRs do not have to implement LSP-ping, then I agree. But is that really such a big win in the long run? If we are tracing LSP to an LSR(which could be one of these inetwork LSRs) and if we dont recieve a response from it, it could either be because LSP is down or the LSR does not implement LSP-ping. How do you know to distinguish between these two? And if you cant, then indirectly it implies that LSP-ping be implemented on all such routers and I think practically thats what will end up happening. Whichever ping mechanism is used, we will end up having to support it on all the routers. - Ravi Shekhar. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 20 12:47: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 MAA24481 for ; Fri, 20 Jul 2001 12:47: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 QQkynb03385; Fri, 20 Jul 2001 16:48:40 GMT Received: by mail-control.mail.uu.net id QQkynb13286 for mpls-outgoing; Fri, 20 Jul 2001 16:48: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 QQkynb13255 for ; Fri, 20 Jul 2001 16:47:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkyna17439 for ; Fri, 20 Jul 2001 16:44:52 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 QQkyna00316 for ; Fri, 20 Jul 2001 16:44:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA24667 for mpls@uu.net; Fri, 20 Jul 2001 12:44:51 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkyna12778 for ; Fri, 20 Jul 2001 16:44: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 QQkyna29235 for ; Fri, 20 Jul 2001 16:39:54 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkyna26824 for ; Fri, 20 Jul 2001 16:39:53 GMT Received: from juniper.net ([172.16.167.236]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6KGdqH55041; Fri, 20 Jul 2001 09:39:53 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3B585ED1.17BBAF98@juniper.net> Date: Fri, 20 Jul 2001 09:39:45 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ravi Shekhar CC: mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] References: <20010720160340.16154.qmail@web14911.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 Ravi, Ravi Shekhar wrote: > > > > > See, the LSP-ping proposal works, because it is based on the assumption: > > the only working path from egress to ingress is the control path itself. > > It is simple (no extra signaling other than adding one object) and > > backward compatible (no change to the network LSR's). > > If by backward compatible you mean that intermediate LSRs do not have > to implement LSP-ping, then I agree. Yes. > But is that really such a big win in the long run? Yes. > If we are tracing LSP to an > LSR(which could be one of these inetwork LSRs) and if we dont recieve a > response from it, it could either be because LSP is down or the LSR does not > implement LSP-ping. In the draft, it said, "... Before initiating the liveliness test, the user must make sure that both ingress and egress LSR can support the LSR-ping." > How do you know to distinguish between these two? > And if you cant, then indirectly it implies that LSP-ping be implemented > on all such routers and I think practically thats what will end up happening. > Whichever ping mechanism is used, we will end up having to support it on all > the routers. > Now you start to scare me. :-) This is up to the network operators. - Ping From owner-mpls@UU.NET Fri Jul 20 12:49: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 MAA24904 for ; Fri, 20 Jul 2001 12:49:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkynb00184; Fri, 20 Jul 2001 16:50:20 GMT Received: by mail-control.mail.uu.net id QQkynb13380 for mpls-outgoing; Fri, 20 Jul 2001 16:49: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 QQkynb13372 for ; Fri, 20 Jul 2001 16:49: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 QQkynb08265 for ; Fri, 20 Jul 2001 16:46:53 GMT Received: from web14807.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14807.mail.yahoo.com [216.136.224.223]) id QQkynb27812 for ; Fri, 20 Jul 2001 16:46:52 GMT Message-ID: <20010720164652.89535.qmail@web14807.mail.yahoo.com> Received: from [216.174.224.251] by web14807.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 09:46:52 PDT Date: Fri, 20 Jul 2001 09:46:52 -0700 (PDT) From: Vikas D Subject: Generalized CR-LDP Question To: mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3B56F3E3.D697973F@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk All, There appears to be an error in draft-ietf-mpls-generalized-cr-ldp-03.txt Section 5.1 - Procedures (for Explicit Label Control) requires the generated Label Set TLV and/or Upstream Label TLV to be included in the outgoing MAPPING message. Should it not be the "Label Request" message that carries these TLVs? - Vikas __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 20 12:59: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 SMTP id MAA28171 for ; Fri, 20 Jul 2001 12:59:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkync07498; Fri, 20 Jul 2001 17:00:14 GMT Received: by mail-control.mail.uu.net id QQkynb14206 for mpls-outgoing; Fri, 20 Jul 2001 16:59:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkynb14198 for ; Fri, 20 Jul 2001 16:59:43 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 QQkynb21103 for ; Fri, 20 Jul 2001 16:57:25 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 QQkynb10126 for ; Fri, 20 Jul 2001 16:57:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA26212 for mpls@uu.net; Fri, 20 Jul 2001 12:57: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 QQkynb13936 for ; Fri, 20 Jul 2001 16:56:09 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 QQkynb25921 for ; Fri, 20 Jul 2001 16:55:27 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQkynb03816 for ; Fri, 20 Jul 2001 16:55:27 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 17:55:12 +0100 Message-ID: From: Pat Moore To: "'hliao@telcordia.com'" Cc: "'mpls@uu.net'" Subject: Re: RSVP-TE and cr-ldp Date: Fri, 20 Jul 2001 17:55:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk We (Data Connection) can supply portable RSVP-TE source code. Please get in touch if you are interested. Pat. ___________________________________________________ Pat Moore Network Convergence Group Data Connection Ltd. Tel: +44 20 8366 1177 Mail: pkm@dataconnection.com Fax: +44 20 8363 1468 Web: www.dataconnection.com > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: 19 July 2001 13:35 > To: abhay > Cc: mpls@UU.NET > Subject: Re: RSVP-TE and cr-ldp > > > > Abhay, > > Can you tell me if there is any vendor who can support RSVP-TE? > > Thanks in an advance. > > Julia > > > > > > abhay > > Prem" > ech.co.in> cc: "'Hong > Liao'" , mpls@UU.NET, (bcc: Hong > Liao/Telcordia) > > 07/19/01 Subject: Re: > RSVP-TE and cr-ldp > 01:13 AM > > > > > > > > > > > Julia, > > I guess yes,but maybe one should have separate label pools. > > I also remember one can do Interworking between CR-LDP > and RSVP-TE > ,each running on separate > > routers. > > Regards, > > Abhay > > > > "Sharma, Prem" wrote: > > > Hi, > > > > I feel, it's very much possible for an LSR to support both > RSVP-TE and > > CR-LDP signalling protocols but one would have to take care > of resource > > partitioning (assignment of label ranges) between the > signalling modules. > > > > Prem > > > > -----Original Message----- > > From: Hong Liao [mailto:hliao@telcordia.com] > > Sent: Wednesday, July 18, 2001 3:19 PM > > To: mpls@UU.NET > > Subject: RSVP-TE and cr-ldp > > > > Hi, > > > > Is there anyone can tell me if there is any LSR can support > RSVP-TE and > > cr-ldp? > > > > Thanks in an advance. > > > > Julia > From owner-mpls@UU.NET Fri Jul 20 13:03:53 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 NAA29330 for ; Fri, 20 Jul 2001 13:03: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 QQkync11944; Fri, 20 Jul 2001 17:04:44 GMT Received: by mail-control.mail.uu.net id QQkync25282 for mpls-outgoing; Fri, 20 Jul 2001 17:04: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 QQkync25192 for ; Fri, 20 Jul 2001 17:03:54 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 QQkync25179 for ; Fri, 20 Jul 2001 17:01:39 GMT Received: from web14911.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14911.mail.yahoo.com [216.136.225.249]) id QQkync08597 for ; Fri, 20 Jul 2001 17:01:39 GMT Message-ID: <20010720170138.26579.qmail@web14911.mail.yahoo.com> Received: from [65.194.140.2] by web14911.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 10:01:38 PDT Date: Fri, 20 Jul 2001 10:01:38 -0700 (PDT) From: Ravi Shekhar Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: Ping Pan Cc: mpls-list In-Reply-To: <3B585ED1.17BBAF98@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Ping, > > But is that really such a big win in the long run? > > Yes. Why? > > > If we are tracing LSP to an > > LSR(which could be one of these inetwork LSRs) and if we > dont recieve a > > response from it, it could either be because LSP is down > or the LSR does not > > implement LSP-ping. > > In the draft, it said, "... Before initiating the liveliness test, the > user must make sure that both ingress and egress LSR can support the > LSR-ping." I read that and it doesnt seem to be a very valid assumption. > > > How do you know to distinguish between these two? > > And if you cant, then indirectly it implies that LSP-ping > be implemented > > on all such routers and I think practically thats what > will end up happening. > > Whichever ping mechanism is used, we will end up having > to support it on all > > the routers. > > > > Now you start to scare me. :-) Mission accomplished..;).. - Ravi Shekhar. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 20 13:05: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 SMTP id NAA29705 for ; Fri, 20 Jul 2001 13:05: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 QQkync12059; Fri, 20 Jul 2001 17:06:07 GMT Received: by mail-control.mail.uu.net id QQkync28061 for mpls-outgoing; Fri, 20 Jul 2001 17:05:36 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 QQkync25327 for ; Fri, 20 Jul 2001 17:04:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkync26166 for ; Fri, 20 Jul 2001 17:02:53 GMT Received: from hypnos.cps.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hypnos.cps.intel.com [192.198.165.17]) id QQkync13916 for ; Fri, 20 Jul 2001 17:02:52 GMT Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA24575; Fri, 20 Jul 2001 17:02:39 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 20 Jul 2001 17:02:36 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1N1CAH>; Fri, 20 Jul 2001 10:02:34 -0700 Message-ID: From: "Feng, Mark" To: "'Arumugam R'" , Rajesh P Jain Cc: "'mpls@uu.net'" Subject: RE: Session Attributes Date: Fri, 20 Jul 2001 10:02:31 -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 See comments below. > -----Original Message----- > From: Arumugam R [mailto:arumugamr@future.futsoft.com] > Sent: Friday, July 20, 2001 2:22 AM > To: Rajesh P Jain > Cc: 'mpls@uu.net' > Subject: Re: Session Attributes > > > > Hi, > See inline comments. > Rajesh P Jain wrote: > > > Can someone clarify where should we store the > Session Attribute Object ? > > ### It is left to the implementation, but usually kept in the PSB. > > > > > > > Also, The draft tells that Session Attribute is an > Optional Object. So, > > Let us consider a case where a Path Message is sent without > a Session Attribute > > Object (As a result, the PSB is set up at all the nodes etc). > > ### Eventhough it is optional, it is upto the implementation looking > for it as a mandatory object. Coming back to you question if you > receive a Path message without a Session Attribute object, > you have to > allocate a FF style for the flow.. > I don't agree with that. The draft does not say what style of reservation should be used. It is really up to the implementation. Conversely, even if the sender asks for SE style in the SESSION_ATTRIBUTE object, the receiver does not have to honor the request. According to the standard, that does not appear to be a protocol error. In other words, the reservation style is decided by the receiver. > > > > > > Now, If we send a Path Message (Of Course for > Rerouting a Tunnel) with > > Session Attribute. So, How will the New Path Message > compare Session Attribute > > Object Details (For the "Make Before Break" or Rerouting) > the PSB of the Old > > Path Message. > > ### So you can't reroute the traffic for an FF style flow > If the receiver sends a Resv with SE style, it is still possible to do "make-before-break". The new Path message would appear to be from a different sender, since the LSP Id is changed. "Comparing", if done, is implementation dependent. > > > > > > Does it mean that if we send a Path Message > without a Session > > Attribute Object, some DEFAULT value of (Setup/ Holding > Priority etc is stored). > > If yes, then what is the default value??? > > ### I think it should be your implementation's assumption. > The default > value can be 4. > > Reg > Arumugam > > > > > TIA > > Rajesh P Jain > > > > > > > > "Feng, Mark" wrote: > > > >> Also the "local protecion" flag is useful in term of > re-routing LSPs in case > >> of downstream node failure. The resource affinity related > vectors are useful > >> regarding constraint-based routing... > >> > >> - Mark > >> > >>> -----Original Message----- > >>> From: Khuzema Pithewan [mailto:khuzema@netbrahma.com] > >>> Sent: Thursday, July 19, 2001 1:49 AM > >>> Cc: 'mpls@uu.net' > >>> Subject: Re: Session Attributes > >>> > >>> > >>> SE Desired flag can be set in Session Attribute if Ingress is > >>> willing to > >>> use make-before-break of LSPs... > >>> > >>> Khuzema. > >>> > >>> > >>> Rajesh P Jain wrote: > >>> > >>>> "Hi", > >>>> I would also like to know if this Session > >>> > >>> Attribute OBJECT > >>> > >>>> anyway helpful in Rerouting Traffic Engineered Tunnels?? Is > >>> > >>> the information > >>> > >>>> present in this object anyway useful in > "make-before-break" concept? > >>>> > >>>> TIA > >>>> Rajesh P Jain > >>>> > >>>> "Feng, Mark" wrote: > >>>> > >>>>> Ping, > >>>>> > >>>>> I know the name implies the attributes belong to the > >>>> > >>> session. But does it > >>> > >>>>> mean all senders, i.e. ingress routers, need to have the > >>>> > >>> same session > >>> > >>>>> attributes? Should the transit nodes reject the new Path > >>>> > >>> message, if the > >>> > >>>>> session attributes are different from other senders of > >>>> > >>> the same session, > >>> > >>>>> because there is no rule on "merging" the session attributes? > >>>>> > >>>>> Thanks. > >>>>> > >>>>> - Mark > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ping Pan [mailto:pingpan@juniper.net] > >>>>>> Sent: Tuesday, July 17, 2001 9:37 PM > >>>>>> To: Khuzema Pithewan > >>>>>> Cc: rsvp@ISI.EDU > >>>>>> Subject: Re: Session Attributes > >>>>>> > >>>>>> > >>>>>> Khuzema, > >>>>>> > >>>>>> First, this question should go to the mpls list. Please > >>>>> > >>> forward the > >>> > >>>>>> discussion to that list. Second, the question itself is > >>>>> > >>> implementation > >>> > >>>>>> dependent. Finally, since the Session Attribute object > >>>>> > >>> is to describe > >>> > >>>>>> the properties of a RSVP session, in a normal implementation, > >>>>>> it should > >>>>>> be kept where you keep the session. > >>>>>> > >>>>>> - Ping > >>>>>> > >>>>>> Khuzema Pithewan wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Session Attribute Object in RSVP-TE contains some > >>>>>> > >>> flags , setup and > >>> > >>>>>>> holding priority and some session related info. > >>>>>>> > >>>>>>> My doubt is , if this object is per session or per LSP, > >>>>>> > >>>>>> because name > >>>>>> > >>>>>>> suggest > >>>>>>> that it is per session, but holding/setup priorities are > >>>>>> > >>>>>> the attributes > >>>>>> > >>>>>>> of a LSP. > >>>>>>> so basically where to keep this Object,?? in PSB or > >>>>>> > >>> Session??? > >>> > >>>>>>> Khuzema. > >>>>>> > > From owner-mpls@UU.NET Fri Jul 20 13:53:05 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 NAA11380 for ; Fri, 20 Jul 2001 13:53: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 QQkynf02641; Fri, 20 Jul 2001 17:53:55 GMT Received: by mail-control.mail.uu.net id QQkynf09134 for mpls-outgoing; Fri, 20 Jul 2001 17:53:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkynf09123 for ; Fri, 20 Jul 2001 17:53:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkynf18804 for ; Fri, 20 Jul 2001 17:51:42 GMT Received: from web11403.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11403.mail.yahoo.com [216.136.131.233]) id QQkynf00270 for ; Fri, 20 Jul 2001 17:51:41 GMT Message-ID: <20010720175141.73749.qmail@web11403.mail.yahoo.com> Received: from [65.194.140.2] by web11403.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 10:51:41 PDT Date: Fri, 20 Jul 2001 10:51:41 -0700 (PDT) From: Sanjay Wadhwa Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: Ravi Shekhar , erosen@cisco.com Cc: Ping Pan , "Punj, Arun" , mpls-list In-Reply-To: <20010720003411.12640.qmail@web14903.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk It is hard to disagress that a signalling independent solution in the long run is a good thing. draft-pan-lsp-ping-00.txt is a simple, backward compatible solution that will work currently for an RSVP-TE core. I think as a solution for RSVP-TE it has merits by virtue of it's simplicity and ease of deployment. Thinking about the following "generic" solution (which looks to be built upon various suggestions by various folks on the list) in context of an LSP setup using LDP : This four step process has a substantial window between the time the forward path is discovered by the ingress and egress and it is actually used for the echo-response in the reverse direction. During this time routing could have changed and the forward LSP could be taking a different path. So, the step 4 is not as simple as sending the response hop-by-hop exactly according to the path information contained in the echo-response. A next-hop indicated there could now no longer directly attached to the intermediate node due to a routing change. What do you do in this case ? Do a routing lookup towards that hop. But then you are back to relying on unicast routing in the reverse direction as opposed to exactly using the forward path used by the forward LSP, and I think this is something we want to avoid in the first place. Also, with un-converged routing step 4 could result in a loop which would cause the echo-response to be dropped. And the ingress could mistakenly then take down a valid LSP. With rsvp loose hops or non-rsvp cloud or nested tunnels a similar situation can arise. But there tying it's fate to the RESV is the key. Cheers.. -Sanjay --- Ravi Shekhar wrote: > > So then I think then the base requirement for the routing of the > response > > from the egress is that it be reverse-path-forwarded back to the > ingress, > > i.e., that it follow the path of label distribution from egress to > ingress. > > > That seems to be the right way to me. One possible way to achieve > this is > as a 4 step process - first 2 to gather the hop-by-hop path from > ingress to > egress node and the next 2 to do the ping on LSP: > > 1) Initiate a UDP packet at ingress and send it to the next hop > for the LSP to > be traced (i.e. destination IP address is the address of the > next hop for > LSP and not the egress address itself). > Have enough information (like ingress router/egress router > address/label) > in the UDP packet to uniquely identify the LSP. > Every hop(including ingress/egress) on the way appends its hop > information > and sends this packet to the next hop of the LSP. > 2) When this UDP packet reaches egress, egress sends it back to > the ingress > hop-by-hop in the reverse order of the way path was traced(and > recorded in > the packet) in step 1. Sending it this way ensures that it > reaches the > ingress. > 3) At this point ingress has the elaborated hop-by-hop path for > the LSP from > ingress to egress. It now generates a UDP packet at ingress > with the > destination address of the egress. Since the UDP packet's > destination is > egress node, it should traverse the LSP now. Inside the UDP > packet fill in > the path that was traced in step 1 (and received by ingress in > step 2). > 4) If egress receives the UDP packet sent in step 3 via LSP, it > can use the > hop-by-hop information contained in the packet and send a > response back > hop-by-hop to the ingress (the same way it sent it back in step > 2). > > This should work independent of the protocol that sets up the LSP > (and across > multiple protocols). Since a unique return path for response is > already > recorded while traversing in the forward direction of LSP (i.e. > from ingress > to egress) in step 1, it would work for LDP too where same label > might have > been handed over to multiple upstreams. > > Some other useful information can also be gathered. Like protocol > that set up > the LSP on each hop interface / timestamp and > number-of-packets-forwarded-on > -the-LSP in steps 2 and 4 to calculate the rate of forwarding on > LSP etc. > > Maximum number of hops to be traced can be specified by the > ingress (and > decremented at each hop) to prevent looping of message in step 1 > forever. > Indication of failure of LSP or reaching maximum number of hops at > any hop > can be put in the UDP packet and sent back to ingress in step 2. > > - Ravi Shekhar. > > __________________________________________________ > 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 Jul 20 14:12: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 OAA15403 for ; Fri, 20 Jul 2001 14:12:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkyng00266; Fri, 20 Jul 2001 18:12:59 GMT Received: by mail-control.mail.uu.net id QQkyng00367 for mpls-outgoing; Fri, 20 Jul 2001 18:12:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkyng00360 for ; Fri, 20 Jul 2001 18:12: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 QQkyng19304 for ; Fri, 20 Jul 2001 18:12:09 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 QQkyng29654 for ; Fri, 20 Jul 2001 18:12:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25209 for ; Fri, 20 Jul 2001 14:12:08 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA13340 for mpls@uu.net; Fri, 20 Jul 2001 14:12:00 -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 QQkyng12219 for ; Fri, 20 Jul 2001 18:01: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 QQkynf17735 for ; Fri, 20 Jul 2001 17:59:27 GMT Received: from c0mailgw11.prontomail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgw.prontomail.com [216.163.180.10]) id QQkynf22854 for ; Fri, 20 Jul 2001 17:59:27 GMT Received: by c0mailgw11.prontomail.com (NPlex 5.5.029) id 3B5716E50003231E; Fri, 20 Jul 2001 12:56:53 -0700 Received: from 148.75.48.66 by SmtpServer for ; Fri, 20 Jul 2001 17:54:15 +0000 Reply-To: From: "Dennis Hartmann" To: "Vikas D" , , Subject: RE: RFC : 3036 : Session establishment for multiple adjacencies. Date: Fri, 20 Jul 2001 14:01:55 -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.2910.0) Importance: Normal In-Reply-To: <20010718184753.26594.qmail@web14808.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I could be wrong, but it would seem to me that they are saying different things. The latter is saying that we must have an active session (TCP connection) over which we can advertise label spaces. The latter is saying that a LSR which is advertising a label space must have the same transport protocol. To relate this to a Cisco environment... We can't advertise the same label space via two seperate processes (LDP and TDP). This is most probably why Cisco uses transport port 711 for TDP and transport port 646 for LDP. Going by RFC 3036, these two processes can NOT be using the same address space (to my knowledge, the Tag field in TDP is identical to the MPLS header). If true, this would be a limitation while migrating a large deployment of TDP to LDP. Each router would need to have statically assigned label spaces. I'm sure Rob or Eric will clear this up for us. Sincerely, Dennis J. Hartmann White Pine Consulting Global Knowledge-MPLS Course Director http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 dennisjhartmann@hotmail.com AOL IM: dennisjhartmann -----Original Message----- From: Vikas D [mailto:vikdw@yahoo.com] Sent: Wednesday, July 18, 2001 2:48 PM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. All, A small doubt in Section 2.5.2, "Transport Connection Establishment" of LDP RFC. It says: .............snip.................. "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency." .............snip.................... Now, under what circumstances would two LSRs, having multiple hello adjacencies , using same label spaces on all adjacencies try to establish multiple TCP sessions? Is this not already precluded by the following rule in the same section (Sec 2.5.2 of RFC 3036): .............snip.................. " 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b it attempts to open a TCP connection for a new LDP session with LSR2." .............snip.................. Thanks - Vikas __________________________________________________ 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 From owner-mpls@UU.NET Fri Jul 20 14:13: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 SMTP id OAA15986 for ; Fri, 20 Jul 2001 14:13: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 QQkyng23498; Fri, 20 Jul 2001 18:14:25 GMT Received: by mail-control.mail.uu.net id QQkyng00643 for mpls-outgoing; Fri, 20 Jul 2001 18:13: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 QQkyng00604 for ; Fri, 20 Jul 2001 18:13: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 QQkyng06530 for ; Fri, 20 Jul 2001 18:12:21 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 QQkyng29747 for ; Fri, 20 Jul 2001 18:12:19 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25234 for ; Fri, 20 Jul 2001 14:12:18 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA13344 for mpls@uu.net; Fri, 20 Jul 2001 14:12:10 -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 QQkyng00066 for ; Fri, 20 Jul 2001 18:10:45 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 QQkyng04970 for ; Fri, 20 Jul 2001 18:10:42 GMT Received: from c0mailgw04.prontomail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgw.prontomail.com [216.163.180.10]) id QQkyng19879 for ; Fri, 20 Jul 2001 18:10:42 GMT Received: by c0mailgw04.prontomail.com (NPlex 5.5.029) id 3B56EEA600031AED; Fri, 20 Jul 2001 11:05:14 -0700 Received: from 148.75.48.66 by SmtpServer for ; Fri, 20 Jul 2001 18:05:02 +0000 Reply-To: From: "Dennis Hartmann" To: , Cc: , , , , , Subject: RE: fault tolerant TCP implementation Date: Fri, 20 Jul 2001 14:12:32 -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.2910.0) Importance: Normal In-Reply-To: <200107181452.f6IEqhC21212@tcb.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit How do they achieve this w/o going through the TCP connection process again (SYN-SYN-ACK)? Are they maintaining dual connections (somewhat similar to Cisco Call manager or MGCP)? I would think that there has to be some type of state in memory on the 2nd device to achieve this with a stateful protocol. Even on a device like Cisco Local Director, the local director has to set the sticky bit for stateful applications or reserve memory within itself. What product are you talking of? I would like to research this. Sincerely, Dennis J. Hartmann White Pine Consulting Global Knowledge-MPLS Course Director http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 dennisjhartmann@hotmail.com AOL IM: dennisjhartmann -----Original Message----- From: danny@nut.tcb.net [mailto:danny@nut.tcb.net]On Behalf Of Danny McPherson Sent: Wednesday, July 18, 2001 10:53 AM To: Aditya@in.huawei.com Cc: afarrel@movaz.com; pjb@dataconnection.com; eric.gray@sandburst.com; philipma@nortelnetworks.com; mpls@UU.NET; mpls-ops@mplsrc.com Subject: Re: fault tolerant TCP implementation > Dear MPLS Gurus, > In the draft on ldp-FT (draft-ietf-mpls-ldp-ft-02.txt ) the authors > write on Page 4, in section 2.2 that it "Notoriously Hard > > to provide a fault tolerant implementation of TCP"...My question is WHY > ? .Why is it so difficult to recreate a TCP connection ( across a > switchover > > from Active Board to Standby Board ) if the connection is in ESTABLISHED > state ? > Later they go on to say that "This is an issue familiar to implementers > of other TCP applications such as BGP". > If anyone could point me to any such related work,I would highly > appreciate their help. I know of at least one vendor (deployed in production networks) that provides this (i.e., stateful TCP failover for BGP, LDP, etc..). It's not impossible, it's just not "easy", especially when the system isn't designed from the start to support it. -danny ------- 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 Jul 20 14:21:54 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 OAA19647 for ; Fri, 20 Jul 2001 14: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 QQkynh07634; Fri, 20 Jul 2001 18:22:46 GMT Received: by mail-control.mail.uu.net id QQkynh01609 for mpls-outgoing; Fri, 20 Jul 2001 18:22:15 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 QQkynh01569 for ; Fri, 20 Jul 2001 18:21:59 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 QQkynh01354 for ; Fri, 20 Jul 2001 18:20:24 GMT Received: from tcb.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQkynh00060 for ; Fri, 20 Jul 2001 18:20:23 GMT Received: from nut.tcb.net (danny@localhost) by tcb.net (8.11.4/8.11.4) with ESMTP id f6KILq820625; Fri, 20 Jul 2001 12:21:52 -0600 Message-Id: <200107201821.f6KILq820625@tcb.net> X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 To: dennisjhartmann@hotmail.com cc: Aditya@in.huawei.com, afarrel@movaz.com, pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET, mpls-ops@mplsrc.com From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: fault tolerant TCP implementation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jul 2001 12:21:52 -0600 Sender: owner-mpls@UU.NET Precedence: bulk > How do they achieve this w/o going through the TCP connection process again > (SYN-SYN-ACK)? Are they maintaining dual connections (somewhat similar to > Cisco Call manager or MGCP)? Nope. > I would think that there has to be some type > of state in memory on the 2nd device to achieve this with a stateful > protocol. Yep (i.e., device == standby control card). > Even on a device like Cisco Local Director, the local director > has to set the sticky bit for stateful applications or reserve memory within > itself. What product are you talking of? I would like to research this. I'll respond to this offline... -danny From owner-mpls@UU.NET Fri Jul 20 14:35: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 OAA24212 for ; Fri, 20 Jul 2001 14: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 QQkyni17424; Fri, 20 Jul 2001 18:36:31 GMT Received: by mail-control.mail.uu.net id QQkyni02619 for mpls-outgoing; Fri, 20 Jul 2001 18:36: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 QQkyni02583 for ; Fri, 20 Jul 2001 18:35: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 QQkyni10933 for ; Fri, 20 Jul 2001 18:34:59 GMT Received: from web14902.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14902.mail.yahoo.com [216.136.225.54]) id QQkyni16389 for ; Fri, 20 Jul 2001 18:34:58 GMT Message-ID: <20010720183458.65289.qmail@web14902.mail.yahoo.com> Received: from [65.194.140.2] by web14902.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 11:34:58 PDT Date: Fri, 20 Jul 2001 11:34:58 -0700 (PDT) From: Ravi Shekhar Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: mpls-list In-Reply-To: <20010720175141.73749.qmail@web11403.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk > This four step process has a substantial window between the time the > forward path is discovered by the ingress and egress and it is actually > > used for the echo-response in the reverse direction. During this time > routing could have changed and the forward LSP could be taking a > different path. So, the step 4 is not as simple as sending the response > hop-by-hop exactly according to the path information contained in the > echo-response. A next-hop indicated there could now no longer directly > attached to the intermediate node due to a routing change. What do you > do in this case ? Do a routing lookup towards that hop. But then you > are back to relying on unicast routing in the reverse direction as > opposed to exactly using the forward path used by the forward LSP, and > I think this is something we want to avoid in the first place. > Also, with un-converged routing step 4 could result in a loop which > would cause the echo-response to be dropped. And the ingress could > mistakenly then take down a valid LSP. If the succesive hops are not reachable to each other, the signalling protocol running between them to set up that LSP will bring down the LSP soon to. In any case, idea is to use it more as a debugging tool than a liveness testing tool to bring down an LSP. Even if one desires to bring down the LSP based on this, probably its a good idea to do multiple such pings to take care of transient conditions before declaring that LSP is down. For instance, if the hop-by-hop path in first 2 steps turn out to be different for two such successive pings, its a clear indication that transient conditions exist. Note that even traceroute could give wrong result if transient routing conditions exist. Regards. - Ravi Shekhar. > > With rsvp loose hops or non-rsvp cloud or nested tunnels a similar > situation can arise. But there tying it's fate to the RESV is the key. > > Cheers.. > -Sanjay __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 20 14:50:47 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 OAA28848 for ; Fri, 20 Jul 2001 14:50: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 QQkynj28039; Fri, 20 Jul 2001 18:51:37 GMT Received: by mail-control.mail.uu.net id QQkynj04061 for mpls-outgoing; Fri, 20 Jul 2001 18:51: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 QQkynj04032 for ; Fri, 20 Jul 2001 18:50: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 QQkynj27622 for ; Fri, 20 Jul 2001 18:48:16 GMT Received: from web11401.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11401.mail.yahoo.com [216.136.131.231]) id QQkynj25607 for ; Fri, 20 Jul 2001 18:48:15 GMT Message-ID: <20010720184815.78046.qmail@web11401.mail.yahoo.com> Received: from [65.194.140.2] by web11401.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 11:48:15 PDT Date: Fri, 20 Jul 2001 11:48:15 -0700 (PDT) From: Sanjay Wadhwa Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] To: Ravi Shekhar , mpls-list In-Reply-To: <20010720183458.65289.qmail@web14902.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk > If the succesive hops are not reachable to each other, the > signalling > protocol running between them to set up that LSP will bring down > the LSP > soon to. Those successive hops are not in the current (latest) forward path being used by the LSP in question. That was the crux of the point above. > In any case, idea is to use it more as a debugging tool than a > liveness testing > tool to bring down an LSP. Ok. That is worth clarifying then. -Sanjay > > Regards. > > - Ravi Shekhar. > > > > > With rsvp loose hops or non-rsvp cloud or nested tunnels a similar > > situation can arise. But there tying it's fate to the RESV is the > key. > > > > Cheers.. > > -Sanjay > > > __________________________________________________ > 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 Jul 20 15:06: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 PAA03335 for ; Fri, 20 Jul 2001 15:06: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 QQkynk12052; Fri, 20 Jul 2001 19:07:09 GMT Received: by mail-control.mail.uu.net id QQkynk15953 for mpls-outgoing; Fri, 20 Jul 2001 19:06: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 QQkynk15638 for ; Fri, 20 Jul 2001 19:06:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkynk27873 for ; Fri, 20 Jul 2001 19:05:18 GMT Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.telefonica.com.ar [168.226.49.11]) id QQkynk07842 for ; Fri, 20 Jul 2001 19:05:16 GMT Received: by MAIL1 with Internet Mail Service (5.5.2448.0) id <3G5JHM5Y>; Fri, 20 Jul 2001 15:50:31 -0300 Message-ID: <49BB9783DE7FD411A29D00508B6F0AD804D442CF@MSTELEFONICA1> From: Zappacosta Rolando Jorge To: "'mpLS@UU.NET'" Subject: FastReRoute & OSPF LER Date: Fri, 20 Jul 2001 15:50:23 -0300 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 Hello everybody. I'm searching for complete and updated info regarding FastRerouing; does anyone know some good links? Another question, suppose you have an MPLS routers based backbone and you use as a LER a router that does *not* run BGP and receives from the outside interfaces pure IP to be inserted into the core. Why must it not, if it mustn't, label the packets prior to their insertion in the core? In other words, may be it possible that the LER labels packets to go through an LSP created taking into account OSPF information? Or must it label packets if the LSP's were created thanks to BGP only? Thanks in advance, Rolando J. Zappacosta Gerencia Laboratorios - DER Reconquista 179 Ciudadela (B1702FCC) Pcia. de Buenos Aires - ARGENTINA Tel: +54-11-4332-8360 Fax: +54-11-4303-5586 Ext: 6005 From owner-mpls@UU.NET Fri Jul 20 15:07: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 PAA03537 for ; Fri, 20 Jul 2001 15:07: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 QQkynk13257; Fri, 20 Jul 2001 19:08:10 GMT Received: by mail-control.mail.uu.net id QQkynk16020 for mpls-outgoing; Fri, 20 Jul 2001 19:06: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 QQkynk15823 for ; Fri, 20 Jul 2001 19:06: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 QQkynk28086 for ; Fri, 20 Jul 2001 19:05: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 QQkynk11008 for ; Fri, 20 Jul 2001 19:05:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA08260 for mpls@uu.net; Fri, 20 Jul 2001 15:05:40 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkynk13914 for ; Fri, 20 Jul 2001 19:05:06 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 QQkynk14424 for ; Fri, 20 Jul 2001 19:04:33 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 QQkynk07304 for ; Fri, 20 Jul 2001 19:04:32 GMT Received: (qmail 25524 invoked by uid 104); 20 Jul 2001 19:04:31 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.808752 secs); 20/07/2001 12:04:31 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 20 Jul 2001 19:04:30 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6KJ4ZP22767; Fri, 20 Jul 2001 12:04:35 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 12:10:17 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D9B@BBY1EXM01> From: Shahram Davari To: "'Suresh Katukam'" Cc: Eric Gray , "'Ping Pan'" , "'mpLS@UU.net'" Subject: RE: LSP-ping Date: Fri, 20 Jul 2001 12:10:08 -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 Sursh, I think the answer is that other mechanism such as customer complain detect that a fault exist in the first place. -Shahram > -----Original Message----- > From: Suresh Katukam [mailto:skatukam@cisco.com] > Sent: Thursday, July 19, 2001 7:32 PM > To: Shahram Davari > Cc: Eric Gray; 'Ping Pan'; 'mpLS@UU.net' > Subject: Re: LSP-ping > > > > Ping, Shahram, > > Is the following question in Shahram's mail answered? > > Thanks, > Suresh > > Shahram Davari wrote: > > > > Hi Ping, > > > > Could you please clarify, which mechanism finds that there > is a problem in the first place. Is it customer complain, or > do you run ICMP-ping continuously over the life of the LSP? > > > > -Shahram > > > > > -----Original Message----- > > > From: Peter Willis [mailto:pjw@ip-engineering.bt.com] > > > Sent: Wednesday, July 18, 2001 5:30 AM > > > To: Eric Gray > > > Cc: erosen@cisco.com; Shahram Davari; 'mpLS@UU.net' > > > Subject: Re: LSP-ping > > > > > > > > > Colleagues, > > > > > > Perhaps the draft-pan-lsp-ping-00.txt can be modified to make > > > it more clear > > > that this is a DIAGNOSTIC tool used AFTER the LSP has failed > > > to deliver user > > > traffic. The draft says this clearly in Section 4 > > > "Motivation" but does not > > > make this clear in the Abstract and Section 3 where it says > > > "This document describes a simple and efficient mechanism > that can be > > > used to detect data plane failures in MPLS LSP's" > > > > > > I think instead of saying "used to detect data plane > > > failures" it should say > > > "used to diagnose data plane failures". > > > > > > If this wording was changed I would be a lot happier with > this draft. > > > > > > Then I can go on to point out that the actual DETECTION > > > mechanism used by this > > > draft is the customer, that is the customer notices > > > connectivity has failed > > > and this triggers diagnostics. So we still need a mechanism > > > to detect LSP > > > failure. > > > > > > > > > -------------------------------------------------------------- > > > ------------------ > > > Peter Willis > > > peter.j.willis@bt.com > > > IP Technology Strategist Phone: > > > +44 (0)1473 645178 > > > Chief Technology Office Fax: > > > +44 (0)1473 644506 > > > BTexact Technologies. > > > PP3, RSB10, Adastral Park, Martlesham, Ipswich IP5 3RE, UK. > > > -------------------------------------------------------------- > > > ------------------ > > > > > > > From owner-mpls@UU.NET Fri Jul 20 15:30: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 PAA12546 for ; Fri, 20 Jul 2001 15:30: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 QQkynm26031; Fri, 20 Jul 2001 19:31:12 GMT Received: by mail-control.mail.uu.net id QQkynm27786 for mpls-outgoing; Fri, 20 Jul 2001 19:30: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 QQkynm27772 for ; Fri, 20 Jul 2001 19:30:27 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 QQkynl12010 for ; Fri, 20 Jul 2001 19:29:54 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 QQkynl10723 for ; Fri, 20 Jul 2001 19:29:54 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 PAA08626 for ; Fri, 20 Jul 2001 15:29:50 -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 PAA28571 for ; Fri, 20 Jul 2001 15:14:04 -0400 (EDT) Message-ID: <3B58830C.7FBACAC8@marconi.com> Date: Fri, 20 Jul 2001 15:14:20 -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: Session Attributes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> Eventhough it is optional, it is upto the implementation looking >> for it as a mandatory object. Coming back to you question if you >> receive a Path message without a Session Attribute object, >> you have to allocate a FF style for the flow.. > > I don't agree with that. The draft does not say what style of > reservation should be used. It is really up to the implementation. > Conversely, even if the sender asks for SE style in the > SESSION_ATTRIBUTE object, the receiver does not have to honor the > request. According to the standard, that does not appear to be a > protocol error. In other words, the reservation style is decided by > the receiver. It's more than just that. Everything in SESSION_ATTRIBUTES is advisory. This can be inferred from the fact that its class number is greater than 192. Routers that don't support SESSION_ATTRIBUTES are supposed to opaquely forward the object and set up the Path without using it. If the parameters in SESSION_ATTRIBUTES were hard requirements, then this behavior would make no sense. Of course, a conformant implementation _should_ follow the parameters, unless there's a really good reason why not to. But they are still advisory nonetheless. >> ### So you can't reroute the traffic for an FF style flow > > If the receiver sends a Resv with SE style, it is still possible > to do "make-before-break". The new Path message would appear to be > from a different sender, since the LSP Id is changed. "Comparing", > if done, is implementation dependent. It is possible to do make-before-break even with FF style. The only catch is that resources will be temporarily wasted on those nodes/links that the new and old LSPs have in common. The reroute may fail if there aren't enough resources to hold this temporary reservation. But if there are sufficient resources, make-before-break will still work. -- David From owner-mpls@UU.NET Fri Jul 20 15:51: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 PAA20797 for ; Fri, 20 Jul 2001 15:51:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkynn16765; Fri, 20 Jul 2001 19:52:16 GMT Received: by mail-control.mail.uu.net id QQkynn00218 for mpls-outgoing; Fri, 20 Jul 2001 19:51:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkynn00138 for ; Fri, 20 Jul 2001 19:51:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkynn09315 for ; Fri, 20 Jul 2001 19:49:46 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkynn09615 for ; Fri, 20 Jul 2001 19:49:46 GMT Message-ID: <3B588B58.5C65E980@sandburst.com> Date: Fri, 20 Jul 2001 15:49:44 -0400 From: Eric Gray MIME-Version: 1.0 To: Dennis Hartmann Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dennis Hartmann wrote: > I could be wrong, I suppose. > but it would seem to me that they are saying different > things. The latter is saying that we must have an active session (TCP > connection) over which we can advertise label spaces. The latter is saying > that a LSR which is advertising a label space must have the same transport > protocol. Which 'latter' is which? Both are wrong. Label spaces are 'advertised' using Hello exchanges over UDP. Neither says anything about the transport protocol (references are to the transport address). > To relate this to a Cisco environment... We can't advertise the > same label space via two seperate processes (LDP and TDP). This is most > probably why Cisco uses transport port 711 for TDP and transport port 646 > for LDP. These are 'listening' ports used by the two signaling protocols and have nothing really to do with label spaces, per-se. It is just not reasonable to attempt to establish an LDP peer relationship using a TDP port. > Going by RFC 3036, these two processes can NOT be using the same > address space (to my knowledge, the Tag field in TDP is identical to the > MPLS header). If true, this would be a limitation while migrating a large > deployment of TDP to LDP. Each router would need to have statically > assigned label spaces. I'm sure Rob or Eric will clear this up for us. What do _you_mean by label spaces? > > > Sincerely, > > Dennis J. Hartmann > White Pine Consulting > Global Knowledge-MPLS Course Director > http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 > dennisjhartmann@hotmail.com > AOL IM: dennisjhartmann > > -----Original Message----- > From: Vikas D [mailto:vikdw@yahoo.com] > Sent: Wednesday, July 18, 2001 2:48 PM > To: mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: RFC : 3036 : Session establishment for multiple > adjacencies. > > All, > > A small doubt in Section 2.5.2, "Transport Connection > Establishment" > of LDP RFC. It says: > > .............snip.................. > "An LSR MUST advertise the same transport address in all Hellos that > advertise the same label space. This requirement ensures that two > LSRs linked by multiple Hello adjacencies using the same label > spaces > play the same connection establishment role for each adjacency." > .............snip.................... > > Now, under what circumstances would two LSRs, having multiple > hello adjacencies , using same label spaces on all adjacencies > try to establish multiple TCP sessions? > > Is this not already precluded by the following rule in the same > section (Sec 2.5.2 of RFC 3036): > > .............snip.................. > " 1. If LSR1 does not already have an LDP session for the exchange > of label spaces LSR1:a and LSR2:b it attempts to open a TCP > connection for a new LDP session with LSR2." > .............snip.................. > > Thanks > - Vikas > > __________________________________________________ > 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 From owner-mpls@UU.NET Fri Jul 20 16:00: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 QAA24993 for ; Fri, 20 Jul 2001 16:00: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 QQkyno12472; Fri, 20 Jul 2001 20:01:04 GMT Received: by mail-control.mail.uu.net id QQkyno03346 for mpls-outgoing; Fri, 20 Jul 2001 20:00:29 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 QQkyno02171 for ; Fri, 20 Jul 2001 20:00: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 QQkynn15747 for ; Fri, 20 Jul 2001 19:59:35 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkynn10724 for ; Fri, 20 Jul 2001 19:59:35 GMT Message-ID: <3B588DA6.737821BF@sandburst.com> Date: Fri, 20 Jul 2001 15:59:34 -0400 From: Eric Gray MIME-Version: 1.0 To: dennisjhartmann@hotmail.com Cc: danny@ambernetworks.com, Aditya@in.huawei.com, afarrel@movaz.com, pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: fault tolerant TCP implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dennis, If an implementation has to use the TCP connection process to re-establish a TCP connection, then it is not particularly fault tolerant. The damage is done already if the TCP connection is detected to be down by both ends. Many examples of approaches that could be used would include some mix of relatively high band-width connectivity between controllers and sharing of state information (either as a result of sharing the state explicitly, or by 'reliable' state information exchanges) between redundant TCP entities. AFAIK, any other approach would have to be visible at the other end of the connection. -- Eric Gray You wrote: > How do they achieve this w/o going through the TCP connection process again > (SYN-SYN-ACK)? Are they maintaining dual connections (somewhat similar to > Cisco Call manager or MGCP)? I would think that there has to be some type > of state in memory on the 2nd device to achieve this with a stateful > protocol. Even on a device like Cisco Local Director, the local director > has to set the sticky bit for stateful applications or reserve memory within > itself. What product are you talking of? I would like to research this. > > Sincerely, > > Dennis J. Hartmann > White Pine Consulting > Global Knowledge-MPLS Course Director > http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 > dennisjhartmann@hotmail.com > AOL IM: dennisjhartmann > > --- From owner-mpls@UU.NET Fri Jul 20 16:27: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 QAA07256 for ; Fri, 20 Jul 2001 16:27: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 QQkynp06619; Fri, 20 Jul 2001 20:28:15 GMT Received: by mail-control.mail.uu.net id QQkynp23508 for mpls-outgoing; Fri, 20 Jul 2001 20:27: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 QQkynp23500 for ; Fri, 20 Jul 2001 20:27: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 QQkynp14186 for ; Fri, 20 Jul 2001 20:27:27 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 QQkynp11142 for ; Fri, 20 Jul 2001 20:27:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA15562 for mpls@uu.net; Fri, 20 Jul 2001 16:27:26 -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 QQkynp23470 for ; Fri, 20 Jul 2001 20:27:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkynp09630 for ; Fri, 20 Jul 2001 20:25:02 GMT Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkynp08671 for ; Fri, 20 Jul 2001 20:25:01 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6KKNGi19514; Fri, 20 Jul 2001 13:23:16 -0700 (PDT) Received: from cisco.com (ams-vpdn-client-12.cisco.com [144.254.46.13]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ACE16659 (AUTH rraszuk); Fri, 20 Jul 2001 13:24:53 -0700 (PDT) Message-ID: <3B589317.BA0B038F@cisco.com> Date: Fri, 20 Jul 2001 13:22:47 -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: Zappacosta Rolando Jorge CC: "'mpLS@UU.NET'" Subject: Re: FastReRoute & OSPF LER References: <49BB9783DE7FD411A29D00508B6F0AD804D442CF@MSTELEFONICA1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Zappacosta, > Another question, suppose you have an MPLS routers based backbone and you > use as a LER a router that does *not* run BGP and receives from the outside > interfaces pure IP to be inserted into the core. Why must it not, if it > mustn't, label the packets prior to their insertion in the core? In other > words, may be it possible that the LER labels packets to go through an LSP > created taking into account OSPF information? Or must it label packets if > the LSP's were created thanks to BGP only? Of course you don't need BGP to use LSPs for forwarding traffic. I think your question maybe triggered by one implementation which in the past by default was inserting into the TE-LSPs destinations comming via bgp but now even they have a knob to relax it (it's called "igp shortcuts" if I remember correctly :). R. From owner-mpls@UU.NET Fri Jul 20 17:14: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 RAA20486 for ; Fri, 20 Jul 2001 17:14: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 QQkynt28050; Fri, 20 Jul 2001 21:15:02 GMT Received: by mail-control.mail.uu.net id QQkyns17377 for mpls-outgoing; Fri, 20 Jul 2001 21:14: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 QQkyns17364 for ; Fri, 20 Jul 2001 21:14:19 GMT Received: from pmismtp04.wcomnet.com by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp04.wcomnet.com [166.38.62.39]) id QQkyns19667 for ; Fri, 20 Jul 2001 21:12:53 GMT Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0GGS00201IXGM7@pmismtp04.wcomnet.com> for mpLS@UU.NET; Fri, 20 Jul 2001 21:12:52 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GGS00201IX2FN@pmismtp04.wcomnet.com> for mpLS@UU.NET; Fri, 20 Jul 2001 21:12:52 +0000 (GMT) Received: from lyao ([166.60.2.200]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GGS000B2IWXR8@pmismtp04.wcomnet.com>; Fri, 20 Jul 2001 21:12:33 +0000 (GMT) Date: Fri, 20 Jul 2001 16:55:02 -0400 From: Lei Yao Subject: RE: LSP-ping In-reply-to: <200107171915.PAA03238@erosen-u10.cisco.com> To: erosen@cisco.com, Shahram Davari Cc: "'mpLS@UU.net'" Reply-to: lei.yao@wcom.com 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.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We really need to let the authors clarify the motivations for LSP ping. It seems to me that the following description from Eric is really the biggest motivation to use LSP ping. > A mechanism which uses ONLY the LSP that is being tested seems worthwhile as > a fault isolation tool, and that's really what LSP-ping offers you. We would like to detect the failure of a specific LSP. However, one LSP fails on a router does not necessarily mean that the whole data plane on the router fails. Even when the whole dataplane on a router fails, most likely control messages (such as RESV messages) can not be delivered either except control messages use a totally different network from data packets. Although it is implied, the draft did not describe how to guarantee that a LSP ping for a specific LSP is forwarded through the designated LSP. It requires the ingress LSR to add the appropriate label to a LSP ping/UDP message. It also requires that intermediate LSRs not try to IP forwarding the LSP/ping UDP packet in case that label switching of the packet fails, which may not be true in many cases. Lei -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Rosen Sent: Tuesday, July 17, 2001 3:15 PM To: Shahram Davari Cc: 'mpLS@UU.net' Subject: Re: LSP-ping Shahram> Could anybody explain to me what is wrong with running ICMP-ping Shahram> over the both the forward and reverse LSP? This won't help you determine which of these two LSPs has failed, since each ICMP-ping uses both LSPs. A mechanism which uses ONLY the LSP that is being tested seems worthwhile as a fault isolation tool, and that's really what LSP-ping offers you. As you've pointed out, the mechanism only returns useful information when the control plane is functioning properly. What the mechanism really tells you is that somewhere along the line, some LSR has a corrupt label switching table, where "corrupt" may be defined as "what's in the table is not what the control plane thinks is in there". Although I think this mechanism is useful, I'm not convinced that piggybacking the response in the control messages is necessary or desirable, and I plan to look at alternative mechanisms for returning the response. From owner-mpls@UU.NET Fri Jul 20 17:37: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 RAA27699 for ; Fri, 20 Jul 2001 17:37: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 QQkynu02867; Fri, 20 Jul 2001 21:38:03 GMT Received: by mail-control.mail.uu.net id QQkynu19413 for mpls-outgoing; Fri, 20 Jul 2001 21:37: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 QQkynu19405 for ; Fri, 20 Jul 2001 21:37:25 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 QQkynu09003 for ; Fri, 20 Jul 2001 21:34:44 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.57.132.42]) id QQkynu19641 for ; Fri, 20 Jul 2001 21:34:44 GMT Message-ID: <3B58A3F2.465AD740@sandburst.com> Date: Fri, 20 Jul 2001 17:34:42 -0400 From: Eric Gray MIME-Version: 1.0 To: Dennis Hartmann Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dennis, See in-line below... You wrote: > **Comments in line > > Dennis Hartmann wrote: > > > I could be wrong, > > I suppose. > > **Thanks for the positive affirmation :-) Certainly, happy to oblige. :-) > > > > but it would seem to me that they are saying different > > things. The latter is saying that we must have an active session (TCP > > connection) over which we can advertise label spaces. The latter is > saying > > that a LSR which is advertising a label space must have the same transport > > protocol. > > Which 'latter' is which? > > **Latter being the second subject > ** .............snip.................. > ** " 1. If LSR1 does not already have an LDP session for the exchange > ** of label spaces LSR1:a and LSR2:b it attempts to open a TCP > ** connection for a new LDP session with LSR2." > ** .............snip.................. So, the other 'latter' would be the former? :-) > > > Both are wrong. Label spaces are 'advertised' using Hello exchanges over > UDP. Neither says anything about the transport protocol (references are to > the transport address). > > **Think we have some crosstalk here. That was not my intention. UDP is a > **transport protocol. UDP ports 646 or 711 can be thought of as transport > **addresses, no? If not, what are they referring to as a transport address? In section 2.5.2, of RFC 3036,Transport Address refers either to the address provided in the "Transport Address TLV" or to the source address in the UDP packet (in this preference order). The TLV comes in two flavors: IPv4 and IPv6. There is no Transport Address TLV for TCP/UDP port number. See sections 2.5.2 (starting on page 13), 3.5.2 (starting on page 51) and 3.8 (page 82). If no Transport Address TLV is provided in the Hello, then the IP source address of the Hello packet is used in its place. In a nutshell, if an implementation wants to support the same label space across multiple interfaces, it either MUST be able to force the source address to be the same in all Hello packets sent on any of these interfaces, or it MUST include Transport Address TLVs in Hellos that would not otherwise have the same source IP address. > > > To relate this to a Cisco environment... We can't advertise the > > same label space via two seperate processes (LDP and TDP). This is most > > probably why Cisco uses transport port 711 for TDP and transport port 646 > > for LDP. > > These are 'listening' ports used by the two signaling protocols and have > nothing really to do with label spaces, per-se. It is just not reasonable > to attempt to establish an LDP peer relationship using a TDP port. > > **True. That may have been a bit off. Perhaps they were talking about one > **label space being advertised over multiple sessions when to physical > **neighbors have many links between them. > > > Going by RFC 3036, these two processes can NOT be using the same > > address space (to my knowledge, the Tag field in TDP is identical to the > > MPLS header). If true, this would be a limitation while migrating a large > > deployment of TDP to LDP. Each router would need to have statically > > assigned label spaces. I'm sure Rob or Eric will clear this up for us. > > What do _you_mean by label spaces? > > **Label spaces being 2^20=1048576. Which can also be explicitly set with > the **label range command. Label Ranges are exchanged upon initialization > of **messages during the discovery phase of session establishment between > LDP **peers. Exactly what I thought you meant (and why I was earlier lamenting the naming choice). In the context of advertising label spaces, label space is an identifier that is part of an LDP-ID (see sections 2.2.1 and 2.2.2 on pages 9 and 10). In this context, label space may be used to force multiple transport connections because TCP transport connections are used in LDP sessions and LDP sessions are between LDP protocol entities as identified by the entire LSP-ID. As described in section 2.5.2, Transport Addresses are either given in a TLV (if included) or are determined from the packet source IP address and are used to determine who initiates the TCP connection. Since this determination is based on a simple comparison, both sides MUST be comparing the same quantities in order to have a reasonable expectation that they will both reliably make the same determination. > > > > > > > > Sincerely, > > > > Dennis J. Hartmann > > White Pine Consulting > > Global Knowledge-MPLS Course Director > > http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 > > dennisjhartmann@hotmail.com > > AOL IM: dennisjhartmann > > > > --- -- Eric Gray From owner-mpls@UU.NET Fri Jul 20 19:05: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 TAA25806 for ; Fri, 20 Jul 2001 19:05: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 QQkyoa14804; Fri, 20 Jul 2001 23:06:26 GMT Received: by mail-control.mail.uu.net id QQkyoa05351 for mpls-outgoing; Fri, 20 Jul 2001 23:05:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkyoa05049 for ; Fri, 20 Jul 2001 23:05:35 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 QQkyoa05007 for ; Fri, 20 Jul 2001 23:03:17 GMT Received: from web20106.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20106.mail.yahoo.com [216.136.226.43]) id QQkyoa11915 for ; Fri, 20 Jul 2001 23:03:16 GMT Message-ID: <20010720230316.31745.qmail@web20106.mail.yahoo.com> Received: from [134.56.103.118] by web20106.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 16:03:16 PDT Date: Fri, 20 Jul 2001 16:03:16 -0700 (PDT) From: Manish Godara Subject: [MPLS] Implicit Peering/Stack Attributes To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, The Architecture document talks about implicit peering in Sections 3.27.5 and 4.3. I understand the concept of implicit peering and that the "implicit peers" would distribute labels via "Stack Attributes". But I don't find any reference in other documents to "Stack Attributes". Can someone please clarify how the Stack Attributes are distributed and where can I find more information? thanks in advance, manish __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Sat Jul 21 11:32: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 SMTP id LAA12391 for ; Sat, 21 Jul 2001 11:32: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 QQkyqo03069; Sat, 21 Jul 2001 15:33:00 GMT Received: by mail-control.mail.uu.net id QQkyqo08323 for mpls-outgoing; Sat, 21 Jul 2001 15:32:28 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 QQkyqo08311 for ; Sat, 21 Jul 2001 15:32: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 QQkyqo12297 for ; Sat, 21 Jul 2001 15:31:20 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f191.pav2.hotmail.com [64.4.37.191]) id QQkyqo01947 for ; Sat, 21 Jul 2001 15:31:20 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Jul 2001 08:31:19 -0700 Received: from 209.86.7.85 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 21 Jul 2001 15:31:19 GMT X-Originating-IP: [209.86.7.85] From: "Hariom Prasad" To: mpls@UU.NET Subject: test message ( ignore ) Date: Sat, 21 Jul 2001 08:31:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jul 2001 15:31:19.0823 (UTC) FILETIME=[309DD1F0:01C111FA] Sender: owner-mpls@UU.NET Precedence: bulk _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Sun Jul 22 14:57: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 OAA13309 for ; Sun, 22 Jul 2001 14:57: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 QQkyut14181; Sun, 22 Jul 2001 18:58:31 GMT Received: by mail-control.mail.uu.net id QQkyut06693 for mpls-outgoing; Sun, 22 Jul 2001 18:58: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 QQkyut06681 for ; Sun, 22 Jul 2001 18:57:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyut08608 for ; Sun, 22 Jul 2001 18:57:13 GMT Received: from web14802.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14802.mail.yahoo.com [216.136.224.218]) id QQkyut12378 for ; Sun, 22 Jul 2001 18:57:13 GMT Message-ID: <20010722185712.97324.qmail@web14802.mail.yahoo.com> Received: from [216.174.224.251] by web14802.mail.yahoo.com via HTTP; Sun, 22 Jul 2001 11:57:12 PDT Date: Sun, 22 Jul 2001 11:57:12 -0700 (PDT) From: Vikas D Subject: draft-ietf-mpls-lsp-hierarchy-02.txt (or is it revision 3??) To: kireeti@juniper.net, yakov@juniper.net, mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3B58A3F2.465AD740@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk In section 7.2, of the LSP hierarchy draft, a requirement for using an already existing FA-LSP is: "the L3PID of the FA-LSP is compatible with the L3PID of the LSP being signaled". Further, it also states : "The PHOP in the message is the address of the LSR at the head-end of the FA-LSP. Before sending the Path/Request message, the ERO in that message is adjusted by removing the subsequence of the ERO that lies in the FA-LSP, and replacing it with just the end point of the FA-LSP." I guess this requirement holds true ONLY if the egress node for the tunneled LSP is same as the FA-LSP egress. This does not hold true when the (tunneled) LSP egress is beyond the region hosting the (tunnelling) FA-LSP. - Vikas __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-mpls@UU.NET Sun Jul 22 16:49: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 QAA29625 for ; Sun, 22 Jul 2001 16:49: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 QQkyvb21373; Sun, 22 Jul 2001 20:50:20 GMT Received: by mail-control.mail.uu.net id QQkyvb24815 for mpls-outgoing; Sun, 22 Jul 2001 20:49: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 QQkyvb24810 for ; Sun, 22 Jul 2001 20:49: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 QQkyvb15687 for ; Sun, 22 Jul 2001 20:46:32 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 QQkyvb03256 for ; Sun, 22 Jul 2001 20:46:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA01862 for mpls@uu.net; Sun, 22 Jul 2001 16:46:30 -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 QQkyvb24550 for ; Sun, 22 Jul 2001 20:45:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyvb21148 for ; Sun, 22 Jul 2001 20:45:32 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQkyvb16741 for ; Sun, 22 Jul 2001 20:45:32 GMT Received: from ASIMHA-W2K.cisco.com (rtp-vpn2-35.cisco.com [10.82.96.35]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA03022; Sun, 22 Jul 2001 16:45:08 -0400 (EDT) Date: Sun, 22 Jul 2001 16:45:16 -0400 (Eastern Daylight Time) From: Ajay Simha To: Kireeti Kompella cc: , Subject: Re: RSVP-TE tunnel using static route possible ? In-Reply-To: <200107201530.IAA03766@kummer.juniper.net> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 20 Jul 2001, Kireeti Kompella wrote: > Hi, > > It's not appropriate to use the MPLS WG mailing list for vendor-specific > questions -- use the vendors' support mailing lists instead. I agree with Kireeti. Please feel free to CC me if I can be of help for Cisco stuff. -ajay > > I'll answer you off-line. > > Kireeti. > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Sun Jul 22 18:16: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 SAA11977 for ; Sun, 22 Jul 2001 18:16: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 QQkyvh09029; Sun, 22 Jul 2001 22:17:42 GMT Received: by mail-control.mail.uu.net id QQkyvh11210 for mpls-outgoing; Sun, 22 Jul 2001 22:17: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 QQkyvh11199 for ; Sun, 22 Jul 2001 22:16:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkyvh18955 for ; Sun, 22 Jul 2001 22:16:17 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQkyvh29981 for ; Sun, 22 Jul 2001 22:16:17 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6MMGDH34961; Sun, 22 Jul 2001 15:16:13 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id PAA12837; Sun, 22 Jul 2001 15:16:13 -0700 (PDT) Date: Sun, 22 Jul 2001 15:16:13 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107222216.PAA12837@kummer.juniper.net> To: kireeti@juniper.net, mpls-ops@mplsrc.com, mpls@UU.NET, vikdw@yahoo.com, yakov@juniper.net Subject: Re: draft-ietf-mpls-lsp-hierarchy-02.txt (or is it revision 3??) In-Reply-To: <20010722185712.97324.qmail@web14802.mail.yahoo.com> Sender: owner-mpls@UU.NET Precedence: bulk Hi Vikas, > In section 7.2, of the LSP hierarchy draft, a requirement for using > an already existing FA-LSP is: > > "the L3PID of the FA-LSP is compatible with the L3PID of > the LSP being signaled". > > Further, it also states : > > "The PHOP in the message is the address of the LSR at the > head-end of the FA-LSP. Before sending the Path/Request > message, the ERO in that message is adjusted by removing > the subsequence of the ERO that lies in the FA-LSP, and > replacing it with just the end point of the FA-LSP." > > I guess this requirement holds true ONLY if the egress node for the > tunneled LSP is same as the FA-LSP egress. This does not hold true > when the (tunneled) LSP egress is beyond the region hosting the > (tunnelling) FA-LSP. The requirement holds for any tunneled LSP, whether it terminates at the egress of the FA or goes beyond. I'm not sure what role PHOP and ERO adjustment play here. Kireeti. From owner-mpls@UU.NET Sun Jul 22 21:01: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 VAA15563 for ; Sun, 22 Jul 2001 21:01: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 QQkyvs22966; Mon, 23 Jul 2001 01:02:28 GMT Received: by mail-control.mail.uu.net id QQkyvs08885 for mpls-outgoing; Mon, 23 Jul 2001 01:01: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 QQkyvs08492 for ; Mon, 23 Jul 2001 01:01:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkyvs14059 for ; Mon, 23 Jul 2001 01:00:32 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f18.law3.hotmail.com [209.185.241.18]) id QQkyvs22026 for ; Mon, 23 Jul 2001 01:00:31 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 22 Jul 2001 18:00:31 -0700 Received: from 38.186.47.9 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 23 Jul 2001 01:00:31 GMT X-Originating-IP: [38.186.47.9] From: "Gangadharan Ramakrishnan" To: mpls@UU.NET Date: Mon, 23 Jul 2001 01:00:31 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2001 01:00:31.0406 (UTC) FILETIME=[DEF594E0:01C11312] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I'm following the rfc3036(LDP Specification) for encoding and decoding of LDP messages. I found a problem in the specification encoding the Host Address FEC Element. The specification says that the PDU filed for Host Addr is more than 32 bits in a diagram and it says it is an address encoded according to the address family. I want to know the exact number of bytes/bits for this field. If it is an IP address field then there is a typo in the diagram, which represent more that 32 bits for "Host Addr". Host Address FEC Element encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Addr (3) | Address Family | Host Addr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Addr | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Host Addr An address encoded according to the Address Family field. Thanks, ganges... _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Mon Jul 23 00:41: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 AAA19576 for ; Mon, 23 Jul 2001 00:41:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkywg16108; Mon, 23 Jul 2001 04:42:29 GMT Received: by mail-control.mail.uu.net id QQkywg07402 for mpls-outgoing; Mon, 23 Jul 2001 04:41: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 QQkywg07389 for ; Mon, 23 Jul 2001 04:41: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 QQkywg13602 for ; Mon, 23 Jul 2001 04:40:52 GMT Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkywg26319 for ; Mon, 23 Jul 2001 04:40:50 GMT Received: from multitech.co.in ([192.168.1.32]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6N4b0626266; Mon, 23 Jul 2001 10:07:05 +0530 Message-ID: <3B5BABC1.A3180ECD@multitech.co.in> Date: Mon, 23 Jul 2001 10:14:49 +0530 From: abhay X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Zappacosta Rolando Jorge CC: "'mpLS@UU.NET'" Subject: Re: FastReRoute & OSPF LER References: <49BB9783DE7FD411A29D00508B6F0AD804D442CF@MSTELEFONICA1> Content-Type: multipart/alternative; boundary="------------6022CB50A1597413FA4E168D" Sender: owner-mpls@UU.NET Precedence: bulk --------------6022CB50A1597413FA4E168D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zappa, Cisco's Document authored by Robert,describes thier way of fast re-route using the Label Stack Model with Global Label Space Implementation. However their earlier releases has fast re-route appilcable only to POS interfaces and the back up path is statically configured and does not offer completed LSP protection. However,Junpier Networks implementation has FRR for both Node and Link failure(so does Cisco) and complete path protection(not Cisco). Both can be found at the Cisco and Juniper websites respectively. 1) Haskins draft on Fast Re-route and Path protection 2)Hellstrand's draft on fast re-route. 3)Shew's draft on fast re-route. All these schemes have only ideas with RNT (Reverse Notification Tree) implementations fault propogation and type of LSP failures with respective required actions. As for your second question,read the mpls extensions drafts for inter area LSP's Hope this helps. Regards, Abhay --------------6022CB50A1597413FA4E168D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi Zappa,
         Cisco's Document authored by Robert,describes thier way of fast re-route
         using the Label Stack Model with Global Label Space Implementation.
         However their earlier releases has fast re-route appilcable only to POS
         interfaces and the back up path is statically configured and does not offer
         completed LSP protection.



        However,Junpier Networks implementation has FRR for both Node and Link failure(so does Cisco)



        and complete path protection(not Cisco).



        Both can be found at the Cisco and Juniper websites respectively.






        1) Haskins draft on Fast Re-route and Path protection



        2)Hellstrand's draft on fast re-route.



        3)Shew's draft on fast re-route.



        All these schemes have only ideas with RNT (Reverse Notification Tree) implementations



        fault propogation and type of LSP failures with respective required actions.






        As for your second question,read the mpls extensions drafts for inter area



        LSP's



        Hope this helps.



        Regards,



        Abhay

 

--------------6022CB50A1597413FA4E168D--



From owner-mpls@UU.NET  Mon Jul 23 03:01: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 DAA06772
	for ; Mon, 23 Jul 2001 03:01: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 QQkywq13319;
	Mon, 23 Jul 2001 07:02:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkywq02164
	for mpls-outgoing; Mon, 23 Jul 2001 07:01:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkywq01389
	for ; Mon, 23 Jul 2001 07:01:27 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 QQkywq11663
	for ; Mon, 23 Jul 2001 07:00:05 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f22.law10.hotmail.com [64.4.15.22])
	id QQkywq11127
	for ; Mon, 23 Jul 2001 07:00:04 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 23 Jul 2001 00:00:03 -0700
Received: from 212.25.110.131 by lw10fd.law10.hotmail.msn.com with HTTP;	Mon, 23 Jul 2001 07:00:03 GMT
X-Originating-IP: [212.25.110.131]
From: "Shawn H" 
To: mpls@UU.NET
Cc: sah5@hotmail.com
Subject: RSVP-TE message when preempting
Date: Mon, 23 Jul 2001 07:00:03 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jul 2001 07:00:03.0761 (UTC) FILETIME=[1915BA10:01C11345]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

what document details the type of message that a transit LSR must send when 
pre-empting a tunnel? Is it PathErr or PathTear? And if PathErr, what error 
code?

Thanks,
   Shawn.

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



From owner-mpls@UU.NET  Mon Jul 23 04:52: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 EAA07650
	for ; Mon, 23 Jul 2001 04:52:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkywx25245;
	Mon, 23 Jul 2001 08:53:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkywx14500
	for mpls-outgoing; Mon, 23 Jul 2001 08:53: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 QQkywx14492
	for ; Mon, 23 Jul 2001 08:52: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 QQkywx22250
	for ; Mon, 23 Jul 2001 08:52:21 GMT
Received: from sepahan.iut.ac.ir by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [213.29.206.3])
	id QQkywx24428
	for ; Mon, 23 Jul 2001 08:52:15 GMT
Received: from saba ([213.29.206.94])
	by sepahan.iut.ac.ir (8.11.2/8.11.2) with SMTP id f6N8r7j19384
	for ; Mon, 23 Jul 2001 13:23:09 +0430
Message-ID: <001301c11354$f4140d60$6501a8c0@saba>
From: "Ali Ghiasian" 
To: 
Subject: Load Balancing algorithm
Date: Mon, 23 Jul 2001 13:23:26 +0430
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C1137A.A7E7F8E0"
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

Hi all
I am looking for available load balancing(for traffic engineering =
purposes) algorithms for MPLS networks.
Does any one know any refrence?
Thanks in advance
Ali Ghiasian

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









Hi all


I am looking for available load =
balancing(for=20
traffic engineering purposes) algorithms for MPLS =
networks.


Does any one know any =
refrence?


Thanks in advance


Ali Ghiasian


------=_NextPart_000_0010_01C1137A.A7E7F8E0--



From owner-mpls@UU.NET  Mon Jul 23 05:29: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 FAA07981
	for ; Mon, 23 Jul 2001 05:29: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 QQkyxa07163;
	Mon, 23 Jul 2001 09:30:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxa06948
	for mpls-outgoing; Mon, 23 Jul 2001 09: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 QQkywz06911
	for ; Mon, 23 Jul 2001 09:29:43 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 QQkywz00292
	for ; Mon, 23 Jul 2001 09:28:40 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 QQkywz05236
	for ; Mon, 23 Jul 2001 09:28:39 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6NF7Zu16690
	for ; Mon, 23 Jul 2001 15:07:35 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GGX6LX00.CZY; Mon, 23 Jul 2001 15:04:45 +0530 
Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id KAA28585; Mon, 23 Jul 2001 10:07:48 +0530
Date: Mon, 23 Jul 2001 15:05:22 +0530 (IST)
From: "chetan kumar s" 
X-Sender: chetansk@soflt.alc.wipinfo.soft.net
Reply-To: chetan.kumar@wipro.com
To: mpls@UU.NET
cc: eric.gray@sandburst.com
Subject: Next Hop Change..
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Eric,
	
	I was just going thro' the mailing archives, got into some
confusing things. Please refer to the archives for this mail..

http://cell.onecall.net/mhonarc/mpls/2001-May/msg00352.html

U have mentioned that LSR need to withdraw the labels when operating in
Ordered Control Mode..


" d) if operating in ordered control mode, LSR-A would withdraw labels it
has previously provided for FEC F to its peers - especially if
it is not currently capable of establishing a new binding to a label
issued by the new next hop; note that this will result in tearing down
the LSP for FEC F fom each upstream peer all the way to however many
ingress LSRs there are. "

Now if refer to RFC, A.1.7,, page 115, NH.17. This statement is reached
only when the LSR is in DoD OR the peer is in DoD. If operating in un
solictated order control mode this statement is never reached.

In a way I think ur explanation seems OK. If a LSR sends label mapping
due the the fact that it is order control mode, then it *has* to withdraw
the mapping. On the other hand if the mapping is sent from a independent
control mode LSR, it need not withdraw the label. 

Any comments...

Thanks
Chetan S





From owner-mpls@UU.NET  Mon Jul 23 08:22: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 SMTP id IAA14508
	for ; Mon, 23 Jul 2001 08:22: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 QQkyxl24284;
	Mon, 23 Jul 2001 12:23:17 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxl21031
	for mpls-outgoing; Mon, 23 Jul 2001 12:22: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 QQkyxl21004
	for ; Mon, 23 Jul 2001 12:22: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 QQkyxl18996
	for ; Mon, 23 Jul 2001 12:21:29 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkyxl24039
	for ; Mon, 23 Jul 2001 12:21:27 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 23 Jul 2001 17:49:18 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71FF0E5@mailserver.netbrahma.com>
From: Khuzema Pithewan 
To: "'mpls@uu.net'" 
Subject: Common label
Date: Mon, 23 Jul 2001 17:49:15 +0530
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,

In "draft-ietf-mpls-rsvp-lsp-tunnel-08" section 2.4.3 says...

" Multipoint-to-point LSPs may be used when path messages do not carry the
EXPLICIT_ROUTE object, or when Path messages have identical EXPICIT_ROUTE
objects.  In either of these cases a common label may be assigned."

My question is, why it should check if EXPLICIT_ROUTE object should be same
to provide common label? I think instead of checking EXPLICIT_ROUTE object,
if I just check for the incoming and outgoing interfaces of the Path
messages on the LSR, even then I can assign the common label if they are
same.  

Regards,
Khuzema.
------------------------------------------------
Net Brahma Technologies Private Limited
Internext Networking Software
A Microland Group Company
777, 3rd 'a' cross, 18th Main 
Koramangala VI th block
Bangalore-95
Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
Fax no        - (080) 5537233 
email : khuzemap@netbrahma.com
www.netbrahma.com



From owner-mpls@UU.NET  Mon Jul 23 09:10:38 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 JAA17919
	for ; Mon, 23 Jul 2001 09:10: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 QQkyxo11356;
	Mon, 23 Jul 2001 13:11:29 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxo09452
	for mpls-outgoing; Mon, 23 Jul 2001 13:10:57 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkyxo08672
	for ; Mon, 23 Jul 2001 13: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 QQkyxo23193
	for ; Mon, 23 Jul 2001 13:09:21 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQkyxo14107
	for ; Mon, 23 Jul 2001 13:09:18 GMT
Received: from multitech.co.in ([192.168.1.32])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6ND54w14433;
	Mon, 23 Jul 2001 18:35:04 +0530
Message-ID: <3B5C22D9.115EB4BE@multitech.co.in>
Date: Mon, 23 Jul 2001 18:42:57 +0530
From: abhay 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ali Ghiasian 
CC: mpls@UU.NET
Subject: Re: Load Balancing algorithm
X-Priority: 2 (High)
References: <001301c11354$f4140d60$6501a8c0@saba>
Content-Type: multipart/alternative;
 boundary="------------8CDAE6596389A85FC55B1B68"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------8CDAE6596389A85FC55B1B68
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ali Ghiansian,

             In generally the load balancing is done by constraint based routing alogrithms,

             With different tie-breaking methods.It is an extension to the SPF alogorithm,but

             routing of traffic has to be controlled on a percentage basis.

             Hope this helps.

             Regards,

             Abhay



Ali Ghiasian wrote:

> Hi allI am looking for available load balancing(for traffic
> engineering purposes) algorithms for MPLS networks.Does any one know
> any refrence?Thanks in advanceAli Ghiasian

--------------8CDAE6596389A85FC55B1B68
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit






Ali Ghiansian,



             In generally the load balancing is done by constraint based routing alogrithms,



             With different tie-breaking methods.It is an extension to the SPF alogorithm,but



             routing of traffic has to be controlled on a percentage basis.



             Hope this helps.



             Regards,



             Abhay



 




Ali Ghiasian wrote:


Hi
allI am looking for available
load balancing(for traffic engineering purposes) algorithms for MPLS networks.Does
any one know any refrence?Thanks
in advanceAli Ghiasian





--------------8CDAE6596389A85FC55B1B68--



From owner-mpls@UU.NET  Mon Jul 23 09:38: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 JAA19772
	for ; Mon, 23 Jul 2001 09:38: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 QQkyxq15674;
	Mon, 23 Jul 2001 13:39:36 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxq18404
	for mpls-outgoing; Mon, 23 Jul 2001 13:39: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 QQkyxq18378
	for ; Mon, 23 Jul 2001 13:38: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 QQkyxq11059
	for ; Mon, 23 Jul 2001 13:38:23 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQkyxq04069
	for ; Mon, 23 Jul 2001 13:38:22 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA07522
	for ; Mon, 23 Jul 2001 09:38:22 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23007 for mpls@uu.net; Mon, 23 Jul 2001 09:38:12 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkynr25572
	for ; Fri, 20 Jul 2001 20:47:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkynq04128
	for ; Fri, 20 Jul 2001 20:43:17 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 QQkynq27130
	for ; Fri, 20 Jul 2001 20:43:17 GMT
Received: by c0mailgw11.prontomail.com (NPlex 5.5.029) id 3B5716E500037910; Fri, 20 Jul 2001 15:40:25 -0700
Received: from 148.75.48.66 by SmtpServer for ; Fri, 20 Jul 2001 20:37:47 +0000
Reply-To: 
From: "Dennis Hartmann" 
To: "Eric Gray" 
Cc: , 
Subject: RE: RFC : 3036 : Session establishment for multiple adjacencies.
Date: Fri, 20 Jul 2001 16:45:25 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002F_01C1113B.60233FB0"
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: <3B588B58.5C65E980@sandburst.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C1113B.60233FB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

**Comments in line

Dennis Hartmann wrote:

>         I could be wrong,

I suppose.

**Thanks for the positive affirmation :-)

> but it would seem to me that they are saying different
> things.  The latter is saying that we must have an active session (TCP
> connection) over which we can advertise label spaces.  The latter is
saying
> that a LSR which is advertising a label space must have the same transport
> protocol.

Which 'latter' is which?

**Latter being the second subject
**              .............snip..................
**  "  1. If LSR1 does not already have an LDP session for the exchange
**       of label spaces LSR1:a and LSR2:b it attempts to open a TCP
**       connection for a new LDP session with LSR2."
**             .............snip..................

Both are wrong.  Label spaces are 'advertised' using Hello exchanges over
UDP.  Neither says anything about the transport protocol (references are to
the transport address).

**Think we have some crosstalk here.  That was not my intention.  UDP is a
**transport protocol.  UDP ports 646 or 711 can be thought of as transport
**addresses, no?  If not, what are they referring to as a transport address?

> To relate this to a Cisco environment... We can't advertise the
> same label space via two seperate processes (LDP and TDP).  This is most
> probably why Cisco uses transport port 711 for TDP and transport port 646
> for LDP.

These are 'listening' ports used by the two signaling protocols and have
nothing really to do with label spaces, per-se.  It is just not reasonable
to attempt to establish an LDP peer relationship using a TDP port.

**True.  That may have been a bit off.  Perhaps they were talking about one
**label space being advertised over multiple sessions when to physical
**neighbors have many links between them.

> Going by RFC 3036, these two processes can NOT be using the same
> address space (to my knowledge, the Tag field in TDP is identical to the
> MPLS header).  If true, this would be a limitation while migrating a large
> deployment of TDP to LDP.  Each router would need to have statically
> assigned label spaces.  I'm sure Rob or Eric will clear this up for us.

What do _you_mean by label spaces?

**Label spaces being 2^20=1048576.  Which can also be explicitly set with
the **label range command.  Label Ranges are exchanged upon initialization
of **messages during the discovery phase of session establishment between
LDP **peers.

>
>
> Sincerely,
>
> Dennis J. Hartmann
> White Pine Consulting
> Global Knowledge-MPLS Course Director
> http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571
> dennisjhartmann@hotmail.com
> AOL IM: dennisjhartmann
>
> -----Original Message-----
> From: Vikas D [mailto:vikdw@yahoo.com]
> Sent: Wednesday, July 18, 2001 2:48 PM
> To: mpls-ops@mplsrc.com; mpls@UU.NET
> Subject: Re: RFC : 3036 : Session establishment for multiple
> adjacencies.
>
> All,
>
> A small doubt in Section 2.5.2, "Transport Connection
> Establishment"
> of LDP RFC.  It says:
>
>              .............snip..................
>  "An LSR MUST advertise the same transport address in all Hellos that
>   advertise the same label space.  This requirement ensures that two
>   LSRs linked by multiple Hello adjacencies using the same label
> spaces
>   play the same connection establishment role for each adjacency."
>              .............snip....................
>
> Now, under what circumstances would two LSRs, having multiple
> hello adjacencies , using same label spaces on all adjacencies
> try to establish multiple TCP sessions?
>
> Is this not already precluded by the following rule in the same
> section (Sec 2.5.2 of RFC 3036):
>
>              .............snip..................
>  "  1. If LSR1 does not already have an LDP session for the exchange
>        of label spaces LSR1:a and LSR2:b it attempts to open a TCP
>        connection for a new LDP session with LSR2."
>              .............snip..................
>
> Thanks
> - Vikas
>
> __________________________________________________
> 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

------=_NextPart_000_002F_01C1113B.60233FB0
Content-Type: text/x-vcard;
	name="Dennis J. Hartmann.vcf"
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:Instructor/Consultant
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:20010715T061237Z
END:VCARD

------=_NextPart_000_002F_01C1113B.60233FB0--



From owner-mpls@UU.NET  Mon Jul 23 09:40:25 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 JAA19952
	for ; Mon, 23 Jul 2001 09:40: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 QQkyxq03448;
	Mon, 23 Jul 2001 13:41:18 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxq18512
	for mpls-outgoing; Mon, 23 Jul 2001 13:40: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 QQkyxq18466
	for ; Mon, 23 Jul 2001 13:40:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkyxq14787
	for ; Mon, 23 Jul 2001 13:39:00 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 QQkyxq14883
	for ; Mon, 23 Jul 2001 13:38:54 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA14985 for ; Mon, 23 Jul 2001 09:38:54 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23013 for mpls@uu.net; Mon, 23 Jul 2001 09:38: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 QQkyqq01156
	for ; Sat, 21 Jul 2001 16:11: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 QQkyqq29042
	for ; Sat, 21 Jul 2001 16:09:32 GMT
Received: from piorun.ds.pg.gda.pl by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: piorun.ds.pg.gda.pl [213.192.76.1])
	id QQkyqq16921
	for ; Sat, 21 Jul 2001 16:09:31 GMT
Received: from localhost (maks@localhost)
	by piorun.ds.pg.gda.pl (8.11.4/8.11.4) with ESMTP id f6LGGfH02367
	for ; Sat, 21 Jul 2001 18:16:42 +0200
Date: Sat, 21 Jul 2001 18:16:40 +0200 (CEST)
From: Maks 
To: 
Subject: IPv4, IPv6
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,
I would like to ask are there any differences between implementing MPLS in
IPv4 and IPv6 netowrks? Which is more suitable or it doesn't matter? Is
there any relationship between MPLS label and IPv6 Flow label?

Best regards,

Maks Milkowski




From owner-mpls@UU.NET  Mon Jul 23 09:41: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 JAA20093
	for ; Mon, 23 Jul 2001 09:41:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkyxq04482;
	Mon, 23 Jul 2001 13:42:22 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxq18523
	for mpls-outgoing; Mon, 23 Jul 2001 13:40: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 QQkyxq18435
	for ; Mon, 23 Jul 2001 13:39: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 QQkyxq23149
	for ; Mon, 23 Jul 2001 13:39:21 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQkyxq05389
	for ; Mon, 23 Jul 2001 13:39:20 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA07595
	for ; Mon, 23 Jul 2001 09:39:20 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23017 for mpls@uu.net; Mon, 23 Jul 2001 09:39: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 QQkyte03218
	for ; Sun, 22 Jul 2001 08:36: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 QQkyte12437
	for ; Sun, 22 Jul 2001 08:34:58 GMT
Received: from web14301.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14301.mail.yahoo.com [216.136.173.77])
	id QQkyte01098
	for ; Sun, 22 Jul 2001 08:34:58 GMT
Message-ID: <20010722083458.9614.qmail@web14301.mail.yahoo.com>
Received: from [202.41.72.200] by web14301.mail.yahoo.com via HTTP; Sun, 22 Jul 2001 01:34:58 PDT
Date: Sun, 22 Jul 2001 01:34:58 -0700 (PDT)
From: Bruce Prasad 
Subject: hello msg. socket
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


sir,

I am currently doing mpls for cdot at Banglore
I have a doubt on the hello message's socket.
Hello message is send on a multicast socket. After
session established, we use a TCP socket for LDP 
message transceving. So which socket i want to use for
furthor Hello messages. i.e. either TCP socket or 
the multicasted socket. If  multicasted socket will
use  
then the Hello msg should be received by other
machines
in the network , to which it have no LDP connection.

thanks in advance

		bruceprasad@yahoo.com

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Mon Jul 23 09:42: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 JAA20202
	for ; Mon, 23 Jul 2001 09:42: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 QQkyxq20454;
	Mon, 23 Jul 2001 13:43:27 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxq18535
	for mpls-outgoing; Mon, 23 Jul 2001 13:40: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 QQkyxq18514
	for ; Mon, 23 Jul 2001 13:40: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 QQkyxq03468
	for ; Mon, 23 Jul 2001 13:39:49 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQkyxq06087
	for ; Mon, 23 Jul 2001 13:39:49 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA07648
	for ; Mon, 23 Jul 2001 09:39:48 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23027 for mpls@uu.net; Mon, 23 Jul 2001 09:39:39 -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 QQkyux01063
	for ; Sun, 22 Jul 2001 19:54: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 QQkyux23207;
	Sun, 22 Jul 2001 19:53:29 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f128.law3.hotmail.com [209.185.241.128])
	id QQkyux27963;
	Sun, 22 Jul 2001 19:53:28 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 22 Jul 2001 12:53:28 -0700
Received: from 38.186.47.9 by lw3fd.law3.hotmail.msn.com with HTTP;	Sun, 22 Jul 2001 19:53:28 GMT
X-Originating-IP: [38.186.47.9]
From: "Gangadharan Ramakrishnan" 
To: mpls@UU.NET
Cc: mpls-request@UU.NET
Subject: Question in Host Address FEC Element encoding
Date: Sun, 22 Jul 2001 19:53:28 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 22 Jul 2001 19:53:28.0392 (UTC) FILETIME=[F9FCBC80:01C112E7]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I'm following the rfc3036(LDP Specification) for encoding and decoding of 
LDP messages. I found a problem in the specification encoding the Host 
Address FEC Element. The specification says that the PDU filed for Host Addr 
is more than 32 bits in a diagram and it says it is an address encoded 
according to the address family.

I want to know the exact number of bytes/bits for this field. If it is an IP 
address field then there is a typo in the diagram, which represent more that 
32 bits for "Host Addr".

Host Address FEC Element encoding:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Addr (3) |     Address Family            | Host Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Host Addr                                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Host Addr
An address encoded according to the Address Family field.


Thanks,
ganges...


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



From owner-mpls@UU.NET  Mon Jul 23 10:01:47 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 KAA21744
	for ; Mon, 23 Jul 2001 10:01: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 QQkyxs12810;
	Mon, 23 Jul 2001 14:02:39 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxs25398
	for mpls-outgoing; Mon, 23 Jul 2001 14:02: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 QQkyxs25263
	for ; Mon, 23 Jul 2001 14:01: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 QQkyxr05016
	for ; Mon, 23 Jul 2001 13:58:42 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQkyxr02588
	for ; Mon, 23 Jul 2001 13:58:41 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6NJbcu18410
	for ; Mon, 23 Jul 2001 19:37:38 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GGXJ4100.G98; Mon, 23 Jul 2001 19:34:49 +0530 
Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id OAA29871; Mon, 23 Jul 2001 14:37:52 +0530
Date: Mon, 23 Jul 2001 19:35:25 +0530 (IST)
From: "chetan kumar s" 
X-Sender: chetansk@soflt.alc.wipinfo.soft.net
Reply-To: chetan.kumar@wipro.com
To: Gangadharan Ramakrishnan 
cc: mpls@UU.NET
Subject: Re: Question in Host Address FEC Element encoding
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Sun, 22 Jul 2001, Gangadharan Ramakrishnan wrote:

> Hi,
> I'm following the rfc3036(LDP Specification) for encoding and decoding of 
> LDP messages. I found a problem in the specification encoding the Host 
> Address FEC Element. The specification says that the PDU filed for Host Addr 
> is more than 32 bits in a diagram and it says it is an address encoded 
> according to the address family.
> 
> I want to know the exact number of bytes/bits for this field. If it is an IP 

Hi,
As mentioned in the RFC this depends on address family, = 32 for IPv4 and
= 128 for IPv6

Thanks
Chetan S



From owner-mpls@UU.NET  Mon Jul 23 10:03: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 KAA21869
	for ; Mon, 23 Jul 2001 10:03: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 QQkyxs20140;
	Mon, 23 Jul 2001 14:04:05 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxs26637
	for mpls-outgoing; Mon, 23 Jul 2001 14:03: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 QQkyxs25825
	for ; Mon, 23 Jul 2001 14:02: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 QQkyxs08047
	for ; Mon, 23 Jul 2001 14:01:58 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 QQkyxs18745
	for ; Mon, 23 Jul 2001 14:01:58 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10945;
	Mon, 23 Jul 2001 10:01:56 -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 KAA01809;
	Mon, 23 Jul 2001 10:01:57 -0400 (EDT)
Message-ID: <3B5C2E71.1370CBF4@marconi.com>
Date: Mon, 23 Jul 2001 10:02: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: Shawn H 
CC: mpls@UU.NET
Subject: Re: RSVP-TE message when preempting
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shawn H wrote:
> 
> what document details the type of message that a transit LSR must
> send when pre-empting a tunnel? Is it PathErr or PathTear? And if
> PathErr, what error code?

draft-ietf-mpls-rsvp-lsp-tunnel-08.txt

Section 4.7.3:

	...
	When pre-emption is supported, each pre-empted reservation
	triggers a TC_Preempt() upcall to local clients, passing a
	subcode that indicates the reason.  A ResvErr and/or PathErr
	with the code "Policy Control failiure" SHOULD be sent toward
	the downstream receivers and upstream senders.
	...

-- David


From owner-mpls@UU.NET  Mon Jul 23 10:04: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 KAA21995
	for ; Mon, 23 Jul 2001 10:04: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 QQkyxs21264;
	Mon, 23 Jul 2001 14:05:05 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxs26720
	for mpls-outgoing; Mon, 23 Jul 2001 14:03: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 QQkyxs26582
	for ; Mon, 23 Jul 2001 14:03: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 QQkyxs09602
	for ; Mon, 23 Jul 2001 14:02:49 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 QQkyxs19239
	for ; Mon, 23 Jul 2001 14:02:48 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6NJfju19267
	for ; Mon, 23 Jul 2001 19:41:45 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GGXJAW00.G9B; Mon, 23 Jul 2001 19:38:56 +0530 
Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id OAA29879; Mon, 23 Jul 2001 14:41:59 +0530
Date: Mon, 23 Jul 2001 19:39:32 +0530 (IST)
From: "chetan kumar s" 
X-Sender: chetansk@soflt.alc.wipinfo.soft.net
Reply-To: chetan.kumar@wipro.com
To: Maks 
cc: mpls@UU.NET
Subject: Re: IPv4, IPv6
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Maks,

	There would be some differences.. Like hierarchical addressing of
IPv6 and route aggregation supported by IPv6 should make some things more
complex and efficient.. 

Thanks
Chetan S

> Hi all,
> I would like to ask are there any differences between implementing MPLS in
> IPv4 and IPv6 netowrks? Which is more suitable or it doesn't matter? Is
> there any relationship between MPLS label and IPv6 Flow label?
> 
> Best regards,
> 
> Maks Milkowski
> 
> 



From owner-mpls@UU.NET  Mon Jul 23 10:12: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 SMTP id KAA22640
	for ; Mon, 23 Jul 2001 10:12: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 QQkyxs25762;
	Mon, 23 Jul 2001 14:13:05 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxs11709
	for mpls-outgoing; Mon, 23 Jul 2001 14:12:31 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkyxs11686
	for ; Mon, 23 Jul 2001 14:12:25 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 QQkyxs04549
	for ; Mon, 23 Jul 2001 14:11:01 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 QQkyxs23245
	for ; Mon, 23 Jul 2001 14:11:01 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 KAA12341
	for ; Mon, 23 Jul 2001 10:10: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 KAA04816
	for ; Mon, 23 Jul 2001 10:10:59 -0400 (EDT)
Message-ID: <3B5C3090.DFED3244@marconi.com>
Date: Mon, 23 Jul 2001 10:11:28 -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: Common label
References: <13D467F625FAD511AE2A00D0B7B917D71FF0E5@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Khuzema Pithewan wrote:
> 
> In "draft-ietf-mpls-rsvp-lsp-tunnel-08" section 2.4.3 says...
> 
> " Multipoint-to-point LSPs may be used when path messages do not
> carry the EXPLICIT_ROUTE object, or when Path messages have
> identical EXPICIT_ROUTE objects.  In either of these cases a
> common label may be assigned."
> 
> My question is, why it should check if EXPLICIT_ROUTE object should
> be same to provide common label? I think instead of checking
> EXPLICIT_ROUTE object, if I just check for the incoming and
> outgoing interfaces of the Path messages on the LSR, even then I
> can assign the common label if they are same.

Think about what will happen on the data plane.  Remember that data
packets are forwarded only according to their labels, and not according
to the actual content of the packets.

If you assign the same label to two different LSPs, then you effectively
merge them together.  Packets from both LSPs will necessarily follow the
same path to the egress, because they will have the same label.

If there is no ERO, or if the two LSPs have identical EROs, this merging
is not a problem - the packets are all going the same way anyway.  If
they have different EROs, however, then the data from one LSP will not
be able to follow the ERO, because it is sharing a label with an LSP
that has a different ERO.

-- David


From owner-mpls@UU.NET  Mon Jul 23 10:15: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 KAA22952
	for ; Mon, 23 Jul 2001 10:15: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 QQkyxt00577;
	Mon, 23 Jul 2001 14:16:37 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxt13073
	for mpls-outgoing; Mon, 23 Jul 2001 14: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 QQkyxt13012
	for ; Mon, 23 Jul 2001 14:15: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 QQkyxs10779
	for ; Mon, 23 Jul 2001 14:12:33 GMT
Received: from sepahan.iut.ac.ir by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [213.29.206.3])
	id QQkyxs24748
	for ; Mon, 23 Jul 2001 14:12:17 GMT
Received: from saba ([213.29.206.94])
	by sepahan.iut.ac.ir (8.11.2/8.11.2) with SMTP id f6NECpj20526;
	Mon, 23 Jul 2001 18:42:51 +0430
Message-ID: <003501c11381$9e7fd050$6501a8c0@saba>
From: "Ali Ghiasian" 
To: "abhay" 
Cc: 
References: <001301c11354$f4140d60$6501a8c0@saba> <3B5C22D9.115EB4BE@multitech.co.in>
Subject: Re: Load Balancing algorithm
Date: Mon, 23 Jul 2001 18:43:12 +0430
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0032_01C113A7.536B4650"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01C113A7.536B4650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ,=20
I think that in addition to constraint based routing, an algorithm is =
required to choose among parallel LSPs one for carrying traffic =
flows.(for example based on minimizing a cost function).I mean that =
algorithm.
Regards
Ali Ghiasian
  ----- Original Message -----=20
  From: abhay=20
  To: Ali Ghiasian=20
  Cc: mpls@UU.NET=20
  Sent: Monday, July 23, 2001 5:42 PM
  Subject: Re: Load Balancing algorithm


Ali Ghiansian,
             In generally the load balancing is done by constraint based =
routing alogrithms,
             With different tie-breaking methods.It is an extension to =
the SPF alogorithm,but
             routing of traffic has to be controlled on a percentage =
basis.
             Hope this helps.
             Regards,
             Abhay
=20

  Ali Ghiasian wrote:=20

    Hi allI am looking for available load balancing(for traffic =
engineering purposes) algorithms for MPLS networks.Does any one know any =
refrence?Thanks in advanceAli Ghiasian

------=_NextPart_000_0032_01C113A7.536B4650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi , 


I think that in addition to constraint =
based=20
routing, an algorithm is required to choose among parallel LSPs one =
for=20
carrying traffic flows.(for example based on minimizing a cost =
function).I mean=20
that algorithm.


Regards


Ali Ghiasian


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

  From:=20
  abhay=20
  
  
To: Ali=20
  Ghiasian 

  
  
Sent: Monday, July 23, 2001 =
5:42 PM

  
Subject: Re: Load Balancing=20
  algorithm

  

Ali =
Ghiansian,
        &nbs=
p;    In generally the load balancing is done by =
constraint based routing =
alogrithms,
        &nb=
sp;    With different tie-breaking methods.It is an =
extension to the SPF =
alogorithm,but
        =
     routing of traffic has to be controlled on a =
percentage =
basis.
         &n=
bsp;   Hope this =
helps.
         &n=
bsp;   =
Regards,
         =
    Abhay
 

  

Ali Ghiasian wrote:=20
  

    
    Hi allI am looking for available load balancing(for traffic =
engineering=20
    purposes) algorithms for MPLS networks.Does any one know any refrence?Thanks in advanceAli=20
    Ghiasian


------=_NextPart_000_0032_01C113A7.536B4650--



From owner-mpls@UU.NET  Mon Jul 23 10:37: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 SMTP id KAA24818
	for ; Mon, 23 Jul 2001 10:37: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 QQkyxu17875;
	Mon, 23 Jul 2001 14:38:30 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxu15617
	for mpls-outgoing; Mon, 23 Jul 2001 14:37: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 QQkyxu15582
	for ; Mon, 23 Jul 2001 14: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 QQkyxu06519
	for ; Mon, 23 Jul 2001 14:36:15 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkyxu24008
	for ; Mon, 23 Jul 2001 14:36:13 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 23 Jul 2001 20:04:04 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71FF0EB@mailserver.netbrahma.com>
From: Khuzema Pithewan 
To: "'mpls@uu.net'" ,
        "'David Charlap'"
	 
Subject: RE: Common label
Date: Mon, 23 Jul 2001 20:04:00 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

At LSR, If I am receiving a Resv message with a new filterspec(style is SE),
with the same label(i.e. outgoing label) then it means LSP are already
merged, so at this point  whether I check for ERO or not, doesn't matter,
because ERO is for the downstream path from this LSR and I am allocating
label for the upstream path(i.e. incoming label). 

If ERO is different for 2 LSP, then I will never receive the same label at
this LSR, as the downstream LSR(at which LSP route is getting changed) will
never send the same labels, as previous hops are different at the downstream
LSR..

Khuzema.

> ----------
> From: 	David Charlap
> Sent: 	Monday, July 23, 2001 7:41 PM
> To: 	'mpls@uu.net'
> Subject: 	Re: Common label
> 
> Khuzema Pithewan wrote:
> > 
> > In "draft-ietf-mpls-rsvp-lsp-tunnel-08" section 2.4.3 says...
> > 
> > " Multipoint-to-point LSPs may be used when path messages do not
> > carry the EXPLICIT_ROUTE object, or when Path messages have
> > identical EXPICIT_ROUTE objects.  In either of these cases a
> > common label may be assigned."
> > 
> > My question is, why it should check if EXPLICIT_ROUTE object should
> > be same to provide common label? I think instead of checking
> > EXPLICIT_ROUTE object, if I just check for the incoming and
> > outgoing interfaces of the Path messages on the LSR, even then I
> > can assign the common label if they are same.
> 
> Think about what will happen on the data plane.  Remember that data
> packets are forwarded only according to their labels, and not according
> to the actual content of the packets.
> 
> If you assign the same label to two different LSPs, then you effectively
> merge them together.  Packets from both LSPs will necessarily follow the
> same path to the egress, because they will have the same label.
> 
> If there is no ERO, or if the two LSPs have identical EROs, this merging
> is not a problem - the packets are all going the same way anyway.  If
> they have different EROs, however, then the data from one LSP will not
> be able to follow the ERO, because it is sharing a label with an LSP
> that has a different ERO.
> 
> -- David
> 


From owner-mpls@UU.NET  Mon Jul 23 10:42: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 KAA25139
	for ; Mon, 23 Jul 2001 10:42:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkyxu22325;
	Mon, 23 Jul 2001 14:43:11 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxu16627
	for mpls-outgoing; Mon, 23 Jul 2001 14:42:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkyxu16594
	for ; Mon, 23 Jul 2001 14:42:18 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 QQkyxu21511
	for ; Mon, 23 Jul 2001 14:41:49 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQkyxu00414
	for ; Mon, 23 Jul 2001 14:41:49 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14643
	for ; Mon, 23 Jul 2001 10:41:48 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA24222 for mpls@uu.net; Mon, 23 Jul 2001 10:41: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 QQkyxu16016
	for ; Mon, 23 Jul 2001 14:39: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 QQkyxu10349
	for ; Mon, 23 Jul 2001 14:39:51 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f140.pav2.hotmail.com [64.4.37.140])
	id QQkyxu28147
	for ; Mon, 23 Jul 2001 14:39:50 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 23 Jul 2001 07:39:49 -0700
Received: from 192.122.173.135 by pv2fd.pav2.hotmail.msn.com with HTTP;	Mon, 23 Jul 2001 14:39:49 GMT
X-Originating-IP: [192.122.173.135]
From: "Kannan J" 
To: mpls@UU.NET
Subject: Defining FEC types at the ingress...
Date: Mon, 23 Jul 2001 14:39:49 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jul 2001 14:39:49.0792 (UTC) FILETIME=[53A40200:01C11385]
Sender: owner-mpls@UU.NET
Precedence: bulk




Hi

The MPLS Architecture states that different types of
FECs can be defined at an ingress to allow for both
coarse grained and fine grained forwarding granularity.

At present LDP supports only two types of FEC
elements -  the host address and address prefix types.
So even though we may define other types of FEC elements
(e.g based on port no etc ) at the ingress it will not
make sense to the LSRs downstream to the ingress as label
exchange happens based only on the destination address
prefix ( coarse forwarding granularity).

However it does seem possible to achieve fine forwarding
granularity through static configuration or via SNMP. For
example the FTN MIB does have a provision to support FEC
elements other than what LDP provides namely source address type ,  port no 
etc and then map them to preconfigured LSPs thereby
having the capability to map specific flows to specific LSPs.

My question is :  should implementors of the mpls stack
assume that only those FEC types as defined in the LDP spec be
used or can they assume that there can be different types of FEC
elements as described above ?    And if the latter how will it
help as unless LDP is extended to support new FEC types such as source
address or port no ,  there will not be any real benefit.

I would appreciate your comments/clarifications on this.

Thanks
Kannan



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



From owner-mpls@UU.NET  Mon Jul 23 10:45: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 KAA25420
	for ; Mon, 23 Jul 2001 10:45: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 QQkyxv06200;
	Mon, 23 Jul 2001 14:46:37 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxv17623
	for mpls-outgoing; Mon, 23 Jul 2001 14:46: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 QQkyxv17566
	for ; Mon, 23 Jul 2001 14:45:43 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 QQkyxu25825
	for ; Mon, 23 Jul 2001 14:44:12 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 QQkyxu03284
	for ; Mon, 23 Jul 2001 14:44:11 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 KAA17395;
	Mon, 23 Jul 2001 10:44:05 -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 KAA16146;
	Mon, 23 Jul 2001 10:44:05 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 23 Jul 2001 10:43:54 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C60D@VIE-MSGUSR-01>
From: "Naidu, Venkata" 
To: "'Ali Ghiasian'" ,
        abhay
	 
Cc: mpls@UU.NET
Subject: RE: Load Balancing algorithm
Date: Mon, 23 Jul 2001 10:43: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

Ali:

Please look at below link(s)...

http://cell-relay.indiana.edu/mhonarc/mpls/2001-Apr/msg00439.html


--Venkata Naidu


Hi , 
I think that in addition to constraint based routing, an algorithm is
required to choose among parallel LSPs one for carrying traffic flows.(for
example based on minimizing a cost function).I mean that algorithm.
Regards
Ali Ghiasian
----- Original Message ----- 
From: abhay 
To: Ali Ghiasian 
Cc: mpls@UU.NET 
Sent: Monday, July 23, 2001 5:42 PM
Subject: Re: Load Balancing algorithm


Ali Ghiansian,
             In generally the load balancing is done by constraint based
routing alogrithms,
             With different tie-breaking methods.It is an extension to the
SPF alogorithm,but
             routing of traffic has to be controlled on a percentage basis.
             Hope this helps.
             Regards,
             Abhay
 

Ali Ghiasian wrote: 
Hi allI am looking for available load balancing(for traffic engineering
purposes) algorithms for MPLS networks.Does any one know any refrence?Thanks
in advanceAli Ghiasian


From owner-mpls@UU.NET  Mon Jul 23 10:48: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 KAA25647
	for ; Mon, 23 Jul 2001 10:48: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 QQkyxv12282;
	Mon, 23 Jul 2001 14:49:42 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxv18188
	for mpls-outgoing; Mon, 23 Jul 2001 14:49: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 QQkyxv18165
	for ; Mon, 23 Jul 2001 14:49:00 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 QQkyxv07364
	for ; Mon, 23 Jul 2001 14:47:37 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkyxv07757
	for ; Mon, 23 Jul 2001 14:47:37 GMT
Message-ID: <3B5C3907.35106D7A@sandburst.com>
Date: Mon, 23 Jul 2001 10:47:35 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Manish Godara 
Cc: mpls@UU.NET
Subject: Re: [MPLS] Implicit Peering/Stack Attributes
References: <20010720230316.31745.qmail@web20106.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

Manish,

    Please see below.

You wrote:

> Hi,
>
> The Architecture document talks about implicit peering
> in Sections 3.27.5 and 4.3.  I understand the concept
> of implicit peering and that the "implicit peers"
> would distribute labels via "Stack Attributes".

>

Understanding this concept is quite a feat, since it is not
very well explained.

In essence, the 'stack attribute' referred to is a second
label in the stack.  Therefore, a 'stack attribute' would be
distributed using a 'label distribution protocol'. At this
time, the only label distribution protocol that appears to
allow distribution of label stacks (which is required if you
want to directly bind more than one label to a single FEC)
is that which is described in RFC 3107.  I do not know that
any implementation does this, however.

In order to accomplish the same thing using any other
label distribution protocol, you would need to distribute
'to me' labels and then distribute the labels corresponding
to 'stack attributes' by explicitly peering with a remote
LSR signaling entity.

As for the term 'implicit peering', I do not believe this is
intuitive to very many, or explicitly described anywhere.
In either the BGP MPLS (RFC 3107) case, or in any other
case, you have to have an explicit peering relationship in
order to obtain labels corresponding to 'stack attributes'.
Perhaps the authors meant that some type of peering is
implied by the existence of 'stack attribute' labels - thus
implicit peering.  Who knows?

--
Eric Gray

>
>
>
> But I don't find any reference in other documents to
> "Stack Attributes".
>
> Can someone please clarify how the Stack Attributes
> are distributed and where can I find more information?
>
> thanks in advance,
> manish
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/



From owner-mpls@UU.NET  Mon Jul 23 11:19: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 LAA28218
	for ; Mon, 23 Jul 2001 11:19:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkyxx00026;
	Mon, 23 Jul 2001 15:20:47 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxx12652
	for mpls-outgoing; Mon, 23 Jul 2001 15:20: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 QQkyxx12565
	for ; Mon, 23 Jul 2001 15:20:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkyxx24087
	for ; Mon, 23 Jul 2001 15:19:20 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 QQkyxx24847
	for ; Mon, 23 Jul 2001 15:19:19 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA29228 for mpls@uu.net; Mon, 23 Jul 2001 11:19: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 QQkyxx12452
	for ; Mon, 23 Jul 2001 15:18: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 QQkyxx16354
	for ; Mon, 23 Jul 2001 15:17:46 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQkyxx26529
	for ; Mon, 23 Jul 2001 15:17:45 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 LAA28032; Mon, 23 Jul 2001 11:17:45 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEC00027;
	Mon, 23 Jul 2001 11:17:43 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010723112214.026b2030@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 23 Jul 2001 11:23:00 -0400
To: "Kannan J" , mpls@UU.NET
From: "Thomas D. Nadeau" 
Subject: Re: Defining FEC types at the ingress...
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:39 PM 7/23/2001 +0000, Kannan J wrote:



>Hi
>
>The MPLS Architecture states that different types of
>FECs can be defined at an ingress to allow for both
>coarse grained and fine grained forwarding granularity.
>
>At present LDP supports only two types of FEC
>elements -  the host address and address prefix types.
>So even though we may define other types of FEC elements
>(e.g based on port no etc ) at the ingress it will not
>make sense to the LSRs downstream to the ingress as label
>exchange happens based only on the destination address
>prefix ( coarse forwarding granularity).
>
>However it does seem possible to achieve fine forwarding
>granularity through static configuration or via SNMP. For
>example the FTN MIB does have a provision to support FEC
>elements other than what LDP provides namely source address type ,  port 
>no etc and then map them to preconfigured LSPs thereby
>having the capability to map specific flows to specific LSPs.

         What if you are not only using LDP for FEC-NHLFE assignments?
For example, CLI->tunnel head or RSVP?

         --Tom





From owner-mpls@UU.NET  Mon Jul 23 11:28: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 LAA28792
	for ; Mon, 23 Jul 2001 11:28: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 QQkyxx09481;
	Mon, 23 Jul 2001 15:29:11 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxx14439
	for mpls-outgoing; Mon, 23 Jul 2001 15:28: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 QQkyxx14432
	for ; Mon, 23 Jul 2001 15:28: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 QQkyxx23614
	for ; Mon, 23 Jul 2001 15:25:46 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkyxx05639
	for ; Mon, 23 Jul 2001 15:25:46 GMT
Message-ID: <3B5C41F4.9DC6DBE4@sandburst.com>
Date: Mon, 23 Jul 2001 11:25:40 -0400
From: Eric Gray 
MIME-Version: 1.0
To: chetan.kumar@wipro.com
Cc: Gangadharan Ramakrishnan , mpls@UU.NET
Subject: Re: Question in Host Address FEC Element encoding
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Chetan S,

    Just to add to this, there may be some unclarity derived from the figure
itself.  It is a convention in ASCII art to represent a _potentially_ multi-word
field using multiple lines, even when the actual field may be one word or less.
The only solution to this inclarity is to become more familiar with ASCII art
in the IETF RFC process...

--
Eric Gray

You wrote:

> On Sun, 22 Jul 2001, Gangadharan Ramakrishnan wrote:
>
> > Hi,
> > I'm following the rfc3036(LDP Specification) for encoding and decoding of
> > LDP messages. I found a problem in the specification encoding the Host
> > Address FEC Element. The specification says that the PDU filed for Host Addr
> > is more than 32 bits in a diagram and it says it is an address encoded
> > according to the address family.
> >
> > I want to know the exact number of bytes/bits for this field. If it is an IP
>
> Hi,
> As mentioned in the RFC this depends on address family, = 32 for IPv4 and
> = 128 for IPv6
>
> Thanks
> Chetan S



From owner-mpls@UU.NET  Mon Jul 23 11:55: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 LAA01243
	for ; Mon, 23 Jul 2001 11:55: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 QQkyxz07121;
	Mon, 23 Jul 2001 15:55:57 GMT
Received: by mail-control.mail.uu.net 
	id QQkyxz17402
	for mpls-outgoing; Mon, 23 Jul 2001 15:55: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 QQkyxz17391
	for ; Mon, 23 Jul 2001 15:55:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkyxz18181
	for ; Mon, 23 Jul 2001 15:54:02 GMT
Received: from web14106.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14106.mail.yahoo.com [216.136.172.136])
	id QQkyxz15900
	for ; Mon, 23 Jul 2001 15:54:01 GMT
Message-ID: <20010723155401.2551.qmail@web14106.mail.yahoo.com>
Received: from [199.166.16.38] by web14106.mail.yahoo.com via HTTP; Mon, 23 Jul 2001 08:54:01 PDT
Date: Mon, 23 Jul 2001 08:54:01 -0700 (PDT)
From: LDP Hello 
Subject: Transport address   --- TCP SESSIONS  
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi ; My question is regarding the Transport address in the LDP hello
...

Is it reasonable for a router to add its ROUTER ID into the Transport
TLV of hello... 
consider 
                       b1 > a1, b2 > a2, b3 > a3 
       
      _______                       ________
     |LSR A  |a1 <---L1-------> b1 |LSR B   |
     |ID:a1  |a2 <---L2-------> b2 |  ID:b1 |
     |_______|a3 <---L3-------> b3 |________|
 
    
Say LSR A always send ITS routerID (a1)  as the transport TLV in Hello
instead of its Interface IP addresses... TCP session will be
established properly on LINK L1 

Now trasport Address in Hellos on L2 & L3 is a1 and LSR B will try to
establish TCP session with address a1 for interfaces b2 & b3 and that
will be through link L1 again ...   LINKS L2 & L3 will never be
utilized ... 

So my question is IS IT VALID/ACCEPTABLE to use ROUTER ID as the
TRANSPORT ADDRESS INSTEAD of INterface address ...???

Thanks ... 









__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Mon Jul 23 12:17:32 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 MAA03069
	for ; Mon, 23 Jul 2001 12:17: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 QQkyyb20951;
	Mon, 23 Jul 2001 16:18:23 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyb09313
	for mpls-outgoing; Mon, 23 Jul 2001 16:17: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 QQkyyb09305
	for ; Mon, 23 Jul 2001 16:17:40 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 QQkyyb06328
	for ; Mon, 23 Jul 2001 16:16:57 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkyyb28275
	for ; Mon, 23 Jul 2001 16:16:56 GMT
Message-ID: <3B5C4DF7.242A0F68@sandburst.com>
Date: Mon, 23 Jul 2001 12:16:55 -0400
From: Eric Gray 
MIME-Version: 1.0
To: chetan.kumar@wipro.com
Cc: mpls@UU.NET
Subject: Re: Next Hop Change..
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Chetan S,

    At least somebody reads my posts! :-)

    So, to address your comments: the DU, Independent control
mode is slightly strange in the case under discussion.  If an LSR
is 'comfortable' with distributing labels even though it may not
have labels for LSPs downstream (the essence of independent
control), then the ability to forward packets without labels to the
routing next hop is implied.

    This SHOULD be the case in such an implementation.  It is
not very likely that you will see DU distribution being used to
distribute labels for a FEC that the distributing LSR does not
know how to forward.  Also, merely doing so effectively breaks
routing in a sense similar to the 'MPLS framework' notion of an
MPLS node (an LSR with no unlabeled packet forwarding ability)
- such an LSR cannot have both outstanding route advertisements
and no LSP in effect for those advertisements since it does not
have 'reachability' if it does.

--
Eric Gray

You wrote:

> Hi Eric,
>
>         I was just going thro' the mailing archives, got into some
> confusing things. Please refer to the archives for this mail..
>
> http://cell.onecall.net/mhonarc/mpls/2001-May/msg00352.html
>
> U have mentioned that LSR need to withdraw the labels when operating in
> Ordered Control Mode..
>
> " d) if operating in ordered control mode, LSR-A would withdraw labels it
> has previously provided for FEC F to its peers - especially if
> it is not currently capable of establishing a new binding to a label
> issued by the new next hop; note that this will result in tearing down
> the LSP for FEC F fom each upstream peer all the way to however many
> ingress LSRs there are. "
>
> Now if refer to RFC, A.1.7,, page 115, NH.17. This statement is reached
> only when the LSR is in DoD OR the peer is in DoD. If operating in un
> solictated order control mode this statement is never reached.
>
> In a way I think ur explanation seems OK. If a LSR sends label mapping
> due the the fact that it is order control mode, then it *has* to withdraw
> the mapping. On the other hand if the mapping is sent from a independent
> control mode LSR, it need not withdraw the label.
>
> Any comments...
>
> Thanks
> Chetan S



From owner-mpls@UU.NET  Mon Jul 23 12:28: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 MAA04027
	for ; Mon, 23 Jul 2001 12:28:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkyyb22504;
	Mon, 23 Jul 2001 16:29:16 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyb10273
	for mpls-outgoing; Mon, 23 Jul 2001 16:28: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 QQkyyb10265
	for ; Mon, 23 Jul 2001 16:28: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 QQkyyb08607
	for ; Mon, 23 Jul 2001 16:25:02 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkyyb16689
	for ; Mon, 23 Jul 2001 16:25:02 GMT
Message-ID: <3B5C4FDD.DFCC3D38@sandburst.com>
Date: Mon, 23 Jul 2001 12:25:01 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Khuzema Pithewan 
Cc: "'mpls@uu.net'" ,
        "'David Charlap'" 
Subject: Re: Common label
References: <13D467F625FAD511AE2A00D0B7B917D71FF0EB@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Khuzema,

    You receive the labels you distribute.  If you distribute a common
label for two LSPs that have divergent paths downstream (implied
by a distinguishable ERO), then you will receive that label.  AT this
point, you cannot recover sufficient information to allow you to
correctly forward the packets received with this common label in
the dowstream LSP - assuming you even have established distinct
downstream LSPs to use in forwarding.

--
Eric Gray

You wrote:

> At LSR, If I am receiving a Resv message with a new filterspec(style is SE),
> with the same label(i.e. outgoing label) then it means LSP are already
> merged, so at this point  whether I check for ERO or not, doesn't matter,
> because ERO is for the downstream path from this LSR and I am allocating
> label for the upstream path(i.e. incoming label).
>
> If ERO is different for 2 LSP, then I will never receive the same label at
> this LSR, as the downstream LSR(at which LSP route is getting changed) will
> never send the same labels, as previous hops are different at the downstream
> LSR..
>
> Khuzema.
>
> > ----------
> > From:         David Charlap
> > Sent:         Monday, July 23, 2001 7:41 PM
> > To:   'mpls@uu.net'
> > Subject:      Re: Common label
> >
> > Khuzema Pithewan wrote:
> > >
> > > In "draft-ietf-mpls-rsvp-lsp-tunnel-08" section 2.4.3 says...
> > >
> > > " Multipoint-to-point LSPs may be used when path messages do not
> > > carry the EXPLICIT_ROUTE object, or when Path messages have
> > > identical EXPICIT_ROUTE objects.  In either of these cases a
> > > common label may be assigned."
> > >
> > > My question is, why it should check if EXPLICIT_ROUTE object should
> > > be same to provide common label? I think instead of checking
> > > EXPLICIT_ROUTE object, if I just check for the incoming and
> > > outgoing interfaces of the Path messages on the LSR, even then I
> > > can assign the common label if they are same.
> >
> > Think about what will happen on the data plane.  Remember that data
> > packets are forwarded only according to their labels, and not according
> > to the actual content of the packets.
> >
> > If you assign the same label to two different LSPs, then you effectively
> > merge them together.  Packets from both LSPs will necessarily follow the
> > same path to the egress, because they will have the same label.
> >
> > If there is no ERO, or if the two LSPs have identical EROs, this merging
> > is not a problem - the packets are all going the same way anyway.  If
> > they have different EROs, however, then the data from one LSP will not
> > be able to follow the ERO, because it is sharing a label with an LSP
> > that has a different ERO.
> >
> > -- David
> >



From owner-mpls@UU.NET  Mon Jul 23 12:29:32 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 MAA04141
	for ; Mon, 23 Jul 2001 12:29: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 QQkyyc08377;
	Mon, 23 Jul 2001 16:30:26 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyb10292
	for mpls-outgoing; Mon, 23 Jul 2001 16:28: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 QQkyyb10287
	for ; Mon, 23 Jul 2001 16:28:55 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkyyb19106
	for ; Mon, 23 Jul 2001 16:28:44 GMT
Received: from hebe.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns02.or.intel.com [134.134.248.4])
	id QQkyyb09811
	for ; Mon, 23 Jul 2001 16:28:43 GMT
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA02365;
	Mon, 23 Jul 2001 16:28:31 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 23 Jul 2001 16:28:31 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 23 Jul 2001 09:28:29 -0700
Message-ID: 
From: "Feng, Mark" 
To: "'David Charlap'" ,
        "'mpls@uu.net'"
	 
Subject: RE: Session Attributes
Date: Mon, 23 Jul 2001 09:28:28 -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

> >> ###  So you can't reroute the traffic for an FF style flow
> > 
> > If the receiver sends a Resv with SE style, it is still possible
> > to do "make-before-break". The new Path message would appear to be
> > from a different sender, since the LSP Id is changed. "Comparing",
> > if done, is implementation dependent.
> 
> It is possible to do make-before-break even with FF style.  The only
> catch is that resources will be temporarily wasted on those 
> nodes/links
> that the new and old LSPs have in common.  The reroute may 
> fail if there
> aren't enough resources to hold this temporary reservation.  But if
> there are sufficient resources, make-before-break will still work.
>

Though this is true, there might be a problem achieving a true
"make-before-break while working with different vendor's implementation. The
draft does not say what the expected behavior should be in FF style.

But I agree this is the logical way to do it:-). 

- Mark
 
> -- David
> 



From owner-mpls@UU.NET  Mon Jul 23 12:35:39 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 MAA04634
	for ; Mon, 23 Jul 2001 12:35: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 QQkyyc02509;
	Mon, 23 Jul 2001 16:36:31 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyc11358
	for mpls-outgoing; Mon, 23 Jul 2001 16:35: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 QQkyyc11346
	for ; Mon, 23 Jul 2001 16:35: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 QQkyyc10182
	for ; Mon, 23 Jul 2001 16:34:21 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 QQkyyc15558
	for ; Mon, 23 Jul 2001 16:34:21 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA00468;
	Mon, 23 Jul 2001 12:34:20 -0400 (EDT)
Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA24881; Mon, 23 Jul 2001 12:34:11 -0400 (EDT)
Message-Id: <200107231634.MAA24881@erosen-u10.cisco.com>
X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs
To: Ping Pan 
cc: mpls-list 
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] 
In-reply-to: Your message of Thu, 19 Jul 2001 18:15:14 -0700.
             <3B578622.BF781C3C@juniper.net> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 23 Jul 2001 12:34:10 -0400
From: Eric Rosen 
Sender: owner-mpls@UU.NET
Precedence: bulk


Having now been convinced of the  need to have the echo response travel back
along the path  of label distribution, piggybacking it  on the control plane
messages  does  seem  to  make  sense.   The alternative  is  to  devise  an
independent transport  method which follows the control  plane reverse path.
This  is probably  more complicated,  given that  we have  only  two control
planes.

So here's my  off-the-cuff suggestion for doing the same  kind of thing with
LDP.  

The LSP-ping message  should be able to carry an  echo object which contains
(a) an  identifier of  the ingress,  and (b) an  LDP FEC  TLV.  (And  also a
sequence number,  I think, to aid  in matching responses  to requests.)  The
LDP FEC  TLV is the one  corresponding to the  LSP on which the  LSP-ping is
being sent.

When the LSP-ping message reaches  the egress, the echo object is extracted,
and given to LDP to be treated as an attribute (TLV) of the FEC it contains.
The egress then  sends a label mapping message for  that FEC, containing the
echo object.  This should  be sent to each LDP peer to  which the egress has
previously distributed  a label  (most likely the  implicit NULL  label) for
that FEC.  The egress then forgets about the response TLV.

When a  label mapping  message for  a particular FEC  is received,  and that
message contains an echo response TLV, then:

- if the  mapping message is not  from the next  hop for that FEC,  the echo
  response TLV is ignored;

- if the mapping message IS from the next hop for that FEC, 

  * if the  LSR is not the ingress  node identified in the  echo object, the
    LSR  sends a label  mapping message  for that  FEC, containing  the echo
    object, to each LDP peer to  which it has previously distributed a label
    for that FEC  (except the one from which it  received this message); the
    LSR then forgets about the TLV. 

  * if the LSR is the ingress node identified in the echo object, it matches
    the echo object  up to a particular LSP-ping and  treats the LSP-ping as
    having been properly responded to.

This procedure  is little different than  the procedure used to  pass up the
MTU or path vector TLVs upstream.   As in the RSVP-TE scheme, if the control
plane is operating properly, the TLV will make it upstream properly. 

This works  fine in the  multipoint-to-point case, at  least as long  as one
isn't pinging an egress from several  ingresses at once.  To handle the case
where there  are multiple outstanding  pings (from different  ingresses), we
either need to allow multiple echo  TLVs in a mapping message, or perhaps we
only need to define which of several  echo TLVs is the one which gets passed
upstream.





From owner-mpls@UU.NET  Mon Jul 23 16:35: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 QAA21868
	for ; Mon, 23 Jul 2001 16:35: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 QQkyys12587;
	Mon, 23 Jul 2001 20:36:37 GMT
Received: by mail-control.mail.uu.net 
	id QQkyys24589
	for mpls-outgoing; Mon, 23 Jul 2001 20:36:06 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 QQkyys24540
	for ; Mon, 23 Jul 2001 20:35:57 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 QQkyys23067
	for ; Mon, 23 Jul 2001 20:32:10 GMT
Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQkyys15796
	for ; Mon, 23 Jul 2001 20:32:10 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6NKW9310538
	for ; Mon, 23 Jul 2001 16:32:09 -0400 (EDT)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 23 Jul 2001 16:32:09 -0400
Message-ID: 
From: "Jiang, Donghua (Donghua)" 
To: "'mpls@uu.net'" 
Subject: A question regarding RFC2205
Date: Mon, 23 Jul 2001 16:31:58 -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 all,

On page 19 of RFC2205, first paragraph, "The same interface may act in both
the incoming and outgoing roles for different data flows in the same
session."

It is understandable that an interface can act either in incoming role or in
outgoing role depending on the directions of data flows.  However, when the
data flows are in different directions, they should not be considered as "in
the same session".  Does the RFC mean two data flows, one direction each, in
two sessions, or two data flows, one direction each, in one session?

Regards,
Jane


From owner-mpls@UU.NET  Mon Jul 23 16:42: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 QAA22218
	for ; Mon, 23 Jul 2001 16:42: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 QQkyys21964;
	Mon, 23 Jul 2001 20:43:24 GMT
Received: by mail-control.mail.uu.net 
	id QQkyys25064
	for mpls-outgoing; Mon, 23 Jul 2001 20:42: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 QQkyys25054
	for ; Mon, 23 Jul 2001 20:42:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkyys27192
	for ; Mon, 23 Jul 2001 20:42:23 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f14.law10.hotmail.com [64.4.15.14])
	id QQkyys12368
	for ; Mon, 23 Jul 2001 20:42:22 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 23 Jul 2001 13:42:23 -0700
Received: from 62.0.96.103 by lw10fd.law10.hotmail.msn.com with HTTP;	Mon, 23 Jul 2001 20:42:23 GMT
X-Originating-IP: [62.0.96.103]
From: "Shawn H" 
To: mpls@UU.NET
Subject: Using tunnels in SPF computations
Date: Mon, 23 Jul 2001 20:42:23 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jul 2001 20:42:23.0291 (UTC) FILETIME=[F9BC88B0:01C113B7]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

what draft details the use of advertised tunnels by other routers in their 
IGP spf computation? I've seen this feature often termed FA-LSP; however, 
from the definition of FA-LSP I found in 
draft-ietf-mpls-lsp-hierarchy-02.txt, it only mentions using tunnels to 
setup other tunnels through them (by advertising them for CSPF computations, 
not SPF computations).
Can someone please clarify?

Thanks.

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



From owner-mpls@UU.NET  Mon Jul 23 16:55: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 QAA23014
	for ; Mon, 23 Jul 2001 16:55: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 QQkyyt02346;
	Mon, 23 Jul 2001 20:56:28 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyt26300
	for mpls-outgoing; Mon, 23 Jul 2001 20:55: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 QQkyyt26291
	for ; Mon, 23 Jul 2001 20:55:49 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 QQkyyt05667
	for ; Mon, 23 Jul 2001 20:55:03 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 QQkyyt07615
	for ; Mon, 23 Jul 2001 20:54:58 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02750
	for ; Mon, 23 Jul 2001 16:54:55 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14130
	for ; Mon, 23 Jul 2001 16:54:56 -0400 (EDT)
Message-ID: <3B5C8F3E.E6A487F5@marconi.com>
Date: Mon, 23 Jul 2001 16:55:26 -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: A question regarding RFC2205
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Jiang, Donghua (Donghua)" wrote:
> 
> On page 19 of RFC2205, first paragraph, "The same interface may act
> in both the incoming and outgoing roles for different data flows in
> the same session."
> 
> It is understandable that an interface can act either in incoming
> role or in outgoing role depending on the directions of data flows.
> However, when the data flows are in different directions, they
> should not be considered as "in the same session".  Does the RFC
> mean two data flows, one direction each, in two sessions, or two
> data flows, one direction each, in one session?

It means multiple data flows in one session, just as it says.

Think about multicast destination addresses and you should easily be
able to come up with some topologies where data for a single session may
flow in both directions over a single link.

This scenario can't happen with a unicast destination address, so it's
of little importance to someone using RSVP to signal MPLS.  But it is
quite important if RSVP is to be used as it was originally intended -
for making resource reservations over a hop-by-hop multicast network.

-- David


From owner-mpls@UU.NET  Mon Jul 23 17:55:00 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 RAA26698
	for ; Mon, 23 Jul 2001 17:54: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 QQkyyx08626;
	Mon, 23 Jul 2001 21:55:53 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyx21214
	for mpls-outgoing; Mon, 23 Jul 2001 21:55: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 QQkyyx21191
	for ; Mon, 23 Jul 2001 21:55:03 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 QQkyyx02726
	for ; Mon, 23 Jul 2001 21:54:03 GMT
Received: from hebe.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns02.or.intel.com [134.134.248.4])
	id QQkyyx06939
	for ; Mon, 23 Jul 2001 21:54:03 GMT
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA02674
	for ; Mon, 23 Jul 2001 21:54:02 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 23 Jul 2001 21:54:02 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 23 Jul 2001 14:54:01 -0700
Message-ID: 
From: "Feng, Mark" 
To: "'mpls@uu.net'" 
Subject: RE: A question regarding RFC2205
Date: Mon, 23 Jul 2001 14:53:20 -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

I have a similar question. 

RFC 2205 describes the usage of the SCOPE object. It seems that the object
is used for both multicast and unicast. In RFC 2209, it is only described
for multicast.

My question is, for unicast, can auto-refresh loop happen, i.e. is SCOPE
object needed for unicast?

Thanks in advance.

- Mark



From owner-mpls@UU.NET  Mon Jul 23 18:15: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 SAA27734
	for ; Mon, 23 Jul 2001 18:15: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 QQkyyz29125;
	Mon, 23 Jul 2001 22:16:54 GMT
Received: by mail-control.mail.uu.net 
	id QQkyyz12986
	for mpls-outgoing; Mon, 23 Jul 2001 22:16:22 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 QQkyyz12915
	for ; Mon, 23 Jul 2001 22:16: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 QQkyyy00074
	for ; Mon, 23 Jul 2001 22:14:25 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 QQkyyy26768
	for ; Mon, 23 Jul 2001 22:14: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 SAA09960
	for ; Mon, 23 Jul 2001 18:14: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 SAA07406
	for ; Mon, 23 Jul 2001 18:14:19 -0400 (EDT)
Message-ID: <3B5CA1D9.A26DB019@marconi.com>
Date: Mon, 23 Jul 2001 18:14:49 -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: A question regarding RFC2205
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Feng, Mark" wrote:
> 
> I have a similar question.
> 
> RFC 2205 describes the usage of the SCOPE object. It seems that the
> object is used for both multicast and unicast. In RFC 2209, it is
> only described for multicast.
> 
> My question is, for unicast, can auto-refresh loop happen, i.e. is
> SCOPE object needed for unicast?

This is well beyond the scope of MPLS (no pun intended.)  But I'll try
to answer anyway.

SCOPE only makes sense with WF style reservations and multicast.

With unicast flows, there is a clear sense of direction from sender(s)
to receiver.  Which means that Path and Resv messages will only flow in
one direction along any particular link.  Resv messages won't loop
because they will only flow along the back-path from the received Path
messages.

Similarly with SE and FF styles there is no issue.  With these styles,
the Resv contains a list of the senders that the Resv message must
arrive at.  (Part of the flow descriptor list).  With respect to any
particular sender, it is always known where the corresponding Path
message came from so there is no issue.

When WF style is used, however, the Resv message has no list of senders
in its flow descriptor.  (That's the whole point of WF style - to
"wildcard" in everybody.)  Therefore, an incoming Resv must be sent out
all interfaces that have received Path messages for the session.  If
there are multiple receivers in the session (ie. multicast), then it is
very possible for a router to receive the same Resv from multiple
places.  The SCOPE object serves to keep this tangled mess of Resv
messages from exploding into a datastorm.

If you try to use SCOPE on FF or SE reservations, I suspect many
implementations will reject the Resv message, even though it is a
theoretically valid (although useless) object in that situation.

Using SCOPE on a unicast WF-style reservation should probably work on
any router that supports WF-style reservations.  But as far as I can
tell, it will not be terribly useful.

-- David


From owner-mpls@UU.NET  Mon Jul 23 18:40: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 SMTP id SAA28637
	for ; Mon, 23 Jul 2001 18:40: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 QQkyza03055;
	Mon, 23 Jul 2001 22:41:40 GMT
Received: by mail-control.mail.uu.net 
	id QQkyza15498
	for mpls-outgoing; Mon, 23 Jul 2001 22:41: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 QQkyza15438
	for ; Mon, 23 Jul 2001 22:40:53 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 QQkyza12712
	for ; Mon, 23 Jul 2001 22:39:11 GMT
Received: from web14805.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14805.mail.yahoo.com [216.136.224.221])
	id QQkyza29676
	for ; Mon, 23 Jul 2001 22:39:10 GMT
Message-ID: <20010723223909.78071.qmail@web14805.mail.yahoo.com>
Received: from [216.174.224.251] by web14805.mail.yahoo.com via HTTP; Mon, 23 Jul 2001 15:39:09 PDT
Date: Mon, 23 Jul 2001 15:39:09 -0700 (PDT)
From: Vikas D 
Subject: Re: draft-ietf-mpls-lsp-hierarchy-02.txt  (or is it revision  3??)
To: Kireeti Kompella , mpls-ops@mplsrc.com, mpls@UU.NET,
        yakov@juniper.net
In-Reply-To: <200107222216.PAA12837@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Kireeti,

I am not sure if the requirement regarding L3 protocol ID to be same
holds true when the LSP egress is not same as FA egress.  The reason
is that as a "tunneling" LSP, the FA-LSP shall have to handle only
MPLS packets.  That is, packets for which the encapsulation type is
"MPLS Unicast".  FA-LSP does not need to look into the L3 protocol
header, and hence FA-LSP can be protocol agnostic.

The only time the nodes involved in FA-LSP need to look into the L3
header is when the FA-LSP egress is same as "tunneled" LSP egress.

- Vikas


--- Kireeti Kompella  wrote:
> Hi Vikas,
> 
> > In section 7.2, of the LSP hierarchy draft, a requirement for
> using
> > an already existing FA-LSP is:
> > 
> >    "the L3PID of the FA-LSP is compatible with the L3PID of
> >     the LSP being signaled".
> > 
> > Further, it also states :
> > 
> >   "The PHOP in the message is the address of the LSR at the
> >    head-end of the FA-LSP.  Before sending the Path/Request
> >    message, the ERO in that message is adjusted by removing
> >    the subsequence of the ERO that lies in the FA-LSP, and
> >    replacing it with just the end point of the FA-LSP."
> > 
> > I guess this requirement holds true ONLY if the egress node for
> the
> > tunneled LSP is same as the FA-LSP egress.  This does not hold
> true
> > when the (tunneled) LSP egress is beyond the region hosting the
> > (tunnelling) FA-LSP.
> 
> The requirement holds for any tunneled LSP, whether it terminates
> at the egress of the FA or goes beyond.
> 
> I'm not sure what role PHOP and ERO adjustment play here.
> 
> Kireeti.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Mon Jul 23 23:22: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 XAA10280
	for ; Mon, 23 Jul 2001 23:22: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 QQkyzt07155;
	Tue, 24 Jul 2001 03:23:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkyzt22727
	for mpls-outgoing; Tue, 24 Jul 2001 03:23: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 QQkyzt22719
	for ; Tue, 24 Jul 2001 03:22: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 QQkyzt07178
	for ; Tue, 24 Jul 2001 03:19:54 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 QQkyzt02668
	for ; Tue, 24 Jul 2001 03:19:52 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6O8wku03020
	for ; Tue, 24 Jul 2001 08:58:46 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GGYK7900.8BP; Tue, 24 Jul 2001 08:55:57 +0530 
Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id DAA31593; Tue, 24 Jul 2001 03:59:00 +0530
Date: Tue, 24 Jul 2001 08:56:33 +0530 (IST)
From: "chetan kumar s" 
X-Sender: chetansk@soflt.alc.wipinfo.soft.net
Reply-To: chetan.kumar@wipro.com
To: LDP Hello 
cc: mpls@UU.NET
Subject: Re: Transport address   --- TCP SESSIONS  
In-Reply-To: <20010723155401.2551.qmail@web14106.mail.yahoo.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 23 Jul 2001, LDP Hello wrote:

Hi,
	The fact that need to considered here is that, two LSR can have
multiple LDP hello adjecencies for a label space, but only *one* TCP
session(for a label space). Thus in ur case the links L2 & L3 *will* be
unutilized..

Thanks
Chetan S

> 
> Hi ; My question is regarding the Transport address in the LDP hello
> ...
> 
> Is it reasonable for a router to add its ROUTER ID into the Transport
> TLV of hello... 
> consider 
>                        b1 > a1, b2 > a2, b3 > a3 
>        
>       _______                       ________
>      |LSR A  |a1 <---L1-------> b1 |LSR B   |
>      |ID:a1  |a2 <---L2-------> b2 |  ID:b1 |
>      |_______|a3 <---L3-------> b3 |________|
>  
>     
> Say LSR A always send ITS routerID (a1)  as the transport TLV in Hello
> instead of its Interface IP addresses... TCP session will be
> established properly on LINK L1 
> 
> Now trasport Address in Hellos on L2 & L3 is a1 and LSR B will try to
> establish TCP session with address a1 for interfaces b2 & b3 and that
> will be through link L1 again ...   LINKS L2 & L3 will never be
> utilized ... 
> 
> So my question is IS IT VALID/ACCEPTABLE to use ROUTER ID as the
> TRANSPORT ADDRESS INSTEAD of INterface address ...???
> 
> Thanks ... 
> __________________________________________________ Do You Yahoo!? Make
> international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 



From owner-mpls@UU.NET  Mon Jul 23 23:27: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 XAA10310
	for ; Mon, 23 Jul 2001 23:27: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 QQkyzt23236;
	Tue, 24 Jul 2001 03:27:55 GMT
Received: by mail-control.mail.uu.net 
	id QQkyzt23189
	for mpls-outgoing; Tue, 24 Jul 2001 03:27: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 QQkyzt23150
	for ; Tue, 24 Jul 2001 03:27:04 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 QQkyzt09239
	for ; Tue, 24 Jul 2001 03:22:32 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQkyzt06072
	for ; Tue, 24 Jul 2001 03:22:30 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6O91Qu03704
	for ; Tue, 24 Jul 2001 09:01:26 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GGYKBO00.EDL; Tue, 24 Jul 2001 08:58:36 +0530 
Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id EAA31597; Tue, 24 Jul 2001 04:01:39 +0530
Date: Tue, 24 Jul 2001 08:59:12 +0530 (IST)
From: "chetan kumar s" 
X-Sender: chetansk@soflt.alc.wipinfo.soft.net
Reply-To: chetan.kumar@wipro.com
To: "Thomas D. Nadeau" 
cc: Kannan J , mpls@UU.NET
Subject: Re: Defining FEC types at the ingress...
In-Reply-To: <4.3.2.7.2.20010723112214.026b2030@bucket.cisco.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,


> >having the capability to map specific flows to specific LSPs.
>          What if you are not only using LDP for FEC-NHLFE assignments?
> For example, CLI->tunnel head or RSVP?

OR CR-LDP

Thanks
Chetan S
> 
>          --Tom
> 
> 
> 



From owner-mpls@UU.NET  Tue Jul 24 00:57: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 AAA12567
	for ; Tue, 24 Jul 2001 00:57: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 QQkyzz16537;
	Tue, 24 Jul 2001 04:58:38 GMT
Received: by mail-control.mail.uu.net 
	id QQkyzz22168
	for mpls-outgoing; Tue, 24 Jul 2001 04:58: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 QQkyzz22154
	for ; Tue, 24 Jul 2001 04:57:55 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 QQkyzz02781
	for ; Tue, 24 Jul 2001 04:54:54 GMT
Received: from mailhost.iitb.ac.in by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQkyzz12719
	for ; Tue, 24 Jul 2001 04:54:53 GMT
Received: (qmail 15651 invoked from network); 24 Jul 2001 04:48:40 -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; 24 Jul 2001 04:48:40 -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 KAA07576;
	Tue, 24 Jul 2001 10:24:58 +0530 (IST)
Received: from localhost (gabhijit@localhost)
	by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id KAA14527;
	Tue, 24 Jul 2001 10:30:41 +0530
X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs
Date: Tue, 24 Jul 2001 10:30:41 +0530 (IST)
From: Abhijit Gadgil 
To: chetan kumar s 
cc: LDP Hello , 
Subject: Re: Transport address   --- TCP SESSIONS  
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

cks>>
cks>> Hi ; My question is regarding the Transport address in the LDP hello
cks>> ...
cks>>
cks>> Is it reasonable for a router to add its ROUTER ID into the Transport
cks>> TLV of hello...
cks>> consider
cks>>                        b1 > a1, b2 > a2, b3 > a3
cks>>
cks>>       _______                       ________
cks>>      |LSR A  |a1 <---L1-------> b1 |LSR B   |
cks>>      |ID:a1  |a2 <---L2-------> b2 |  ID:b1 |
cks>>      |_______|a3 <---L3-------> b3 |________|
cks>>
cks>>
cks>> Say LSR A always send ITS routerID (a1)  as the transport TLV in Hello
cks>> instead of its Interface IP addresses... TCP session will be
cks>> established properly on LINK L1
cks>>
cks>> Now trasport Address in Hellos on L2 & L3 is a1 and LSR B will try to
cks>> establish TCP session with address a1 for interfaces b2 & b3 and that
cks>> will be through link L1 again ...   LINKS L2 & L3 will never be
cks>> utilized ...

Not necessarily they should go out of link L1. They may go out of link L2,
L3 (Perhaps what u r refering here is loopback router address - which
typically would be router id, but not necessarily.)  And it depends more
upon the implementation of the TCP/IP stack in Box A.

So the answer to the question below is Yes!

cks>> So my question is IS IT VALID/ACCEPTABLE to use ROUTER ID as the
cks>> TRANSPORT ADDRESS INSTEAD of INterface address ...???


-abhijit



From owner-mpls@UU.NET  Tue Jul 24 09:50:54 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 JAA17819
	for ; Tue, 24 Jul 2001 09:50:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzbj27475;
	Tue, 24 Jul 2001 13:51:42 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbj05018
	for mpls-outgoing; Tue, 24 Jul 2001 13:51: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 QQkzbj05001
	for ; Tue, 24 Jul 2001 13:50: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 QQkzbj08541
	for ; Tue, 24 Jul 2001 13:50:02 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 QQkzbj25039
	for ; Tue, 24 Jul 2001 13:50:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07283 for ; Tue, 24 Jul 2001 09:50:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27663 for mpls@uu.net; Tue, 24 Jul 2001 09:49:52 -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 QQkzac15294
	for ; Tue, 24 Jul 2001 05:32:43 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 QQkzac10252
	for ; Tue, 24 Jul 2001 05:31:11 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzac22339
	for ; Tue, 24 Jul 2001 05:31:08 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 24 Jul 2001 10:58:57 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71E6842@mailserver.netbrahma.com>
From: Manoj Agiwal 
To: "'mpls@uu.net'" 
Subject: TC_Prempt in RSVP_TE
Date: Tue, 24 Jul 2001 10:58:49 +0530
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 ,
         Draft says ,

   "If the requested bandwidth is available, but
   is in use by lower priority sessions, then lower priority sessions
   (beginning with the lowest priority) MAY be pre-empted to free the
   necessary bandwidth"

   What will happen to the label allocated for this LSP  ?

   What will happen to the reservations for this LSP at other nodes ?

    Will  preemption priority be used while Label allocation in case if
    the Label pool is exhausted .
    Or it is going to work only for bandwidth ?

Regards ,
Manoj



   
   



From owner-mpls@UU.NET  Tue Jul 24 09:52:20 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 JAA17894
	for ; Tue, 24 Jul 2001 09:52: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 QQkzbj23070;
	Tue, 24 Jul 2001 13:53:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbj05197
	for mpls-outgoing; Tue, 24 Jul 2001 13:52: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 QQkzbj05160
	for ; Tue, 24 Jul 2001 13:52: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 QQkzbj11141
	for ; Tue, 24 Jul 2001 13:51:14 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQkzbj20993
	for ; Tue, 24 Jul 2001 13:51:04 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07424 for ; Tue, 24 Jul 2001 09:51:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27678 for mpls@uu.net; Tue, 24 Jul 2001 09:50:53 -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 QQkzat27510
	for ; Tue, 24 Jul 2001 09:58: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 QQkzat06360
	for ; Tue, 24 Jul 2001 09:56:19 GMT
Received: from hd1.vsnl.net.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hd1.vsnl.net.in [202.54.30.1])
	id QQkzat26918
	for ; Tue, 24 Jul 2001 09:56:15 GMT
Received: from linux ([210.212.215.210])
	by hd1.vsnl.net.in (8.8.8/8.8.8) with SMTP id PAA16106
	for ; Tue, 24 Jul 2001 15:26:56 +0530 (IST)
From: Srinivas Reddy 
Reply-To: lsreddy@trinc.com
Organization: ROC
To: mpls@UU.NET
Subject: penultimate hop poping
Date: Tue, 24 Jul 2001 20:49:28 +0530
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <01072420492800.19202@linux>
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear all,

	as per rfc3031 under section 3.16. 
1)Initial LDP negotiations MUST allow each LSR to determine whether its 
neighbouring LSRS are capable of poping the label stack.

how can we(egress) determine that our neighbour has the capability of poping 
the stack.

2)A LSR MUST NOT Request a label distribution peer to pop the label stack 
unless it is capable of doing so.
	is it possible that a LSR will not support the label stack poping.

and under section 4.1.5 (rfc3031)
LSR Rd distributes a binding between Implicit NULL and an address prefix X to 
LSR Ru if and only if :
	1. the rules os -----------
	2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it can pop the 
label stack) ...
how can Rd (egress) knows that  Ru has support of poping of stack. or is it a 
MUST that each LSR should support penultimate hop poing.

please calrify ,me about this.
thanks in adv.
regards
lonka



From owner-mpls@UU.NET  Tue Jul 24 10:10: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 KAA18994
	for ; Tue, 24 Jul 2001 10:10: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 QQkzbk13212;
	Tue, 24 Jul 2001 14:11:49 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbk27448
	for mpls-outgoing; Tue, 24 Jul 2001 14:11: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 QQkzbk27307
	for ; Tue, 24 Jul 2001 14:11:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzbk25116
	for ; Tue, 24 Jul 2001 14:08:20 GMT
Received: from ws9.cdotb.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.41.72.121])
	id QQkzbk09360
	for ; Tue, 24 Jul 2001 14:08:05 GMT
Received: from jnana.cdotb.ernet.in (jnana.cdotb.ernet.in [192.168.51.201])
	by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id TAA01918
	for ; Tue, 24 Jul 2001 19:27:16 +0500 (GMT+0500)
Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/28Nov00-1214PM)
	id RAA0000010731; Tue, 24 Jul 2001 17:11:14 +0500 (GMT+0500)
Message-ID: <3B5D61DB.E366FBB@cdotb.ernet.in>
Date: Tue, 24 Jul 2001 17:24:03 +0530
From: "N.Suresh" 
Organization: C-DoT
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Test Message
Content-Type: multipart/alternative;
 boundary="------------C82089F678A1E7F2E62BFF54"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------C82089F678A1E7F2E62BFF54
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Test message

--
!============================================================================!
= Suresh N., Research Engineer, C-DoT, Bangalore.                            =
= Call me at : OFF: 2383951(Dir) / 2263399 (268)                             =
=              RES: 3334248  MOBILE: 98441 77782                             =
= Alternate email :  nsur_mys@email.com                                      =
= QOT: For fast-acting relief, try slowing down.
!============================================================================!



--------------C82089F678A1E7F2E62BFF54
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Test message

-- 
!============================================================================!
= Suresh N., Research Engineer, C-DoT, Bangalore.                            =
= Call me at : OFF: 2383951(Dir) / 2263399 (268)                             =
=              RES: 3334248  MOBILE: 98441 77782                             =
= Alternate email :  nsur_mys@email.com                                      =
= QOT: For fast-acting relief, try slowing down.
!============================================================================!

 

--------------C82089F678A1E7F2E62BFF54--



From owner-mpls@UU.NET  Tue Jul 24 11:16:34 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 LAA23954
	for ; Tue, 24 Jul 2001 11:16: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 QQkzbp04375;
	Tue, 24 Jul 2001 15:17:29 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbp23527
	for mpls-outgoing; Tue, 24 Jul 2001 15:16: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 QQkzbp23498
	for ; Tue, 24 Jul 2001 15:16: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 QQkzbp29849
	for ; Tue, 24 Jul 2001 15:15:55 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzbp18536
	for ; Tue, 24 Jul 2001 15:15:55 GMT
Message-ID: <3B5D912A.3D735114@sandburst.com>
Date: Tue, 24 Jul 2001 11:15:54 -0400
From: Eric Gray 
MIME-Version: 1.0
To: lsreddy@trinc.com
Cc: mpls@UU.NET
Subject: Re: penultimate hop poping
References: <01072420492800.19202@linux>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lonka,

    In general, PPP and Ethernet MPLS implementations SHOULD be able
to support PHP and ATM/FR implementations MAY be able to support
PHP (using a 'default' VC corresponding to forwarding to the nexthop
routing instance).  Currently the only indication that an LSR MAY get
that a peer does not support PHP is if that LSR consistently rejects (by
sending a Label Release message, for example) any attempt to distribute
an IMPLICIT NULL label.

    Clearly there will be some interoperation friction between an LSR that
does not support PHP and a neighboring LSR that is learning impaired.
The scenario in which the downstream keeps giving IMPLICIT NULL is
avoided if the upstream peer asks for a new label, and waits for a Label
Mapping message (again, for example), before releasing the IMPLICIT
NULL label it has received.

    Of course, some implementations may so far depend on PHP that they
will give the IMPLICIT NULL label again in this case - even though this
is a clear violation of the specification.

--
Eric Gray

You wrote:

> Dear all,
>
>         as per rfc3031 under section 3.16.
> 1)Initial LDP negotiations MUST allow each LSR to determine whether its
> neighbouring LSRS are capable of poping the label stack.
>
> how can we(egress) determine that our neighbour has the capability of poping
> the stack.
>
> 2)A LSR MUST NOT Request a label distribution peer to pop the label stack
> unless it is capable of doing so.
>         is it possible that a LSR will not support the label stack poping.
>
> and under section 4.1.5 (rfc3031)
> LSR Rd distributes a binding between Implicit NULL and an address prefix X to
> LSR Ru if and only if :
>         1. the rules os -----------
>         2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it can pop the
> label stack) ...
> how can Rd (egress) knows that  Ru has support of poping of stack. or is it a
> MUST that each LSR should support penultimate hop poing.
>
> please calrify ,me about this.
> thanks in adv.
> regards
> lonka



From owner-mpls@UU.NET  Tue Jul 24 11:22: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 LAA24326
	for ; Tue, 24 Jul 2001 11:22: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 QQkzbp12960;
	Tue, 24 Jul 2001 15:22:59 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbp24389
	for mpls-outgoing; Tue, 24 Jul 2001 15:22: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 QQkzbp24347
	for ; Tue, 24 Jul 2001 15:22:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzbp24505
	for ; Tue, 24 Jul 2001 15:20:49 GMT
Received: from zcars0m9.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.129.242.157])
	id QQkzbp08321
	for ; Tue, 24 Jul 2001 15:20:49 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 f6OFKS905186
	for ; Tue, 24 Jul 2001 11:20:28 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 24 Jul 2001 11:20:23 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 24 Jul 2001 11:20:25 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD34165C96@zcard0ka.ca.nortel.com>
From: "David Allan" 
To: erosen@cisco.com
Cc: mpls-list , Ping Pan 
Subject: RE: [I-D ACTION:draft-pan-lsp-ping-00.txt]
Date: Tue, 24 Jul 2001 11:20:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11454.27EA7610"
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_01C11454.27EA7610
Content-Type: text/plain;
	charset="iso-8859-1"

Eric:

I do agree that a useful OAM echo request contains an identifier of the
ingress (level specific), some form of correlation I.D. (for matching
responses) and a means of identifying the specific LSP (or as you note for
LDP, the LSP's raison d'etre). Your "off the cuff" description requires the
sort of flexibility we believe any useful OAM messaging solution will
require and incorporated into our OAM messaging draft
(draft-azad-mpls-oam-messaging). 

However, I am not a fan of a hop-by-hop return along the control path. To
date we've have seen an interesting menagerie of OAM return paths:
	- each LSP inherently has a reverse NHLFE mapping (the reverse
notification tree approach/chang).
	- each LSP has an ingress IP address carried in the OAM messaging
(ping, bonica) which maps to either control or 
	payload level return.
IMHO all these approaches have questionable scaling, and/or limited
applicability.

I'd like to suggest that the most useful/scalable return path definition
fits squarely between the two approaches brought forward to date. OAM
messaging carries an ingress identifier that the recipient can map to an FEC
and hence to user plane connectivity back to the ingress. I can envision
scenarios where depending on a robust control plane has advantages once a
suspected problem is being escalated, but as a first line of defence, it
will fall over very quickly.

cheers
Dave

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Monday, July 23, 2001 12:34 PM
To: Ping Pan
Cc: mpls-list
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]



Having now been convinced of the  need to have the echo response travel back
along the path  of label distribution, piggybacking it  on the control plane
messages  does  seem  to  make  sense.   The alternative  is  to  devise  an
independent transport  method which follows the control  plane reverse path.
This  is probably  more complicated,  given that  we have  only  two control
planes.

So here's my  off-the-cuff suggestion for doing the same  kind of thing with
LDP.  

The LSP-ping message  should be able to carry an  echo object which contains
(a) an  identifier of  the ingress,  and (b) an  LDP FEC  TLV.  (And  also a
sequence number,  I think, to aid  in matching responses  to requests.)  The
LDP FEC  TLV is the one  corresponding to the  LSP on which the  LSP-ping is
being sent.

When the LSP-ping message reaches  the egress, the echo object is extracted,
and given to LDP to be treated as an attribute (TLV) of the FEC it contains.
The egress then  sends a label mapping message for  that FEC, containing the
echo object.  This should  be sent to each LDP peer to  which the egress has
previously distributed  a label  (most likely the  implicit NULL  label) for
that FEC.  The egress then forgets about the response TLV.

When a  label mapping  message for  a particular FEC  is received,  and that
message contains an echo response TLV, then:

- if the  mapping message is not  from the next  hop for that FEC,  the echo
  response TLV is ignored;

- if the mapping message IS from the next hop for that FEC, 

  * if the  LSR is not the ingress  node identified in the  echo object, the
    LSR  sends a label  mapping message  for that  FEC, containing  the echo
    object, to each LDP peer to  which it has previously distributed a label
    for that FEC  (except the one from which it  received this message); the
    LSR then forgets about the TLV. 

  * if the LSR is the ingress node identified in the echo object, it matches
    the echo object  up to a particular LSP-ping and  treats the LSP-ping as
    having been properly responded to.

This procedure  is little different than  the procedure used to  pass up the
MTU or path vector TLVs upstream.   As in the RSVP-TE scheme, if the control
plane is operating properly, the TLV will make it upstream properly. 

This works  fine in the  multipoint-to-point case, at  least as long  as one
isn't pinging an egress from several  ingresses at once.  To handle the case
where there  are multiple outstanding  pings (from different  ingresses), we
either need to allow multiple echo  TLVs in a mapping message, or perhaps we
only need to define which of several  echo TLVs is the one which gets passed
upstream.




------_=_NextPart_001_01C11454.27EA7610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [I-D ACTION:draft-pan-lsp-ping-00.txt]




Eric:




I do agree that a useful OAM echo request contains an =
identifier of the ingress (level specific), some form of correlation =
I.D. (for matching responses) and a means of identifying the specific =
LSP (or as you note for LDP, the LSP's raison d'etre). Your "off =
the cuff" description requires the sort of flexibility we believe =
any useful OAM messaging solution will require and incorporated into =
our OAM messaging draft (draft-azad-mpls-oam-messaging). 



However, I am not a fan of a hop-by-hop return along =
the control path. To date we've have seen an interesting menagerie of =
OAM return paths:



        - each LSP =
inherently has a reverse NHLFE mapping (the reverse notification tree =
approach/chang).

        - each =
LSP has an ingress IP address carried in the OAM messaging (ping, =
bonica) which maps to either control or 



        payload =
level return.

IMHO all these approaches have questionable scaling, =
and/or limited applicability.




I'd like to suggest that the most useful/scalable =
return path definition fits squarely between the two approaches brought =
forward to date. OAM messaging carries an ingress identifier that the =
recipient can map to an FEC and hence to user plane connectivity back =
to the ingress. I can envision scenarios where depending on a robust =
control plane has advantages once a suspected problem is being =
escalated, but as a first line of defence, it will fall over very =
quickly.



cheers

Dave




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

From: Eric Rosen [mailto:erosen@cisco.com]

Sent: Monday, July 23, 2001 12:34 PM

To: Ping Pan

Cc: mpls-list

Subject: Re: [Fwd: I-D =
ACTION:draft-pan-lsp-ping-00.txt]








Having now been convinced of the  need to have =
the echo response travel back

along the path  of label distribution, =
piggybacking it  on the control plane

messages  does  seem  to  =
make  sense.   The alternative  is  to  =
devise  an

independent transport  method which follows the =
control  plane reverse path.

This  is probably  more complicated,  =
given that  we have  only  two control

planes.




So here's my  off-the-cuff suggestion for doing =
the same  kind of thing with

LDP.  




The LSP-ping message  should be able to carry =
an  echo object which contains

(a) an  identifier of  the ingress,  =
and (b) an  LDP FEC  TLV.  (And  also a

sequence number,  I think, to aid  in =
matching responses  to requests.)  The

LDP FEC  TLV is the one  corresponding to =
the  LSP on which the  LSP-ping is

being sent.




When the LSP-ping message reaches  the egress, =
the echo object is extracted,

and given to LDP to be treated as an attribute (TLV) =
of the FEC it contains.

The egress then  sends a label mapping message =
for  that FEC, containing the

echo object.  This should  be sent to each =
LDP peer to  which the egress has

previously distributed  a label  (most =
likely the  implicit NULL  label) for

that FEC.  The egress then forgets about the =
response TLV.




When a  label mapping  message for  a =
particular FEC  is received,  and that

message contains an echo response TLV, then:




- if the  mapping message is not  from the =
next  hop for that FEC,  the echo

  response TLV is ignored;




- if the mapping message IS from the next hop for =
that FEC, 




  * if the  LSR is not the ingress  =
node identified in the  echo object, the

    LSR  sends a label  =
mapping message  for that  FEC, containing  the =
echo

    object, to each LDP peer to  =
which it has previously distributed a label

    for that FEC  (except the =
one from which it  received this message); the

    LSR then forgets about the TLV. =





  * if the LSR is the ingress node identified in =
the echo object, it matches

    the echo object  up to a =
particular LSP-ping and  treats the LSP-ping as

    having been properly responded =
to.




This procedure  is little different than  =
the procedure used to  pass up the

MTU or path vector TLVs upstream.   As in =
the RSVP-TE scheme, if the control

plane is operating properly, the TLV will make it =
upstream properly. 




This works  fine in the  =
multipoint-to-point case, at  least as long  as one

isn't pinging an egress from several  ingresses =
at once.  To handle the case

where there  are multiple outstanding  =
pings (from different  ingresses), we

either need to allow multiple echo  TLVs in a =
mapping message, or perhaps we

only need to define which of several  echo TLVs =
is the one which gets passed

upstream.









------_=_NextPart_001_01C11454.27EA7610--


From owner-mpls@UU.NET  Tue Jul 24 11:48:32 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 LAA26207
	for ; Tue, 24 Jul 2001 11:48: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 QQkzbr24402;
	Tue, 24 Jul 2001 15:49:26 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbr27510
	for mpls-outgoing; Tue, 24 Jul 2001 15:48:48 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 QQkzbr27458
	for ; Tue, 24 Jul 2001 15:48: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 QQkzbr16040
	for ; Tue, 24 Jul 2001 15:48:26 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 QQkzbr26014
	for ; Tue, 24 Jul 2001 15:48:26 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 LAA04848
	for ; Tue, 24 Jul 2001 11:45:55 -0400 (EDT)
Subject: RSVP message sequence
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: 
From: "Hong Liao" 
Date: Tue, 24 Jul 2001 11:45:09 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 07/24/2001 11:45:10 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I found that some switch sent out Path message not following the sequence
of the message format in the spec, I was wondering if rsvp message has to
follow the sequence of the spec or not.

Thanks in an advance.

Julia




From owner-mpls@UU.NET  Tue Jul 24 11:50:17 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 LAA26358
	for ; Tue, 24 Jul 2001 11:50:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzbr01376;
	Tue, 24 Jul 2001 15:51:12 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbr27863
	for mpls-outgoing; Tue, 24 Jul 2001 15:50: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 QQkzbr27688
	for ; Tue, 24 Jul 2001 15:49:36 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 QQkzbr15489
	for ; Tue, 24 Jul 2001 15:47:59 GMT
Received: from crag.netrotech.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: user-112v9a2.biz.mindspring.com [66.47.165.66])
	id QQkzbr26889
	for ; Tue, 24 Jul 2001 15:47:59 GMT
Received: (from jmuston@localhost)
	by crag.netrotech.com (8.9.3/8.9.3/Debian 8.9.3-21) id LAA17550
	for mpls@uu.net; Tue, 24 Jul 2001 11:03:23 -0500
From: John Muston 
Date: Tue, 24 Jul 2001 11:03:22 -0500
To: mpls@UU.NET
Subject: TE Mib, tunnel interfaces, ifstack layering?
Message-ID: <20010724110322.A17502@netrotech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-mpls@UU.NET
Precedence: bulk

In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
stack is shown as:

        +------------------------------------------------+
        | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
        +------------------------------------------------+
        |        MPLS-interface ifType = mpls(166)       |
        +------------------------------------------------+
        |               Underlying Layer                 |
        +------------------------------------------------+

It is not clear to me how the particular lower layer of the tunnel
interface is chosen.

In the case of a tunnel interface created but not yet signalled, I
imagine it would be layered over nothing (ifindex 0).

Once signalled, would it be the mplsOutSegmentIfIndex of the
tunnel's underlying cross connect?

If so, I assume a rerouted tunnel, since it might have a different egress
interface, might need to be restacked onto a different interface.

Should a tunnel also be layered over the mplsInSegmentIfIndex (if
nonzero)?



From owner-mpls@UU.NET  Tue Jul 24 12:16: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 MAA28403
	for ; Tue, 24 Jul 2001 12:16: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 QQkzbt14105;
	Tue, 24 Jul 2001 16:17:15 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbt20276
	for mpls-outgoing; Tue, 24 Jul 2001 16:16: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 QQkzbt20255
	for ; Tue, 24 Jul 2001 16:16:27 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 QQkzbs14262
	for ; Tue, 24 Jul 2001 16:14:25 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 QQkzbs05615
	for ; Tue, 24 Jul 2001 16:14:24 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25724 for ; Tue, 24 Jul 2001 12:14:24 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28296 for mpls@uu.net; Tue, 24 Jul 2001 12:14:13 -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 QQkzbq26431
	for ; Tue, 24 Jul 2001 15:42: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 QQkzbq21994
	for ; Tue, 24 Jul 2001 15:38:15 GMT
Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tlvsdy.vim.tlt.alcatel.it [194.243.74.244])
	id QQkzbq05580
	for ; Tue, 24 Jul 2001 15:38:14 GMT
Received: from tlvhdk.netit.alcatel.it (tlvhgd.netit.alcatel.it [151.98.14.48])
	by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id RAA07304
	for ; Tue, 24 Jul 2001 17:38:55 +0200 (MET DST)
Received: from alcatel.it (ipt010.tndl.alcatel.it [151.98.36.75])
	by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA12569
	for ; Tue, 24 Jul 2001 17:33:44 +0200 (METDST)
Message-ID: <3B5D9661.AD7E6243@alcatel.it>
Date: Tue, 24 Jul 2001 17:38:09 +0200
From: Roberto Guglielmi 
Organization: Alcatel - IP R&D
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Question about FTN MIB
Content-Type: multipart/mixed;
 boundary="------------C593427DA7CF630DA3F6AE23"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------C593427DA7CF630DA3F6AE23
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

draft-ietf-mpls-ftn-mib-00 staes that the object "mplsFTNActionPointer"
in table "mplsFTNEntry", if "mplsFTNActionType" is redirectLsp(2),
indicates the instance of mplsXCEntry for the LSP to redirect matching
packets to. What's the format of such an object? Is the value
"1.3.6.1.3.96.1.9.1.mplsXCIndex", where mplsXCIndex is in the range
1..2147483647, correct?

Thanks in advance,
Roberto

--------------C593427DA7CF630DA3F6AE23
Content-Type: text/x-vcard; charset=us-ascii;
 name="roberto.guglielmi.vcf"
Content-Description: Card for Roberto Guglielmi
Content-Disposition: attachment;
 filename="roberto.guglielmi.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Guglielmi;Roberto
tel;fax:+39 039 686 3590
tel;work:+39 039 686 4801
x-mozilla-html:FALSE
org:Alcatel Italy;IP Laboratory
adr:;;;;;;
version:2.1
email;internet:roberto.guglielmi@alcatel.it
title:SW Designer
fn:Roberto Guglielmi
end:vcard

--------------C593427DA7CF630DA3F6AE23--



From owner-mpls@UU.NET  Tue Jul 24 12:53: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 MAA01525
	for ; Tue, 24 Jul 2001 12:53: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 QQkzbv10656;
	Tue, 24 Jul 2001 16:54:43 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbv23520
	for mpls-outgoing; Tue, 24 Jul 2001 16:54: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 QQkzbv23515
	for ; Tue, 24 Jul 2001 16:54: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 QQkzbv18337
	for ; Tue, 24 Jul 2001 16:47:56 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 QQkzbv09116
	for ; Tue, 24 Jul 2001 16:47:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA03392 for mpls@uu.net; Tue, 24 Jul 2001 12:47:55 -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 QQkzbv23083
	for ; Tue, 24 Jul 2001 16:47: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 QQkzbv15820
	for ; Tue, 24 Jul 2001 16:45:27 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQkzbv29703
	for ; Tue, 24 Jul 2001 16:45:27 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6OGjQH25677
	for ; Tue, 24 Jul 2001 09:45:27 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B5DA621.94049F61@juniper.net>
Date: Tue, 24 Jul 2001 09:45:21 -0700
From: Ping Pan 
Organization: Juniper Networks
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls-list 
Subject: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Content-Type: multipart/mixed;
 boundary="------------B823042BD35FD3AFCF19A877"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------B823042BD35FD3AFCF19A877
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Here is an updated version on draft, Graceful Restart Mechanism for
RSVP-TE. We believe that this is useful and important for LSR failure
recovery. We have explained further on the use of Restart-Time and
Recovery-Time in this revision.

Thanks!

- Ping
--------------B823042BD35FD3AFCF19A877
Content-Type: message/rfc822
Content-Disposition: inline

Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA14008;
	Tue, 24 Jul 2001 10:35:59 -0400 (EDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA19920;
	Tue, 24 Jul 2001 10:35:56 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA15135
	for ietf-123-outbound.06@ietf.org; Tue, 24 Jul 2001 09:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12678
	for ; Tue, 24 Jul 2001 06:30:07 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06010
	for ; Tue, 24 Jul 2001 06:30:07 -0400 (EDT)
Message-Id: <200107241030.GAA06010@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;;:;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-pan-rsvp-te-restart-01.txt
Date: Tue, 24 Jul 2001 06:30:07 -0400
Sender: nsyracus@cnri.reston.va.us
X-Mozilla-Status2: 00000000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Graceful Restart Mechanism for RSVP-TE
	Author(s)	: P. Pan et al.
	Filename	: draft-pan-rsvp-te-restart-01.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by LSR's control plane
restart, and specifically by the restart of its RSVP-TE component, on
LSRs that are capable of preserving the MPLS forwarding component
across the restart.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pan-rsvp-te-restart-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pan-rsvp-te-restart-01.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pan-rsvp-te-restart-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010723140528.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pan-rsvp-te-restart-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pan-rsvp-te-restart-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010723140528.I-D@ietf.org>

--OtherAccess--

--NextPart--


--------------B823042BD35FD3AFCF19A877--



From owner-mpls@UU.NET  Tue Jul 24 13:26: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 NAA04201
	for ; Tue, 24 Jul 2001 13:26: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 QQkzbx27988;
	Tue, 24 Jul 2001 17:27:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbx15945
	for mpls-outgoing; Tue, 24 Jul 2001 17:26: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 QQkzbx15940
	for ; Tue, 24 Jul 2001 17:26:35 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 QQkzbx24042
	for ; Tue, 24 Jul 2001 17:25:35 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 QQkzbx26056
	for ; Tue, 24 Jul 2001 17:25:35 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 NAA17362
	for ; Tue, 24 Jul 2001 13:25:33 -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 NAA22918
	for ; Tue, 24 Jul 2001 13:25:34 -0400 (EDT)
Message-ID: <3B5DAFAE.7021575E@marconi.com>
Date: Tue, 24 Jul 2001 13:26:06 -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 message sequence
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 found that some switch sent out Path message not following the
> sequence of the message format in the spec, I was wondering if rsvp
> message has to follow the sequence of the spec or not.

Be liberal in what you accept.  Be conservative in what you send.

RFC 2205 describes certain specific ordering requirements.  Anything
that is different from the BNF, but not in violation of the stated
ordering requirements should be accepted.  Anything that violates the
stated ordering requirements should be rejected.

When your router generates the corresponding Path message, however, you
should send out the objects in the recommended order.

-- David


From owner-mpls@UU.NET  Tue Jul 24 13:37: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 SMTP id NAA05056
	for ; Tue, 24 Jul 2001 13:37: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 QQkzby14363;
	Tue, 24 Jul 2001 17:38:35 GMT
Received: by mail-control.mail.uu.net 
	id QQkzby16827
	for mpls-outgoing; Tue, 24 Jul 2001 17:38: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 QQkzby16809
	for ; Tue, 24 Jul 2001 17:37:55 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 QQkzby02463
	for ; Tue, 24 Jul 2001 17:37:22 GMT
Received: from ganymede.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns01.or.intel.com [134.134.248.3])
	id QQkzby02918
	for ; Tue, 24 Jul 2001 17:37:21 GMT
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA00423;
	Tue, 24 Jul 2001 17:37:11 GMT
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 24 Jul 2001 17:37:11 0000 (GMT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 24 Jul 2001 10:37:10 -0700
Message-ID: 
From: "Feng, Mark" 
To: "'Manoj Agiwal'" , "'mpls@uu.net'" 
Subject: RE: TC_Prempt in RSVP_TE
Date: Tue, 24 Jul 2001 10:37:06 -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

> -----Original Message-----
> From: Manoj Agiwal [mailto:ManojA@netbrahma.com]
> Sent: Monday, July 23, 2001 10:29 PM
> To: 'mpls@uu.net'
> Subject: TC_Prempt in RSVP_TE
> 
> 
> Hi ,
>          Draft says ,
> 
>    "If the requested bandwidth is available, but
>    is in use by lower priority sessions, then lower priority sessions
>    (beginning with the lowest priority) MAY be pre-empted to free the
>    necessary bandwidth"
> 
>    What will happen to the label allocated for this LSP  ?
>

Implementation dependent.
 
>    What will happen to the reservations for this LSP at other nodes ?
>

IMO, nothing. The node where the pre-emption occurs sends out
PathErr/ResvErr. Other nodes either forward the message, or process it; but
the reservation should still be intact. In other words, no action is taken
until the point the edge router receives the error.
 
>     Will  preemption priority be used while Label allocation 
> in case if
>     the Label pool is exhausted .
>     Or it is going to work only for bandwidth ?
>

IMO, it is implementation dependent.
 
> Regards ,
> Manoj
> 
> 
> 
>    
>    
> 
> 



From owner-mpls@UU.NET  Tue Jul 24 13:56:25 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 NAA06588
	for ; Tue, 24 Jul 2001 13:56: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 QQkzbz25121;
	Tue, 24 Jul 2001 17:57:20 GMT
Received: by mail-control.mail.uu.net 
	id QQkzbz18670
	for mpls-outgoing; Tue, 24 Jul 2001 17:56: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 QQkzbz18657
	for ; Tue, 24 Jul 2001 17:56: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 QQkzbz11080
	for ; Tue, 24 Jul 2001 17:56:34 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 QQkzbz07730
	for ; Tue, 24 Jul 2001 17:56:34 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA10330 for mpls@uu.net; Tue, 24 Jul 2001 13:56: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 QQkzbz18607
	for ; Tue, 24 Jul 2001 17:55: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 QQkzbz28864
	for ; Tue, 24 Jul 2001 17:54:23 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 QQkzbz04747
	for ; Tue, 24 Jul 2001 17:54:22 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 NAA09801; Tue, 24 Jul 2001 13:54:22 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AED05357;
	Tue, 24 Jul 2001 13:54:21 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010724135013.0285c180@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Jul 2001 13:59:43 -0400
To: Roberto Guglielmi , mpls@UU.NET
From: "Thomas D. Nadeau" 
Subject: Re: Question about FTN MIB
In-Reply-To: <3B5D9661.AD7E6243@alcatel.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>draft-ietf-mpls-ftn-mib-00 staes that the object "mplsFTNActionPointer"
>in table "mplsFTNEntry", if "mplsFTNActionType" is redirectLsp(2),
>indicates the instance of mplsXCEntry for the LSP to redirect matching
>packets to. What's the format of such an object? Is the value
>"1.3.6.1.3.96.1.9.1.mplsXCIndex", where mplsXCIndex is in the range
>1..2147483647, correct?

         First, I believe that the MIB is up to revision -01,
so make sure that you are looking at the most recent
version. Second, since the action pointer is a RowPointer,
it should contain the OID of the first column of the XCEntry
in the appropriate row: ...mplsXcIndex....

where x, y, z, p are the indexes of the XcEntry.
The NMS can then do successive gets on the remainder
of the columns in this table to get the appropriate
values.

         --Tom




From owner-mpls@UU.NET  Tue Jul 24 15:19: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 PAA13047
	for ; Tue, 24 Jul 2001 15:19:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzcf09725;
	Tue, 24 Jul 2001 19:20:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzcf06749
	for mpls-outgoing; Tue, 24 Jul 2001 19:19:48 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 QQkzcf06740
	for ; Tue, 24 Jul 2001 19:19:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzcf00404
	for ; Tue, 24 Jul 2001 19:18: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 QQkzcf19919
	for ; Tue, 24 Jul 2001 19:18:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA16995 for mpls@uu.net; Tue, 24 Jul 2001 15:18:14 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzcf06480
	for ; Tue, 24 Jul 2001 19:17:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzcf20729
	for ; Tue, 24 Jul 2001 19:17:37 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 QQkzcf05412
	for ; Tue, 24 Jul 2001 19:17:36 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 PAA23315; Tue, 24 Jul 2001 15:17:29 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AED06863;
	Tue, 24 Jul 2001 15:17:28 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Jul 2001 15:22:50 -0400
To: John Muston , mpls@UU.NET
From: "Thomas D. Nadeau" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Cc: "Cheenu Srinivasan" ,
        "Arun Viswanathan (E-mail)" 
In-Reply-To: <20010724110322.A17502@netrotech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
>stack is shown as:
>
>         +------------------------------------------------+
>         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
>         +------------------------------------------------+
>         |        MPLS-interface ifType = mpls(166)       |
>         +------------------------------------------------+
>         |               Underlying Layer                 |
>         +------------------------------------------------+
>
>It is not clear to me how the particular lower layer of the tunnel
>interface is chosen.
>
>In the case of a tunnel interface created but not yet signalled, I
>imagine it would be layered over nothing (ifindex 0).
>
>Once signalled, would it be the mplsOutSegmentIfIndex of the
>tunnel's underlying cross connect?
>
>If so, I assume a rerouted tunnel, since it might have a different egress
>interface, might need to be restacked onto a different interface.
>
>Should a tunnel also be layered over the mplsInSegmentIfIndex (if
>nonzero)?


         Sorry for the confusion. The text in the draft needs
a few sentences to clarify. Something like this:

         In the case where the tunnel interface is
present at the head-end of the tunnel, the
tunnel interface should be stacked upon the
outgoing MPLS interface.  In the case where
the tunnel interface is optionally represented
at the egress of the tunnel as well, it
should be stacked upon the incoming MPLS
interface. If the tunnel interface has been created,
but no LSP has been signaled for the tunnel,
the tunnel should not be stacked upon any underlying
interface. If the tunnel's underlying LSP is
changed, then the interface stacking should be
changed accordingly to the new MPLS interface
as described above.

         --Tom





From owner-mpls@UU.NET  Tue Jul 24 18:13:47 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 SAA27722
	for ; Tue, 24 Jul 2001 18:13: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 QQkzcq14605;
	Tue, 24 Jul 2001 22:14:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkzcq22004
	for mpls-outgoing; Tue, 24 Jul 2001 22:14: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 QQkzcq21996
	for ; Tue, 24 Jul 2001 22:14: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 QQkzcq28321
	for ; Tue, 24 Jul 2001 22:13:39 GMT
Received: from crag.netrotech.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: user-112v9a2.biz.mindspring.com [66.47.165.66])
	id QQkzcq19505
	for ; Tue, 24 Jul 2001 22:13:38 GMT
Received: (from jmuston@localhost)
	by crag.netrotech.com (8.9.3/8.9.3/Debian 8.9.3-21) id RAA17757;
	Tue, 24 Jul 2001 17:29:16 -0500
From: John Muston 
Date: Tue, 24 Jul 2001 17:29:16 -0500
To: "Thomas D. Nadeau" 
Cc: mpls@UU.NET, Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Message-ID: <20010724172916.A17715@netrotech.com>
References: <20010724110322.A17502@netrotech.com> <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>; from tnadeau@cisco.com on Tue, Jul 24, 2001 at 03:22:50PM -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, Jul 24, 2001 at 03:22:50PM -0400, Thomas D. Nadeau wrote:
> 
>          Sorry for the confusion. The text in the draft needs
> a few sentences to clarify. Something like this:
> 
>          In the case where the tunnel interface is
> present at the head-end of the tunnel, the
> tunnel interface should be stacked upon the
> outgoing MPLS interface.  In the case where
> the tunnel interface is optionally represented
> at the egress of the tunnel as well, it
> should be stacked upon the incoming MPLS
> interface. If the tunnel interface has been created,

In the optional "egress of the tunnel" interface case where the
mplsInSegmentIfIndex is 0 because it is in the platform label space, I
assume the interface would have no lower layer.

> but no LSP has been signaled for the tunnel,
> the tunnel should not be stacked upon any underlying
> interface. If the tunnel's underlying LSP is
> changed, then the interface stacking should be
> changed accordingly to the new MPLS interface
> as described above.

Speaking of LSP changes on a tunnel, is it correct that a tunnel
interface's ifTable and MplsTunnelPerfEntry statistics are expected to
continue to increase rather than reset to 0 after an LSP change?

Thanks.

-John


From owner-mpls@UU.NET  Tue Jul 24 19:32: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 TAA01194
	for ; Tue, 24 Jul 2001 19:32: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 QQkzcw08476;
	Tue, 24 Jul 2001 23:33:43 GMT
Received: by mail-control.mail.uu.net 
	id QQkzcw17720
	for mpls-outgoing; Tue, 24 Jul 2001 23:33: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 QQkzcw17708
	for ; Tue, 24 Jul 2001 23:32:57 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 QQkzcw21600
	for ; Tue, 24 Jul 2001 23:32: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 QQkzcw06931
	for ; Tue, 24 Jul 2001 23:32:50 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA04833 for mpls@uu.net; Tue, 24 Jul 2001 19:32: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 QQkzcw17670
	for ; Tue, 24 Jul 2001 23:32:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzcw02388
	for ; Tue, 24 Jul 2001 23:30:49 GMT
Received: from hawk.CrescentNetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawk.crescentnetworks.com [64.64.148.44])
	id QQkzcw03686
	for ; Tue, 24 Jul 2001 23:30:49 GMT
Received: from crescentnetworks.com (dhcp60.in.crescentnets.com [192.168.29.60])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id TAA11564;
	Tue, 24 Jul 2001 19:29:46 -0400 (EDT)
Message-ID: <3B5E0519.A528B34B@crescentnetworks.com>
Date: Tue, 24 Jul 2001 19:30:33 -0400
From: Joan Cucchiara 
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" 
CC: John Muston , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Thomas D. Nadeau" wrote:
> 
> >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> >stack is shown as:
> >
> >         +------------------------------------------------+
> >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> >         +------------------------------------------------+
> >         |        MPLS-interface ifType = mpls(166)       |
> >         +------------------------------------------------+
> >         |               Underlying Layer                 |
> >         +------------------------------------------------+


Hi Tom,

Is it possible to have more than one Underlying Layer?
Should the above be changed to "Underlying Layer(s)"?

> >
> >It is not clear to me how the particular lower layer of the tunnel
> >interface is chosen.
> >
> >In the case of a tunnel interface created but not yet signalled, I
> >imagine it would be layered over nothing (ifindex 0).
> >
> >Once signalled, would it be the mplsOutSegmentIfIndex of the
> >tunnel's underlying cross connect?
> >
> >If so, I assume a rerouted tunnel, since it might have a different egress
> >interface, might need to be restacked onto a different interface.
> >
> >Should a tunnel also be layered over the mplsInSegmentIfIndex (if
> >nonzero)?
> 
>          Sorry for the confusion. The text in the draft needs
> a few sentences to clarify. Something like this:
> 
>          In the case where the tunnel interface is
> present at the head-end of the tunnel, the
> tunnel interface should be stacked upon the
> outgoing MPLS interface.  In the case where
> the tunnel interface is optionally represented
> at the egress of the tunnel as well, it
> should be stacked upon the incoming MPLS
> interface. If the tunnel interface has been created,

Does this imply that in a cross-connect where 
mplsInSegment and mplsOutSegment have non-zero ifIndices
that the mpls tunnel's ifIndex will appear twice in the
stacking?  (so once on the ifStack representing
the interface layers for the inSegment stacking and 
once on the ifStack representing
the interface layers for the outSegment stacking?)

  thanks, Joan

> but no LSP has been signaled for the tunnel,
> the tunnel should not be stacked upon any underlying
> interface. If the tunnel's underlying LSP is
> changed, then the interface stacking should be
> changed accordingly to the new MPLS interface
> as described above.
> 
>          --Tom



From owner-mpls@UU.NET  Tue Jul 24 23:24:16 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 XAA09892
	for ; Tue, 24 Jul 2001 23:24:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzdl10400;
	Wed, 25 Jul 2001 03:25:11 GMT
Received: by mail-control.mail.uu.net 
	id QQkzdl23981
	for mpls-outgoing; Wed, 25 Jul 2001 03:24: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 QQkzdl23973
	for ; Wed, 25 Jul 2001 03:24: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 QQkzdl18453
	for ; Wed, 25 Jul 2001 03:23:33 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 QQkzdl08602
	for ; Wed, 25 Jul 2001 03:23:32 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f6P92Tu00064
	for ; Wed, 25 Jul 2001 09:02:29 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GH0F1D00.SUY; Wed, 25 Jul 2001 08:59:37 +0530 
Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id EAA04424; Wed, 25 Jul 2001 04:02:42 +0530
Date: Wed, 25 Jul 2001 09:00:12 +0530 (IST)
From: "chetan kumar s" 
X-X-Sender: 
Reply-To: 
To: Eric Gray 
cc: , 
Subject: Re: penultimate hop poping
In-Reply-To: <3B5D912A.3D735114@sandburst.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

>     Of course, some implementations may so far depend on PHP that they
> will give the IMPLICIT NULL label again in this case - even though this
> is a clear violation of the specification.

	'violation of specification' how ?? I do not see any such
statements in any of the RFC, have I missed something ??

And beyond that if I look at the RFC 3031 section 3.16 Page 19, it states

   Initial label distribution protocol negotiations MUST allow each LSR
   to determine whether its neighboring LSRS are capable of popping the
   label stack.

So, does the RFC 3036 missing something in the init message ??

Thanks
Chetan S


>
> --
> Eric Gray
>
> You wrote:
>
> > Dear all,
> >
> >         as per rfc3031 under section 3.16.
> > 1)Initial LDP negotiations MUST allow each LSR to determine whether its
> > neighbouring LSRS are capable of poping the label stack.
> >
> > how can we(egress) determine that our neighbour has the capability of poping
> > the stack.
> >
> > 2)A LSR MUST NOT Request a label distribution peer to pop the label stack
> > unless it is capable of doing so.
> >         is it possible that a LSR will not support the label stack poping.
> >
> > and under section 4.1.5 (rfc3031)
> > LSR Rd distributes a binding between Implicit NULL and an address prefix X to
> > LSR Ru if and only if :
> >         1. the rules os -----------
> >         2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it can pop the
> > label stack) ...
> > how can Rd (egress) knows that  Ru has support of poping of stack. or is it a
> > MUST that each LSR should support penultimate hop poing.
> >
> > please calrify ,me about this.
> > thanks in adv.
> > regards
> > lonka
>



From owner-mpls@UU.NET  Tue Jul 24 23:38: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 XAA10453
	for ; Tue, 24 Jul 2001 23:38: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 QQkzdm01213;
	Wed, 25 Jul 2001 03:39:30 GMT
Received: by mail-control.mail.uu.net 
	id QQkzdm24983
	for mpls-outgoing; Wed, 25 Jul 2001 03:39: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 QQkzdm24969
	for ; Wed, 25 Jul 2001 03:38: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 QQkzdm12610
	for ; Wed, 25 Jul 2001 03:37:30 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 QQkzdm28286
	for ; Wed, 25 Jul 2001 03:37:27 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Jul 2001 09:10:35 +0500
Message-ID: <751B6DD7A243D511AB9F0002557C56878B2BC5@HUAWEIMAIL>
To: chetan.kumar@wipro.com
Cc: lsreddy@trinc.com, mpls@UU.NET
Subject: RE: penultimate hop poping
Date: Wed, 25 Jul 2001 09:10:30 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C114BF.BE2CCA40"
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_01C114BF.BE2CCA40
Content-Type: text/plain;
	charset="iso-8859-1"


hello Chetan 


  The RFC3036 clearly mentions the following thing

--------------------------------------------------------------------
6. Areas for Future Study

   The following topics not addressed in this version of LDP are
   possible areas for future study:

      -  Section 2.16 of the MPLS architecture [RFC3031] requires that
         the initial label distribution protocol negotiation between
         peer LSRs enable each LSR to determine whether its peer is
         capable of popping the label stack.  This version of LDP
         assumes that LSRs support label popping for all link types
         except ATM and Frame Relay.  A future version may specify means
         to make this determination part of the session initiation
         negotiation.
------------------------------------------------------------------------

So the RFC is not missing anything but it is left for the future study


Regds
Ashwin




-----Original Message-----
From: chetan kumar s [mailto:chetan.kumar@wipro.com]
Sent: Wednesday, July 25, 2001 8:30 AM
To: Eric Gray
Cc: lsreddy@trinc.com; mpls@UU.NET
Subject: Re: penultimate hop poping


Hi,

>     Of course, some implementations may so far depend on PHP that they
> will give the IMPLICIT NULL label again in this case - even though this
> is a clear violation of the specification.

	'violation of specification' how ?? I do not see any such
statements in any of the RFC, have I missed something ??

And beyond that if I look at the RFC 3031 section 3.16 Page 19, it states

   Initial label distribution protocol negotiations MUST allow each LSR
   to determine whether its neighboring LSRS are capable of popping the
   label stack.

So, does the RFC 3036 missing something in the init message ??

Thanks
Chetan S


>
> --
> Eric Gray
>
> You wrote:
>
> > Dear all,
> >
> >         as per rfc3031 under section 3.16.
> > 1)Initial LDP negotiations MUST allow each LSR to determine whether its
> > neighbouring LSRS are capable of poping the label stack.
> >
> > how can we(egress) determine that our neighbour has the capability of
poping
> > the stack.
> >
> > 2)A LSR MUST NOT Request a label distribution peer to pop the label
stack
> > unless it is capable of doing so.
> >         is it possible that a LSR will not support the label stack
poping.
> >
> > and under section 4.1.5 (rfc3031)
> > LSR Rd distributes a binding between Implicit NULL and an address prefix
X to
> > LSR Ru if and only if :
> >         1. the rules os -----------
> >         2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it
can pop the
> > label stack) ...
> > how can Rd (egress) knows that  Ru has support of poping of stack. or is
it a
> > MUST that each LSR should support penultimate hop poing.
> >
> > please calrify ,me about this.
> > thanks in adv.
> > regards
> > lonka
>

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






RE: penultimate hop poping






hello Chetan 






  The RFC3036 clearly mentions the following =
thing




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

6. Areas for Future Study




   The following topics not addressed in =
this version of LDP are

   possible areas for future study:




      -  Section 2.16 =
of the MPLS architecture [RFC3031] requires that

         the =
initial label distribution protocol negotiation between

         =
peer LSRs enable each LSR to determine whether its peer is

         =
capable of popping the label stack.  This version of LDP

         =
assumes that LSRs support label popping for all link types

         =
except ATM and Frame Relay.  A future version may specify =
means

         to =
make this determination part of the session initiation

         =
negotiation.

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




So the RFC is not missing anything but it is left for =
the future study






Regds

Ashwin










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

From: chetan kumar s [mailto:chetan.kumar@wipro.com=
]

Sent: Wednesday, July 25, 2001 8:30 AM

To: Eric Gray

Cc: lsreddy@trinc.com; mpls@UU.NET

Subject: Re: penultimate hop poping






Hi,




>     Of course, some =
implementations may so far depend on PHP that they

> will give the IMPLICIT NULL label again in this =
case - even though this

> is a clear violation of the =
specification.




        'violation =
of specification' how ?? I do not see any such

statements in any of the RFC, have I missed =
something ??




And beyond that if I look at the RFC 3031 section =
3.16 Page 19, it states




   Initial label distribution protocol =
negotiations MUST allow each LSR

   to determine whether its neighboring =
LSRS are capable of popping the

   label stack.




So, does the RFC 3036 missing something in the init =
message ??




Thanks

Chetan S






>

> --

> Eric Gray

>

> You wrote:

>

> > Dear all,

> >

> =
>         as per rfc3031 =
under section 3.16.

> > 1)Initial LDP negotiations MUST allow each =
LSR to determine whether its

> > neighbouring LSRS are capable of poping =
the label stack.

> >

> > how can we(egress) determine that our =
neighbour has the capability of poping

> > the stack.

> >

> > 2)A LSR MUST NOT Request a label =
distribution peer to pop the label stack

> > unless it is capable of doing so.

> =
>         is it possible =
that a LSR will not support the label stack poping.

> >

> > and under section 4.1.5 (rfc3031)

> > LSR Rd distributes a binding between =
Implicit NULL and an address prefix X to

> > LSR Ru if and only if :

> =
>         1. the rules os =
-----------

> =
>         2.Rd knows that Ru =
Can Support Implicit NULL label(i.e. that it can pop the

> > label stack) ...

> > how can Rd (egress) knows that  Ru =
has support of poping of stack. or is it a

> > MUST that each LSR should support =
penultimate hop poing.

> >

> > please calrify ,me about this.

> > thanks in adv.

> > regards

> > lonka

>





------_=_NextPart_001_01C114BF.BE2CCA40--


From owner-mpls@UU.NET  Wed Jul 25 00:35: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 AAA12866
	for ; Wed, 25 Jul 2001 00:35:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzdq22911;
	Wed, 25 Jul 2001 04:36:31 GMT
Received: by mail-control.mail.uu.net 
	id QQkzdq19084
	for mpls-outgoing; Wed, 25 Jul 2001 04:35: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 QQkzdq19074
	for ; Wed, 25 Jul 2001 04:35: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 QQkzdq20076
	for ; Wed, 25 Jul 2001 04:34:01 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQkzdq19775
	for ; Wed, 25 Jul 2001 04:33:58 GMT
Received: from multitech.co.in ([192.168.1.32])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6P4TWP24981;
	Wed, 25 Jul 2001 09:59:32 +0530
Message-ID: <3B5E4CFF.BB65888C@multitech.co.in>
Date: Wed, 25 Jul 2001 10:07:19 +0530
From: abhay 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" 
CC: John Muston , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
Content-Type: multipart/alternative;
 boundary="------------FBF9AFE480BEEEEF642E9223"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------FBF9AFE480BEEEEF642E9223
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

    This new explanation would have helped me sometime ago,

    It did take a while for me to get  what you were saying then.

    Better late than never..8)

    Thanks

    Regards,

    Abhay

"Thomas D. Nadeau" wrote:

> >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> >stack is shown as:
> >
> >         +------------------------------------------------+
> >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> >         +------------------------------------------------+
> >         |        MPLS-interface ifType = mpls(166)       |
> >         +------------------------------------------------+
> >         |               Underlying Layer                 |
> >         +------------------------------------------------+
> >
> >It is not clear to me how the particular lower layer of the tunnel
> >interface is chosen.
> >
> >In the case of a tunnel interface created but not yet signalled, I
> >imagine it would be layered over nothing (ifindex 0).
> >
> >Once signalled, would it be the mplsOutSegmentIfIndex of the
> >tunnel's underlying cross connect?
> >
> >If so, I assume a rerouted tunnel, since it might have a different egress
> >interface, might need to be restacked onto a different interface.
> >
> >Should a tunnel also be layered over the mplsInSegmentIfIndex (if
> >nonzero)?
>
>          Sorry for the confusion. The text in the draft needs
> a few sentences to clarify. Something like this:
>
>          In the case where the tunnel interface is
> present at the head-end of the tunnel, the
> tunnel interface should be stacked upon the
> outgoing MPLS interface.  In the case where
> the tunnel interface is optionally represented
> at the egress of the tunnel as well, it
> should be stacked upon the incoming MPLS
> interface. If the tunnel interface has been created,
> but no LSP has been signaled for the tunnel,
> the tunnel should not be stacked upon any underlying
> interface. If the tunnel's underlying LSP is
> changed, then the interface stacking should be
> changed accordingly to the new MPLS interface
> as described above.
>
>          --Tom

--------------FBF9AFE480BEEEEF642E9223
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Tom,



    This new explanation would have helped me sometime ago,



    It did take a while for me to get  what you were saying then.



    Better late than never..8)



    Thanks



    Regards,



    Abhay




"Thomas D. Nadeau" wrote:

>In section 7 of draft-ietf-mpls-te-mib-06.txt the
interface

>stack is shown as:

>

>         +------------------------------------------------+

>         | MPLS-Tunnel-interface
ifType = mplsTunnel(150) |

>         +------------------------------------------------+

>         |       
MPLS-interface ifType = mpls(166)       |

>         +------------------------------------------------+

>         |              
Underlying Layer                
|

>         +------------------------------------------------+

>

>It is not clear to me how the particular lower layer of the tunnel

>interface is chosen.

>

>In the case of a tunnel interface created but not yet signalled, I

>imagine it would be layered over nothing (ifindex 0).

>

>Once signalled, would it be the mplsOutSegmentIfIndex of the

>tunnel's underlying cross connect?

>

>If so, I assume a rerouted tunnel, since it might have a different
egress

>interface, might need to be restacked onto a different interface.

>

>Should a tunnel also be layered over the mplsInSegmentIfIndex (if

>nonzero)?

         Sorry for the confusion.
The text in the draft needs

a few sentences to clarify. Something like this:

         In the case where the
tunnel interface is

present at the head-end of the tunnel, the

tunnel interface should be stacked upon the

outgoing MPLS interface.  In the case where

the tunnel interface is optionally represented

at the egress of the tunnel as well, it

should be stacked upon the incoming MPLS

interface. If the tunnel interface has been created,

but no LSP has been signaled for the tunnel,

the tunnel should not be stacked upon any underlying

interface. If the tunnel's underlying LSP is

changed, then the interface stacking should be

changed accordingly to the new MPLS interface

as described above.

         --Tom



--------------FBF9AFE480BEEEEF642E9223--



From owner-mpls@UU.NET  Wed Jul 25 01:57: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 BAA22390
	for ; Wed, 25 Jul 2001 01:57: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 QQkzdv15435;
	Wed, 25 Jul 2001 05:58:43 GMT
Received: by mail-control.mail.uu.net 
	id QQkzdv14957
	for mpls-outgoing; Wed, 25 Jul 2001 05:58:12 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzdv14949
	for ; Wed, 25 Jul 2001 05: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 QQkzdv00319
	for ; Wed, 25 Jul 2001 05:57:40 GMT
Received: from india.tejasnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.94.83])
	id QQkzdv03909
	for ; Wed, 25 Jul 2001 05:57:17 GMT
Received: from tejasnetworks.com ([192.168.1.157])
	by india.tejasnetworks.com (8.9.3/8.9.3) with ESMTP id LAA21502;
	Wed, 25 Jul 2001 11:36:13 +0530
Message-ID: <3B5E6009.59184B99@tejasnetworks.com>
Date: Wed, 25 Jul 2001 11:28:33 +0530
From: rajesh 
Reply-To: rajesh@tejasnetworks.com
Organization: Tejas Networks
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET, jplang@calient.net, kireeti@juniper.net, azinin@cisco.com
Subject: Queries regarding LMP.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

     Have a few queries regd LMP.

Q1)  Regd the applicability of LMP...

draft-many-gmpls-architecture-00.txt states that

"   For instance, the traditional IP routing model assumes the
   establishment of a routing adjacency over each link connecting two
   adjacent nodes. Having such a large number of adjacencies is not
   scalable at all. Each node needs to maintain each of its adjacencies
   one by one, and link state routing information must be flooded in
   the topology for each link.

   To solve this issue the concept of bundling was introduced.
   Moreover, the manual configuration and control of these links, even
   if they are unnumbered, becomes totally impractical. The Link
   Management Protocol (LMP) was specified to solve these problems. "

a) Can one assume that LMP makes sense ONLY in the case of a large
     number of parallel links and link bundling...

      and an implementation of GMPLS neednot have LMP if no link
      bundling is used ??

      The above maybe the case when using lower end SONET ADM,
       DXCs...

b) Under what other conditions would one require LMP (ie other than
      link bundling) ?

Q2) Suppose one does NOT need to use LMP but then one needs to use
         OSPF extensions to support TE
(draft-kompella-ospf-gmpls-extensions-01.txt) ,

        then one may need to do a  correlation of Link Ids between 2
TE nodes.

       a) Is there a standard recommended way to do this correlation ??

             E.g OSPF - Link Local Signaling
                    or OSPF - link scope LSA ?

Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
         are encoded as IP packets and also suggests protocol number
140.

          What would be the destination IP address of an LMP packet ??

           A multicast or is it got from an IGP ??

Q4) In LMP, if a Link Id correlation has been done,  and If the link ids

         on one of the ends or both change... How is this change taken
into
         account ??

         Eg for i = 1,2
                          Port i, Node 1 connected to Port i, Node 2

          If one interchanges the connection then one has to recorrelate

           the Link Id mappings..

Thanks in advance,
Rajesh



From owner-mpls@UU.NET  Wed Jul 25 02:26: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 SMTP id CAA01985
	for ; Wed, 25 Jul 2001 02:26: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 QQkzdx11307;
	Wed, 25 Jul 2001 06:27:28 GMT
Received: by mail-control.mail.uu.net 
	id QQkzdx06742
	for mpls-outgoing; Wed, 25 Jul 2001 06:26:57 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzdx06728
	for ; Wed, 25 Jul 2001 06:26:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzdx21250
	for ; Wed, 25 Jul 2001 06:25:38 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzdx22928
	for ; Wed, 25 Jul 2001 06:25:33 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Jul 2001 11:53:16 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71E6849@mailserver.netbrahma.com>
From: Manoj Agiwal 
To: "'rsvp@isi.edu'" 
Cc: "'mpls@UU.NET'" 
Subject: Conversion of Bandwidth to QoS parameters .
Date: Wed, 25 Jul 2001 11:53:15 +0530
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 ,
        What is the way in which we can convert the bandwidth to QoS
parameters viz. Traffic Spec Rate , Bucket Size , Peak Rate , Minimum Police
Unit and Maximum Packet Size .

       When the end user request for reservations he will mention Bandwidth
to be reserved , in case of RSVP-TE reservation will get initiated from
ingress router . Thus is there any way we can map Bandwidth to QoS
parameters .

Regards ,
Manoj


From owner-mpls@UU.NET  Wed Jul 25 06:35: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 GAA07903
	for ; Wed, 25 Jul 2001 06:35: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 QQkzeo22940;
	Wed, 25 Jul 2001 10:36:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkzeo13645
	for mpls-outgoing; Wed, 25 Jul 2001 10:35: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 QQkzeo13628
	for ; Wed, 25 Jul 2001 10:35: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 QQkzeo13551
	for ; Wed, 25 Jul 2001 10:34:45 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 QQkzeo11662
	for ; Wed, 25 Jul 2001 10:34:44 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA06274 for mpls@uu.net; Wed, 25 Jul 2001 06:34:43 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzeo13519
	for ; Wed, 25 Jul 2001 10:34:13 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 QQkzeo17917
	for ; Wed, 25 Jul 2001 10:33: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 QQkzeo27896
	for ; Wed, 25 Jul 2001 10:33:39 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 f6PAXPg24806;
	Wed, 25 Jul 2001 03:33:25 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id GAA06398; Wed, 25 Jul 2001 06:33:17 -0400 (EDT)
Message-Id: <200107251033.GAA06398@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: chetan.kumar@wipro.com
cc: Eric Gray , lsreddy@trinc.com, mpls@UU.NET
Subject: Re: penultimate hop poping 
In-reply-to: Your message of "Wed, 25 Jul 2001 09:00:12 +0530."
              
Date: Wed, 25 Jul 2001 06:33:17 -0400
From: Bob Thomas 
Sender: owner-mpls@UU.NET
Precedence: bulk

> Hi,
> 
> >     Of course, some implementations may so far depend on PHP that they
> > will give the IMPLICIT NULL label again in this case - even though this
> > is a clear violation of the specification.
> 
> 	'violation of specification' how ?? I do not see any such
> statements in any of the RFC, have I missed something ??
> 
> And beyond that if I look at the RFC 3031 section 3.16 Page 19, it states
> 
>    Initial label distribution protocol negotiations MUST allow each LSR
>    to determine whether its neighboring LSRS are capable of popping the
>    label stack.
> 
> So, does the RFC 3036 missing something in the init message ??

Please see the first bullet in Section 6 of RFC3036:

      -  Section 2.16 of the MPLS architecture [RFC3031] requires that
         the initial label distribution protocol negotiation between
         peer LSRs enable each LSR to determine whether its peer is
         capable of popping the label stack.  This version of LDP
         assumes that LSRs support label popping for all link types
         except ATM and Frame Relay.  A future version may specify means
         to make this determination part of the session initiation
         negotiation.

         (The reference to Section 2.16 should be a reference to
          section 3.16).

Bob


> 
> Thanks
> Chetan S
> 
> 
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > Dear all,
> > >
> > >         as per rfc3031 under section 3.16.
> > > 1)Initial LDP negotiations MUST allow each LSR to determine whether its
> > > neighbouring LSRS are capable of poping the label stack.
> > >
> > > how can we(egress) determine that our neighbour has the capability of poping
> > > the stack.
> > >
> > > 2)A LSR MUST NOT Request a label distribution peer to pop the label stack
> > > unless it is capable of doing so.
> > >         is it possible that a LSR will not support the label stack poping.
> > >
> > > and under section 4.1.5 (rfc3031)
> > > LSR Rd distributes a binding between Implicit NULL and an address prefix X to
> > > LSR Ru if and only if :
> > >         1. the rules os -----------
> > >         2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it can pop the
> > > label stack) ...
> > > how can Rd (egress) knows that  Ru has support of poping of stack. or is it a
> > > MUST that each LSR should support penultimate hop poing.
> > >
> > > please calrify ,me about this.
> > > thanks in adv.
> > > regards
> > > lonka
> >
> 



From owner-mpls@UU.NET  Wed Jul 25 09:15: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 SMTP id JAA19356
	for ; Wed, 25 Jul 2001 09:15: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 QQkzez27821;
	Wed, 25 Jul 2001 13:16:48 GMT
Received: by mail-control.mail.uu.net 
	id QQkzez25359
	for mpls-outgoing; Wed, 25 Jul 2001 13:15: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 QQkzez25325
	for ; Wed, 25 Jul 2001 13:15: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 QQkzey18663
	for ; Wed, 25 Jul 2001 13:14:37 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 QQkzey10669
	for ; Wed, 25 Jul 2001 13:14:36 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA14126 for mpls@uu.net; Wed, 25 Jul 2001 09:14:36 -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 QQkzey24746
	for ; Wed, 25 Jul 2001 13:14:11 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzey16827
	for ; Wed, 25 Jul 2001 13:13:45 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 QQkzey09392
	for ; Wed, 25 Jul 2001 13:13:45 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 JAA00096; Wed, 25 Jul 2001 09:13:37 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEE05057;
	Wed, 25 Jul 2001 09:13:35 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010725091749.0216f950@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Jul 2001 09:19:03 -0400
To: John Muston 
From: "Thomas D. Nadeau" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Cc: mpls@UU.NET, Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
In-Reply-To: <20010724172916.A17715@netrotech.com>
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
 <20010724110322.A17502@netrotech.com>
 <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 05:29 PM 7/24/2001 -0500, John Muston wrote:
>On Tue, Jul 24, 2001 at 03:22:50PM -0400, Thomas D. Nadeau wrote:
> >
> >          Sorry for the confusion. The text in the draft needs
> > a few sentences to clarify. Something like this:
> >
> >          In the case where the tunnel interface is
> > present at the head-end of the tunnel, the
> > tunnel interface should be stacked upon the
> > outgoing MPLS interface.  In the case where
> > the tunnel interface is optionally represented
> > at the egress of the tunnel as well, it
> > should be stacked upon the incoming MPLS
> > interface. If the tunnel interface has been created,
>
>In the optional "egress of the tunnel" interface case where the
>mplsInSegmentIfIndex is 0 because it is in the platform label space, I
>assume the interface would have no lower layer.

         Yes.

> > but no LSP has been signaled for the tunnel,
> > the tunnel should not be stacked upon any underlying
> > interface. If the tunnel's underlying LSP is
> > changed, then the interface stacking should be
> > changed accordingly to the new MPLS interface
> > as described above.
>
>Speaking of LSP changes on a tunnel, is it correct that a tunnel
>interface's ifTable and MplsTunnelPerfEntry statistics are expected to
>continue to increase rather than reset to 0 after an LSP change?

         Yes. The reason being that the interface itself has not
been reset. This is similar to say an IP interface being moved
from eth0 to eth1 without being disabled first. Another
similar situation is if you did load balancing over two
interfaces eth0 and eth1, and one of them went away. The
IP interface would continue to roll upwards.

         --Tom



>Thanks.
>
>-John



From owner-mpls@UU.NET  Wed Jul 25 09:21: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 SMTP id JAA19990
	for ; Wed, 25 Jul 2001 09:21: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 QQkzez23491;
	Wed, 25 Jul 2001 13:22:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkzez26412
	for mpls-outgoing; Wed, 25 Jul 2001 13:22: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 QQkzez26403
	for ; Wed, 25 Jul 2001 13:22: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 QQkzez19353
	for ; Wed, 25 Jul 2001 13:21:11 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 QQkzez21067
	for ; Wed, 25 Jul 2001 13:21:11 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA14702 for mpls@uu.net; Wed, 25 Jul 2001 09:21: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 QQkzez26252
	for ; Wed, 25 Jul 2001 13:20: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 QQkzez29504
	for ; Wed, 25 Jul 2001 13:19:53 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 QQkzez02973
	for ; Wed, 25 Jul 2001 13:19:53 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 JAA00734; Wed, 25 Jul 2001 09:19:41 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEE05121;
	Wed, 25 Jul 2001 09:19:39 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010725091917.02169d20@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Jul 2001 09:25:07 -0400
To: Joan Cucchiara 
From: "Thomas D. Nadeau" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Cc: John Muston , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
In-Reply-To: <3B5E0519.A528B34B@crescentnetworks.com>
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:30 PM 7/24/2001 -0400, Joan Cucchiara wrote:


>"Thomas D. Nadeau" wrote:
> >
> > >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> > >stack is shown as:
> > >
> > >         +------------------------------------------------+
> > >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> > >         +------------------------------------------------+
> > >         |        MPLS-interface ifType = mpls(166)       |
> > >         +------------------------------------------------+
> > >         |               Underlying Layer                 |
> > >         +------------------------------------------------+
>
>
>Hi Tom,
>
>Is it possible to have more than one Underlying Layer?
>Should the above be changed to "Underlying Layer(s)"?

         Yes. You are correct. Nice catch. Since it is
possible to have more than one LSP servicing
the tunnel, there could be multiple underlying interfaces.



> > >
> > >It is not clear to me how the particular lower layer of the tunnel
> > >interface is chosen.
> > >
> > >In the case of a tunnel interface created but not yet signalled, I
> > >imagine it would be layered over nothing (ifindex 0).
> > >
> > >Once signalled, would it be the mplsOutSegmentIfIndex of the
> > >tunnel's underlying cross connect?
> > >
> > >If so, I assume a rerouted tunnel, since it might have a different egress
> > >interface, might need to be restacked onto a different interface.
> > >
> > >Should a tunnel also be layered over the mplsInSegmentIfIndex (if
> > >nonzero)?
> >
> >          Sorry for the confusion. The text in the draft needs
> > a few sentences to clarify. Something like this:
> >
> >          In the case where the tunnel interface is
> > present at the head-end of the tunnel, the
> > tunnel interface should be stacked upon the
> > outgoing MPLS interface.  In the case where
> > the tunnel interface is optionally represented
> > at the egress of the tunnel as well, it
> > should be stacked upon the incoming MPLS
> > interface. If the tunnel interface has been created,
>
>Does this imply that in a cross-connect where
>mplsInSegment and mplsOutSegment have non-zero ifIndices
>that the mpls tunnel's ifIndex will appear twice in the
>stacking?  (so once on the ifStack representing
>the interface layers for the inSegment stacking and
>once on the ifStack representing
>the interface layers for the outSegment stacking?)

         No, I don't think so. The reason being that you
would be referring to a midpoint in that case, and
there are no tunnel interfaces at midpoints.
I think that you have one or the other if you only
consider the ingress/egress cases. I personally think that
you only have this at the head of the tunnel, and thus
a single outgoing XC and ifIndex to stack upon. However,
there are some who feel that we should include the
case at the egress.

         --Tom




From owner-mpls@UU.NET  Wed Jul 25 09:33: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 JAA20784
	for ; Wed, 25 Jul 2001 09:33: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 QQkzfa24558;
	Wed, 25 Jul 2001 13:34:12 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfa27817
	for mpls-outgoing; Wed, 25 Jul 2001 13:33: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 QQkzfa27808
	for ; Wed, 25 Jul 2001 13:33: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 QQkzfa21992
	for ; Wed, 25 Jul 2001 13:30:58 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 QQkzfa06434
	for ; Wed, 25 Jul 2001 13:30:57 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA15966 for mpls@uu.net; Wed, 25 Jul 2001 09:30:57 -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 QQkzfa27520
	for ; Wed, 25 Jul 2001 13:30: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 QQkzez12709
	for ; Wed, 25 Jul 2001 13:29:50 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 QQkzez17472
	for ; Wed, 25 Jul 2001 13:29:49 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 JAA01820; Wed, 25 Jul 2001 09:29:42 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEE05255;
	Wed, 25 Jul 2001 09:29:40 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010725093431.02190e08@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Jul 2001 09:35:08 -0400
To: abhay 
From: "Thomas D. Nadeau" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Cc: John Muston , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
In-Reply-To: <3B5E4CFF.BB65888C@multitech.co.in>
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi,

>     This new explanation would have helped me sometime ago,
>     It did take a while for me to get  what you were saying then.
>     Better late than never..8)

         Glad to have helped. In the future, please speak up if
something is unclear, since if it is unclear to you, there
are probably lots of others that it is unclear to as well. 8)

         --Tom




>     Thanks
>
>     Regards,
>
>     Abhay
>
>
>"Thomas D. Nadeau" wrote:
>> >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
>> >stack is shown as:
>> >
>> >         +------------------------------------------------+
>> >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
>> >         +------------------------------------------------+
>> >         |        MPLS-interface ifType = mpls(166)       |
>> >         +------------------------------------------------+
>> >         |               Underlying Layer                 |
>> >         +------------------------------------------------+
>> >
>> >It is not clear to me how the particular lower layer of the tunnel
>> >interface is chosen.
>> >
>> >In the case of a tunnel interface created but not yet signalled, I
>> >imagine it would be layered over nothing (ifindex 0).
>> >
>> >Once signalled, would it be the mplsOutSegmentIfIndex of the
>> >tunnel's underlying cross connect?
>> >
>> >If so, I assume a rerouted tunnel, since it might have a different egress
>> >interface, might need to be restacked onto a different interface.
>> >
>> >Should a tunnel also be layered over the mplsInSegmentIfIndex (if
>> >nonzero)?
>>
>>          Sorry for the confusion. The text in the draft needs
>>a few sentences to clarify. Something like this:
>>
>>          In the case where the tunnel interface is
>>present at the head-end of the tunnel, the
>>tunnel interface should be stacked upon the
>>outgoing MPLS interface.  In the case where
>>the tunnel interface is optionally represented
>>at the egress of the tunnel as well, it
>>should be stacked upon the incoming MPLS
>>interface. If the tunnel interface has been created,
>>but no LSP has been signaled for the tunnel,
>>the tunnel should not be stacked upon any underlying
>>interface. If the tunnel's underlying LSP is
>>changed, then the interface stacking should be
>>changed accordingly to the new MPLS interface
>>as described above.
>>
>>          --Tom



From owner-mpls@UU.NET  Wed Jul 25 11:26:22 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 LAA00958
	for ; Wed, 25 Jul 2001 11:26: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 QQkzfh02288;
	Wed, 25 Jul 2001 15:27:12 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfh20776
	for mpls-outgoing; Wed, 25 Jul 2001 15:26: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 QQkzfh20713
	for ; Wed, 25 Jul 2001 15:25: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 QQkzfh04730
	for ; Wed, 25 Jul 2001 15:25:43 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzfh09860
	for ; Wed, 25 Jul 2001 15:25:43 GMT
Message-ID: <3B5EE4F1.BD42FAC9@sandburst.com>
Date: Wed, 25 Jul 2001 11:25:37 -0400
From: Eric Gray 
MIME-Version: 1.0
To: chetan.kumar@wipro.com
Cc: lsreddy@trinc.com, mpls@UU.NET
Subject: Re: penultimate hop poping
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Chetan S,

    Yes, violation of the specification.  Regardless of the distribution mode
that an LSR is using (DU/DoD), any LSR may request additional labels
for a particular FEC.  This is intended primarily to support LSP setup when
the upstream LSR does not want (or is not able) to merge all packets onto
a single downstream LSP.  Labels returned for such requests MUST NOT
be the same as those distributed (for this, or any other, FEC) previously
(unless also previously released by the upstream LSR).

    This is required because simply issuing the same label forces upstream
LSR(s) to merge packets.  The procedures in the appendix of RFC 3036
specify this behavior.

--
Eric Gray

You wrote:

> Hi,
>
> >     Of course, some implementations may so far depend on PHP that they
> > will give the IMPLICIT NULL label again in this case - even though this
> > is a clear violation of the specification.
>
>         'violation of specification' how ?? I do not see any such
> statements in any of the RFC, have I missed something ??
>
> And beyond that if I look at the RFC 3031 section 3.16 Page 19, it states
>
>    Initial label distribution protocol negotiations MUST allow each LSR
>    to determine whether its neighboring LSRS are capable of popping the
>    label stack.
>
> So, does the RFC 3036 missing something in the init message ??
>
> Thanks
> Chetan S
>
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > Dear all,
> > >
> > >         as per rfc3031 under section 3.16.
> > > 1)Initial LDP negotiations MUST allow each LSR to determine whether its
> > > neighbouring LSRS are capable of poping the label stack.
> > >
> > > how can we(egress) determine that our neighbour has the capability of poping
> > > the stack.
> > >
> > > 2)A LSR MUST NOT Request a label distribution peer to pop the label stack
> > > unless it is capable of doing so.
> > >         is it possible that a LSR will not support the label stack poping.
> > >
> > > and under section 4.1.5 (rfc3031)
> > > LSR Rd distributes a binding between Implicit NULL and an address prefix X to
> > > LSR Ru if and only if :
> > >         1. the rules os -----------
> > >         2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it can pop the
> > > label stack) ...
> > > how can Rd (egress) knows that  Ru has support of poping of stack. or is it a
> > > MUST that each LSR should support penultimate hop poing.
> > >
> > > please calrify ,me about this.
> > > thanks in adv.
> > > regards
> > > lonka
> >



From owner-mpls@UU.NET  Wed Jul 25 11:56: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 LAA04081
	for ; Wed, 25 Jul 2001 11:56: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 QQkzfj17562;
	Wed, 25 Jul 2001 15:57:45 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfj23927
	for mpls-outgoing; Wed, 25 Jul 2001 15:57: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 QQkzfj23902
	for ; Wed, 25 Jul 2001 15:57:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzfj18281
	for ; Wed, 25 Jul 2001 15:55: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 QQkzfj25258
	for ; Wed, 25 Jul 2001 15:55:14 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA26800 for mpls@uu.net; Wed, 25 Jul 2001 11:55: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 QQkzfj23529
	for ; Wed, 25 Jul 2001 15:54: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 QQkzfj11073
	for ; Wed, 25 Jul 2001 15:54:02 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQkzfj11737
	for ; Wed, 25 Jul 2001 15:54:01 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6PFs1H86160
	for ; Wed, 25 Jul 2001 08:54:01 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B5EEB94.C2AB0DC2@juniper.net>
Date: Wed, 25 Jul 2001 08:53:56 -0700
From: Ping Pan 
Organization: Juniper Networks
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls-list 
Subject: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Content-Type: multipart/mixed;
 boundary="------------E66D2BBA2CA2D49C6BD05B8F"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------E66D2BBA2CA2D49C6BD05B8F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Here is an updated version of LSP-ping. We have taken the suggestions
from George and Sanjay.

Thanks!

- Ping
--------------E66D2BBA2CA2D49C6BD05B8F
Content-Type: message/rfc822
Content-Disposition: inline

Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA22173;
	Wed, 25 Jul 2001 10:37:20 -0400 (EDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA26306;
	Wed, 25 Jul 2001 10:37:11 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA27478
	for ietf-123-outbound.06@ietf.org; Wed, 25 Jul 2001 09:05:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25476
	for ; Wed, 25 Jul 2001 06:32:54 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07464
	for ; Wed, 25 Jul 2001 06:32:53 -0400 (EDT)
Message-Id: <200107251032.GAA07464@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;;:;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-pan-lsp-ping-01.txt
Date: Wed, 25 Jul 2001 06:32:52 -0400
Sender: nsyracus@cnri.reston.va.us
X-Mozilla-Status2: 00000000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Detecting Data Plane Liveliness in RSVP-TE
	Author(s)	: P. Pan, N. Sheth, D. Cooper
	Filename	: draft-pan-lsp-ping-01.txt
	Pages		: 7
	Date		: 24-Jul-01
	
This document describes a simple and efficient mechanism that can be
used to detect data plane failures in MPLS LSP's. The proposed mechanism
requires a new optional RSVP object.  The processing overhead imposed on
LSR control plane is kept to minimum.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pan-lsp-ping-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pan-lsp-ping-01.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pan-lsp-ping-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132235.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pan-lsp-ping-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pan-lsp-ping-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132235.I-D@ietf.org>

--OtherAccess--

--NextPart--


--------------E66D2BBA2CA2D49C6BD05B8F--



From owner-mpls@UU.NET  Wed Jul 25 11:59:01 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 LAA04338
	for ; Wed, 25 Jul 2001 11:59:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzfj26269;
	Wed, 25 Jul 2001 15:59:55 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfj24358
	for mpls-outgoing; Wed, 25 Jul 2001 15:59: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 QQkzfj24157
	for ; Wed, 25 Jul 2001 15:59:01 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzfj27115
	for ; Wed, 25 Jul 2001 15:58:42 GMT
Received: from edgeflow.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.191.40.82])
	id QQkzfj19235
	for ; Wed, 25 Jul 2001 15:58:41 GMT
Received: from edgsvr04.edgeflow.edgeflow.com ([10.0.1.60]) by watchdog.edgeflow.com with ESMTP id <119045>; Wed, 25 Jul 2001 11:58:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Queries regarding LMP.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date:  Wed, 25 Jul 2001 11:58:31 -0400
Message-ID: 
Thread-Topic: Queries regarding LMP.
Thread-Index: AcEUzv8oQDe7d+VTQXKqdTvHaG/QKQAUIDNQ
From: "Martin Dubuc" 
To: , , ,
        , 
Cc: 
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA04338

Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
control and data link health. To determine whether LMP is useful or not,
one has to look at the operational aspect of product deployment and
maintenance, i.e. what tools the vendor wants to implement to facilitate
provisioning and maintenance of their customers network. In a small
network, a vendor may be able to get away with manual configuration of
links. In an opaque network, it is also easy to pinpoint link failures.
However, in a truly optical network, there needs to be mechanisms to
isolate faults (which LMP provides).

Usefulness of LMP is not directly tied to use of link bundles. Link
bundles are mostly used to reduce the flooding of link information
generated by the routing protocol.

Q3) Destination address can be multicast or any valid IP address of
destination node (most likely the NodeID of the destination node).

-----Original Message-----
From: rajesh [mailto:rajesh@tejasnetworks.com]
Sent: Wednesday, July 25, 2001 1:59 AM
To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net;
azinin@cisco.com
Subject: Queries regarding LMP.


Hi,

     Have a few queries regd LMP.

Q1)  Regd the applicability of LMP...

draft-many-gmpls-architecture-00.txt states that

"   For instance, the traditional IP routing model assumes the
   establishment of a routing adjacency over each link connecting two
   adjacent nodes. Having such a large number of adjacencies is not
   scalable at all. Each node needs to maintain each of its adjacencies
   one by one, and link state routing information must be flooded in
   the topology for each link.

   To solve this issue the concept of bundling was introduced.
   Moreover, the manual configuration and control of these links, even
   if they are unnumbered, becomes totally impractical. The Link
   Management Protocol (LMP) was specified to solve these problems. "

a) Can one assume that LMP makes sense ONLY in the case of a large
     number of parallel links and link bundling...

      and an implementation of GMPLS neednot have LMP if no link
      bundling is used ??

      The above maybe the case when using lower end SONET ADM,
       DXCs...

b) Under what other conditions would one require LMP (ie other than
      link bundling) ?

Q2) Suppose one does NOT need to use LMP but then one needs to use
         OSPF extensions to support TE
(draft-kompella-ospf-gmpls-extensions-01.txt) ,

        then one may need to do a  correlation of Link Ids between 2
TE nodes.

       a) Is there a standard recommended way to do this correlation ??

             E.g OSPF - Link Local Signaling
                    or OSPF - link scope LSA ?

Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
         are encoded as IP packets and also suggests protocol number
140.

          What would be the destination IP address of an LMP packet ??

           A multicast or is it got from an IGP ??

Q4) In LMP, if a Link Id correlation has been done,  and If the link ids

         on one of the ends or both change... How is this change taken
into
         account ??

         Eg for i = 1,2
                          Port i, Node 1 connected to Port i, Node 2

          If one interchanges the connection then one has to recorrelate

           the Link Id mappings..

Thanks in advance,
Rajesh



From owner-mpls@UU.NET  Wed Jul 25 12:33: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 MAA08083
	for ; Wed, 25 Jul 2001 12:33: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 QQkzfm19006;
	Wed, 25 Jul 2001 16:34:02 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfm18396
	for mpls-outgoing; Wed, 25 Jul 2001 16:33: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 QQkzfm18335
	for ; Wed, 25 Jul 2001 16:33: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 QQkzfm29082
	for ; Wed, 25 Jul 2001 16:32:51 GMT
Received: from ureach.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.ureach.com [63.150.151.36])
	id QQkzfm17176
	for ; Wed, 25 Jul 2001 16:32:51 GMT
Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49])
	by ureach.com (8.9.1/8.8.5) with ESMTP id MAA19778;
	Wed, 25 Jul 2001 12:32:51 -0400
Received: (from nobody@localhost)
	by www21.ureach.com (8.9.3/8.9.1) id MAA00835;
	Wed, 25 Jul 2001 12:32:51 -0400
Date: Wed, 25 Jul 2001 12:32:51 -0400
Message-Id: <200107251632.MAA00835@www21.ureach.com>
To: "Manoj Agiwal" , "'rsvp@isi.edu'" 
From: Anouk Rocher  
Reply-to: 
Subject: Re: Conversion of Bandwidth to QoS parameters .
cc: "'mpls@UU.NET'" 
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-vsuite-type: e
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Manoj,

I had asked a similar question a few weeks ago (look in the archives).
If you receive anything more detailed do please repost it. But basically
the whole thing boils down to

a) there is no standard/interoperable way of doing this (and while I can't
   speak from direct experience, I will be surprised if any of the 
   interoperability labs test things like this).
b) one approach is to use the standard parameters defined for intserv
   controlled load (or guaranteed service if that suits you better) service
   and the parameters from the TSPEC, ADSPEC and FLOWSPEC that your platform
   can use. Typically bandwidth X will convert to something like Token-rate X.

Anouk.


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


---- On Wed, 25 Jul 2001, Manoj Agiwal (ManojA@netbrahma.com) wrote:

> Hi ,
>         What is the way in which we can convert the bandwidth to QoS
> parameters viz. Traffic Spec Rate , Bucket Size , Peak Rate , Minimum
> Police
> Unit and Maximum Packet Size .
> 
>        When the end user request for reservations he will mention
> Bandwidth
> to be reserved , in case of RSVP-TE reservation will get initiated from
> ingress router . Thus is there any way we can map Bandwidth to QoS
> parameters .
> 
> Regards ,
> Manoj
> 
> 



From owner-mpls@UU.NET  Wed Jul 25 12:36:47 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 MAA08348
	for ; Wed, 25 Jul 2001 12:36: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 QQkzfm29697;
	Wed, 25 Jul 2001 16:37:34 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfm18829
	for mpls-outgoing; Wed, 25 Jul 2001 16:37: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 QQkzfm18810
	for ; Wed, 25 Jul 2001 16:36: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 QQkzfm10466
	for ; Wed, 25 Jul 2001 16:34:59 GMT
Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQkzfm26208
	for ; Wed, 25 Jul 2001 16:34:57 GMT
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f6PGYoC28408;
	Wed, 25 Jul 2001 12:34:50 -0400 (EDT)
Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA24726; Wed, 25 Jul 2001 12:34:48 -0400
Message-ID: <3B5EF51E.B6FBC137@lucent.com>
Date: Wed, 25 Jul 2001 12:34:38 -0400
From: Zhi-Wei Lin 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.77 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin Dubuc 
CC: rajesh@tejasnetworks.com, mpls@UU.NET, jplang@calient.net,
        kireeti@juniper.net, azinin@cisco.com, ccamp@ops.ietf.org
Subject: Re: Queries regarding LMP.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Martin, comments in-line


Martin Dubuc wrote:
> 
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
> control and data link health. To determine whether LMP is useful or not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).

When you say "truly optical network", do you mean a network that has no
O/E/O (no 3R) at all? or is there some 3R at the edge?

As for mechanisms to isolate faults, I think this capability is already
part of networks. For example, SONET has mechanisms such as trace
identifiers, AIS/RDI signals, and tandem connection points for doing
this. OTN (G.709) also has these defined. In addition, OTN has defined 6
flexible layers for TCM and 2 fixed layer for TCM (section and path). 

I think LMP is not necessary for fault isolation, but it could be
another mechanism that may be used (if one so chooses). 

> 
> Usefulness of LMP is not directly tied to use of link bundles. Link
> bundles are mostly used to reduce the flooding of link information
> generated by the routing protocol.
> 
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).
> 
> -----Original Message-----
> From: rajesh [mailto:rajesh@tejasnetworks.com]
> Sent: Wednesday, July 25, 2001 1:59 AM
> To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net;
> azinin@cisco.com
> Subject: Queries regarding LMP.
> 
> Hi,
> 
>      Have a few queries regd LMP.
> 
> Q1)  Regd the applicability of LMP...
> 
> draft-many-gmpls-architecture-00.txt states that
> 
> "   For instance, the traditional IP routing model assumes the
>    establishment of a routing adjacency over each link connecting two
>    adjacent nodes. Having such a large number of adjacencies is not
>    scalable at all. Each node needs to maintain each of its adjacencies
>    one by one, and link state routing information must be flooded in
>    the topology for each link.
> 
>    To solve this issue the concept of bundling was introduced.
>    Moreover, the manual configuration and control of these links, even
>    if they are unnumbered, becomes totally impractical. The Link
>    Management Protocol (LMP) was specified to solve these problems. "
> 
> a) Can one assume that LMP makes sense ONLY in the case of a large
>      number of parallel links and link bundling...
> 
>       and an implementation of GMPLS neednot have LMP if no link
>       bundling is used ??
> 
>       The above maybe the case when using lower end SONET ADM,
>        DXCs...
> 
> b) Under what other conditions would one require LMP (ie other than
>       link bundling) ?
> 
> Q2) Suppose one does NOT need to use LMP but then one needs to use
>          OSPF extensions to support TE
> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
> 
>         then one may need to do a  correlation of Link Ids between 2
> TE nodes.
> 
>        a) Is there a standard recommended way to do this correlation ??
> 
>              E.g OSPF - Link Local Signaling
>                     or OSPF - link scope LSA ?
> 
> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>          are encoded as IP packets and also suggests protocol number
> 140.
> 
>           What would be the destination IP address of an LMP packet ??
> 
>            A multicast or is it got from an IGP ??
> 
> Q4) In LMP, if a Link Id correlation has been done,  and If the link ids
> 
>          on one of the ends or both change... How is this change taken
> into
>          account ??
> 
>          Eg for i = 1,2
>                           Port i, Node 1 connected to Port i, Node 2
> 
>           If one interchanges the connection then one has to recorrelate
> 
>            the Link Id mappings..
> 
> Thanks in advance,
> Rajesh


From owner-mpls@UU.NET  Wed Jul 25 13:22: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 NAA13523
	for ; Wed, 25 Jul 2001 13:22: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 QQkzfp28374;
	Wed, 25 Jul 2001 17:23:44 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfp13562
	for mpls-outgoing; Wed, 25 Jul 2001 17:23: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 QQkzfp13542
	for ; Wed, 25 Jul 2001 17:22: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 QQkzfp22109
	for ; Wed, 25 Jul 2001 17:21:05 GMT
Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged))
	id QQkzfp04235
	for ; Wed, 25 Jul 2001 17:21:05 GMT
Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Jul 2001 10:17:07 -0700
Message-ID: 
From: Jonathan Lang 
To: "'Martin Dubuc'" , rajesh@tejasnetworks.com,
        mpls@UU.NET, Jonathan Lang , kireeti@juniper.net,
        azinin@cisco.com
Cc: ccamp@ops.ietf.org
Subject: RE: Queries regarding LMP.
Date: Wed, 25 Jul 2001 10:17:02 -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

Following up on Martin's comments...

> -----Original Message-----
> From: Martin Dubuc [mailto:martin.dubuc@edgeflow.com]
> Sent: Wednesday, July 25, 2001 8:59 AM
> To: rajesh@tejasnetworks.com; mpls@UU.NET; jplang@calient.net;
> kireeti@juniper.net; azinin@cisco.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: Queries regarding LMP.
> 
> 
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
> control and data link health. To determine whether LMP is useful or not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).
> 
> Usefulness of LMP is not directly tied to use of link bundles. Link
> bundles are mostly used to reduce the flooding of link information
> generated by the routing protocol.
To add further, when GMPLS labels map to physical resources (i.e., ports or
fibers), LMP can be used to exchange these labels so that there is a common
understanding of the mapping.  Even if man ual configuration is used, LMP
provides a mechanism to verify the accuracy (it is not uncommon for manual
configuration to be in error...).

> 
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).
Note that the protocol Id suggestion of 140 has been removed in the latest
version as this value MUST be assigned by IANA.  140 has been used in
interops for the time being, but this shouldn't be considered as the final
protocol id.

Q4) Recorrelation of Link Ids can be done by reverifying the link and/or
resending the LinkSummary message.

Thanks,
Jonathan 

> 
> -----Original Message-----
> From: rajesh [mailto:rajesh@tejasnetworks.com]
> Sent: Wednesday, July 25, 2001 1:59 AM
> To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net;
> azinin@cisco.com
> Subject: Queries regarding LMP.
> 
> 
> Hi,
> 
>      Have a few queries regd LMP.
> 
> Q1)  Regd the applicability of LMP...
> 
> draft-many-gmpls-architecture-00.txt states that
> 
> "   For instance, the traditional IP routing model assumes the
>    establishment of a routing adjacency over each link connecting two
>    adjacent nodes. Having such a large number of adjacencies is not
>    scalable at all. Each node needs to maintain each of its 
> adjacencies
>    one by one, and link state routing information must be flooded in
>    the topology for each link.
> 
>    To solve this issue the concept of bundling was introduced.
>    Moreover, the manual configuration and control of these links, even
>    if they are unnumbered, becomes totally impractical. The Link
>    Management Protocol (LMP) was specified to solve these problems. "
> 
> a) Can one assume that LMP makes sense ONLY in the case of a large
>      number of parallel links and link bundling...
> 
>       and an implementation of GMPLS neednot have LMP if no link
>       bundling is used ??
> 
>       The above maybe the case when using lower end SONET ADM,
>        DXCs...
> 
> b) Under what other conditions would one require LMP (ie other than
>       link bundling) ?
> 
> Q2) Suppose one does NOT need to use LMP but then one needs to use
>          OSPF extensions to support TE
> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
> 
>         then one may need to do a  correlation of Link Ids between 2
> TE nodes.
> 
>        a) Is there a standard recommended way to do this 
> correlation ??
> 
>              E.g OSPF - Link Local Signaling
>                     or OSPF - link scope LSA ?
> 
> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>          are encoded as IP packets and also suggests protocol number
> 140.
> 
>           What would be the destination IP address of an LMP packet ??
> 
>            A multicast or is it got from an IGP ??
> 
> Q4) In LMP, if a Link Id correlation has been done,  and If 
> the link ids
> 
>          on one of the ends or both change... How is this change taken
> into
>          account ??
> 
>          Eg for i = 1,2
>                           Port i, Node 1 connected to Port i, Node 2
> 
>           If one interchanges the connection then one has to 
> recorrelate
> 
>            the Link Id mappings..
> 
> Thanks in advance,
> Rajesh
> 


From owner-mpls@UU.NET  Wed Jul 25 13:59: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 NAA17095
	for ; Wed, 25 Jul 2001 13:59: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 QQkzfr21604;
	Wed, 25 Jul 2001 17:59:59 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfr17770
	for mpls-outgoing; Wed, 25 Jul 2001 17:59: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 QQkzfr17749
	for ; Wed, 25 Jul 2001 17:59: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 QQkzfr22250
	for ; Wed, 25 Jul 2001 17:59:15 GMT
Received: from crag.netrotech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: user-112v9a2.biz.mindspring.com [66.47.165.66])
	id QQkzfr03341
	for ; Wed, 25 Jul 2001 17:59:14 GMT
Received: (from jmuston@localhost)
	by crag.netrotech.com (8.9.3/8.9.3/Debian 8.9.3-21) id NAA18384;
	Wed, 25 Jul 2001 13:16:03 -0500
From: John Muston 
Date: Wed, 25 Jul 2001 13:16:03 -0500
To: "Thomas D. Nadeau" 
Cc: Joan Cucchiara , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Message-ID: <20010725131603.A18317@netrotech.com>
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com> <3B5E0519.A528B34B@crescentnetworks.com> <4.3.2.7.2.20010725091917.02169d20@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4.3.2.7.2.20010725091917.02169d20@bucket.cisco.com>; from tnadeau@cisco.com on Wed, Jul 25, 2001 at 09:25:07AM -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Jul 25, 2001 at 09:25:07AM -0400, Thomas D. Nadeau wrote:
> At 07:30 PM 7/24/2001 -0400, Joan Cucchiara wrote:
> 
> 
> >"Thomas D. Nadeau" wrote:
> > >
> > > >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> > > >stack is shown as:
> > > >
> > > >         +------------------------------------------------+
> > > >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> > > >         +------------------------------------------------+
> > > >         |        MPLS-interface ifType = mpls(166)       |
> > > >         +------------------------------------------------+
> > > >         |               Underlying Layer                 |
> > > >         +------------------------------------------------+
> >
> >
> >Hi Tom,
> >
> >Is it possible to have more than one Underlying Layer?
> >Should the above be changed to "Underlying Layer(s)"?
> 
>          Yes. You are correct. Nice catch. Since it is
> possible to have more than one LSP servicing
> the tunnel, there could be multiple underlying interfaces.

I thought that an mplsTunnelEntry refers to a single mplsXCTable row
(via the mplsTunnelXCPointer), which in turn describes a single LSP.
What am I missing?

If there were multiple LSPs under a tunnel, wouldn't that mean multiple
MPLS-iftype interfaces under an mplsTunnel-iftype interface, not
necessarily multiple layers below the MPLS-iftype interface?

Though I can see having multiple layers below the MPLS-iftype interface
in cases like TE Link Bundling though.

-John


From owner-mpls@UU.NET  Wed Jul 25 14:28:30 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 OAA20217
	for ; Wed, 25 Jul 2001 14:28:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzft07158;
	Wed, 25 Jul 2001 18:29:15 GMT
Received: by mail-control.mail.uu.net 
	id QQkzft10449
	for mpls-outgoing; Wed, 25 Jul 2001 18:28:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzft10417
	for ; Wed, 25 Jul 2001 18:28: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 QQkzft26865
	for ; Wed, 25 Jul 2001 18:28:00 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 QQkzft04687
	for ; Wed, 25 Jul 2001 18:28:00 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA10507 for mpls@uu.net; Wed, 25 Jul 2001 14:27:59 -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 QQkzft10341
	for ; Wed, 25 Jul 2001 18:27: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 QQkzft23711
	for ; Wed, 25 Jul 2001 18:26:47 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQkzft03213
	for ; Wed, 25 Jul 2001 18:26:46 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 OAA14040; Wed, 25 Jul 2001 14:26:37 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEE10337;
	Wed, 25 Jul 2001 14:26:35 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010725141224.021573a0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Jul 2001 14:32:02 -0400
To: John Muston 
From: "Thomas D. Nadeau" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Cc: Joan Cucchiara , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
In-Reply-To: <20010725131603.A18317@netrotech.com>
References: <4.3.2.7.2.20010725091917.02169d20@bucket.cisco.com>
 <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com>
 <3B5E0519.A528B34B@crescentnetworks.com>
 <4.3.2.7.2.20010725091917.02169d20@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 01:16 PM 7/25/2001 -0500, John Muston wrote:
>On Wed, Jul 25, 2001 at 09:25:07AM -0400, Thomas D. Nadeau wrote:
> > At 07:30 PM 7/24/2001 -0400, Joan Cucchiara wrote:
> >
> >
> > >"Thomas D. Nadeau" wrote:
> > > >
> > > > >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> > > > >stack is shown as:
> > > > >
> > > > >         +------------------------------------------------+
> > > > >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> > > > >         +------------------------------------------------+
> > > > >         |        MPLS-interface ifType = mpls(166)       |
> > > > >         +------------------------------------------------+
> > > > >         |               Underlying Layer                 |
> > > > >         +------------------------------------------------+
> > >
> > >
> > >Hi Tom,
> > >
> > >Is it possible to have more than one Underlying Layer?
> > >Should the above be changed to "Underlying Layer(s)"?
> >
> >          Yes. You are correct. Nice catch. Since it is
> > possible to have more than one LSP servicing
> > the tunnel, there could be multiple underlying interfaces.
>
>I thought that an mplsTunnelEntry refers to a single mplsXCTable row
>(via the mplsTunnelXCPointer), which in turn describes a single LSP.
>What am I missing?

         Not necessarily. Remember that the XC pointer can refer to a
"group" of in/out segments. For example, if you were doing some
sort of load sharing with your LSP, so that multiple paths met
the constraints of the tunnel, it would be possible to share
these paths. These paths might run over different outgoing
interfaces (mpls) or physical (underlying layer), depending on
how the mpls interfaces are stacked upon what lies under them.
For example, the tunnel1 below uses 1 XC pointer, but this
XC index specifies 2 outgoing labels which run over two
different outgoing MPLS interfaces, which in-turn run
over two different ethernet interfaces:

         mplsTunnel1->mplsInterface1->enet3
                    ->mplsInterface2->enet4

You can also have a case where the tunnel1 uses 1 XC pointer,
its XC index specifies 2 outgoing labels which run over ONE
outgoing MPLS interface, which in-turn runs over
one ethernet interface:

         mplsTunnel1->mplsInterface1->enet3
                    ->mplsInterface2->enet3

         I think that in the majority of cases, however, the
stacking situation will be the intuitive, one-to-one
scenario:

         mplsTunnel1->mplsInterface1->enet

>If there were multiple LSPs under a tunnel, wouldn't that mean multiple
>MPLS-iftype interfaces under an mplsTunnel-iftype interface, not
>necessarily multiple layers below the MPLS-iftype interface?
>
>Though I can see having multiple layers below the MPLS-iftype interface
>in cases like TE Link Bundling though.

         Yes.

         --Tom




>-John



From owner-mpls@UU.NET  Wed Jul 25 14:55: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 OAA23115
	for ; Wed, 25 Jul 2001 14:55: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 QQkzfv16991;
	Wed, 25 Jul 2001 18:56:30 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfv13972
	for mpls-outgoing; Wed, 25 Jul 2001 18:55: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 QQkzfv13959
	for ; Wed, 25 Jul 2001 18:55:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzfv15092
	for ; Wed, 25 Jul 2001 18:55:08 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 QQkzfv13962
	for ; Wed, 25 Jul 2001 18:54:23 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 f6PIpJl28180;
	Wed, 25 Jul 2001 14:51:19 -0400 (EDT)
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <3T8RDAV4>; Wed, 25 Jul 2001 14:54:31 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D02204040198240F@mail1.tellium.com>
From: Bala Rajagopalan 
To: "'lyndon_ong@eudoramail.com'" 
Cc: rajesh@tejasnetworks.com, mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: Queries regarding LMP.
Date: Wed, 25 Jul 2001 14:54: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


Hello,

> -----Original Message-----
> From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com]
> Hi,
> 
>> By the same token, is there really a need for fast keep-alive 
> for all situations, esp. for in-band DCC control channels 
> where there is a link layer protocol in use that can monitor 
> control link health?  Keep-alive is just further overhead in 
> that situation, especially when there may be hellos in the 
> signaling and routing protocols going on at the same time.

For in-band DCC, the SONET/SDH procedures can help in
detecting link down situation. However, a keep-alive also tells
if the neighbor discovery process running is up or down. Perhaps
 the neighbor discovery Hello messages can be sent over a 
coarser time period. W.r.t routing
protocols, the idea is not to create an IGP adjacency over
each link (and hence no IGP hello over each link).


Regards,

Bala


From owner-mpls@UU.NET  Wed Jul 25 16:15: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 QAA02676
	for ; Wed, 25 Jul 2001 16:15: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 QQkzgb10099;
	Wed, 25 Jul 2001 20:16:34 GMT
Received: by mail-control.mail.uu.net 
	id QQkzgb01693
	for mpls-outgoing; Wed, 25 Jul 2001 20:15: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 QQkzgb01653
	for ; Wed, 25 Jul 2001 20:15:28 GMT
Received: from pmismtp04.wcomnet.com by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pmismtp04.wcomnet.com [166.38.62.39])
	id QQkzgb29348
	for ; Wed, 25 Jul 2001 20:15:16 GMT
Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 id <0GH100G01PLFOB@pmismtp04.wcomnet.com> for mpls@UU.NET; Wed,
 25 Jul 2001 20:15:15 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GH100F01PJHZN@pmismtp04.wcomnet.com> for
 mpls@UU.NET; Wed, 25 Jul 2001 20:15:14 +0000 (GMT)
Received: from lyao ([166.60.19.230])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0GH100E98PIX7K@pmismtp04.wcomnet.com>; Wed,
 25 Jul 2001 20:13:47 +0000 (GMT)
Date: Wed, 25 Jul 2001 15:56:04 -0400
From: Lei Yao 
Subject: RE: Conversion of Bandwidth to QoS parameters .
In-reply-to: <200107251632.MAA00835@www21.ureach.com>
To: anouk@ureach.com, Manoj Agiwal , rsvp@isi.edu
Cc: mpls@UU.NET
Reply-to: lei.yao@wcom.com
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.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

We did raise concern on this. See the following draft:
- draft-mcdysan-diffserv-consistent-meter-00.txt

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anouk
Rocher
Sent: Wednesday, July 25, 2001 12:33 PM
To: Manoj Agiwal; 'rsvp@isi.edu'
Cc: 'mpls@UU.NET'
Subject: Re: Conversion of Bandwidth to QoS parameters .


Manoj,

I had asked a similar question a few weeks ago (look in the archives).
If you receive anything more detailed do please repost it. But basically
the whole thing boils down to

a) there is no standard/interoperable way of doing this (and while I can't
   speak from direct experience, I will be surprised if any of the
   interoperability labs test things like this).
b) one approach is to use the standard parameters defined for intserv
   controlled load (or guaranteed service if that suits you better) service
   and the parameters from the TSPEC, ADSPEC and FLOWSPEC that your platform
   can use. Typically bandwidth X will convert to something like Token-rate
X.

Anouk.


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


---- On Wed, 25 Jul 2001, Manoj Agiwal (ManojA@netbrahma.com) wrote:

> Hi ,
>         What is the way in which we can convert the bandwidth to QoS
> parameters viz. Traffic Spec Rate , Bucket Size , Peak Rate , Minimum
> Police
> Unit and Maximum Packet Size .
>
>        When the end user request for reservations he will mention
> Bandwidth
> to be reserved , in case of RSVP-TE reservation will get initiated from
> ingress router . Thus is there any way we can map Bandwidth to QoS
> parameters .
>
> Regards ,
> Manoj
>
>



From owner-mpls@UU.NET  Wed Jul 25 16:32: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 QAA04409
	for ; Wed, 25 Jul 2001 16:32:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzfu20298;
	Wed, 25 Jul 2001 18:39:01 GMT
Received: by mail-control.mail.uu.net 
	id QQkzfu11696
	for mpls-outgoing; Wed, 25 Jul 2001 18:38:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzfu11687
	for ; Wed, 25 Jul 2001 18: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 QQkzfu24782
	for ; Wed, 25 Jul 2001 18:37:17 GMT
Received: from shared1-mail.whowhere.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: shared1-batch.whowhere.com [209.185.123.82])
	id QQkzfu19403
	for ; Wed, 25 Jul 2001 18:37:16 GMT
Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Wed Jul 25 11:36:49 2001
To: "Martin Dubuc" ,
        "Zhi-Wei Lin" 
Date: Wed, 25 Jul 2001 11:36:49 -0700
From: "Lyndon Ong" 
Message-ID: 
Mime-Version: 1.0
Cc: rajesh@tejasnetworks.com, mpls@UU.NET, jplang@calient.net,
        kireeti@juniper.net, azinin@cisco.com, ccamp@ops.ietf.org
X-Sent-Mail: off
Reply-To: lyndon_ong@eudoramail.com
X-Mailer: MailCity Service
Subject: Re: Queries regarding LMP.
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail  (http://www.eudoramail.com:80) 
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I thought that this was why the fault localization piece of LMP was made negotiable, since it was not necessary to support this in opaque networks.

By the same token, is there really a need for fast keep-alive for all situations, esp. for in-band DCC control channels where there is a link layer protocol in use that can monitor control link health?  Keep-alive is just further overhead in that situation, especially when there may be hellos in the signaling and routing protocols going on at the same time.

Cheers,

Lyndon

--

On Wed, 25 Jul 2001 12:34:38   Zhi-Wei Lin wrote:
>Hi Martin, comments in-line
>
>
>Martin Dubuc wrote:
>> 
>> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
>> control and data link health. To determine whether LMP is useful or not,
>> one has to look at the operational aspect of product deployment and
>> maintenance, i.e. what tools the vendor wants to implement to facilitate
>> provisioning and maintenance of their customers network. In a small
>> network, a vendor may be able to get away with manual configuration of
>> links. In an opaque network, it is also easy to pinpoint link failures.
>> However, in a truly optical network, there needs to be mechanisms to
>> isolate faults (which LMP provides).
>
>When you say "truly optical network", do you mean a network that has no
>O/E/O (no 3R) at all? or is there some 3R at the edge?
>
>As for mechanisms to isolate faults, I think this capability is already
>part of networks. For example, SONET has mechanisms such as trace
>identifiers, AIS/RDI signals, and tandem connection points for doing
>this. OTN (G.709) also has these defined. In addition, OTN has defined 6
>flexible layers for TCM and 2 fixed layer for TCM (section and path). 
>
>I think LMP is not necessary for fault isolation, but it could be
>another mechanism that may be used (if one so chooses). 
>
>> 
>> Usefulness of LMP is not directly tied to use of link bundles. Link
>> bundles are mostly used to reduce the flooding of link information
>> generated by the routing protocol.
>> 
>> Q3) Destination address can be multicast or any valid IP address of
>> destination node (most likely the NodeID of the destination node).
>> 
>> -----Original Message-----
>> From: rajesh [mailto:rajesh@tejasnetworks.com]
>> Sent: Wednesday, July 25, 2001 1:59 AM
>> To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net;
>> azinin@cisco.com
>> Subject: Queries regarding LMP.
>> 
>> Hi,
>> 
>>      Have a few queries regd LMP.
>> 
>> Q1)  Regd the applicability of LMP...
>> 
>> draft-many-gmpls-architecture-00.txt states that
>> 
>> "   For instance, the traditional IP routing model assumes the
>>    establishment of a routing adjacency over each link connecting two
>>    adjacent nodes. Having such a large number of adjacencies is not
>>    scalable at all. Each node needs to maintain each of its adjacencies
>>    one by one, and link state routing information must be flooded in
>>    the topology for each link.
>> 
>>    To solve this issue the concept of bundling was introduced.
>>    Moreover, the manual configuration and control of these links, even
>>    if they are unnumbered, becomes totally impractical. The Link
>>    Management Protocol (LMP) was specified to solve these problems. "
>> 
>> a) Can one assume that LMP makes sense ONLY in the case of a large
>>      number of parallel links and link bundling...
>> 
>>       and an implementation of GMPLS neednot have LMP if no link
>>       bundling is used ??
>> 
>>       The above maybe the case when using lower end SONET ADM,
>>        DXCs...
>> 
>> b) Under what other conditions would one require LMP (ie other than
>>       link bundling) ?
>> 
>> Q2) Suppose one does NOT need to use LMP but then one needs to use
>>          OSPF extensions to support TE
>> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
>> 
>>         then one may need to do a  correlation of Link Ids between 2
>> TE nodes.
>> 
>>        a) Is there a standard recommended way to do this correlation ??
>> 
>>              E.g OSPF - Link Local Signaling
>>                     or OSPF - link scope LSA ?
>> 
>> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>>          are encoded as IP packets and also suggests protocol number
>> 140.
>> 
>>           What would be the destination IP address of an LMP packet ??
>> 
>>            A multicast or is it got from an IGP ??
>> 
>> Q4) In LMP, if a Link Id correlation has been done,  and If the link ids
>> 
>>          on one of the ends or both change... How is this change taken
>> into
>>          account ??
>> 
>>          Eg for i = 1,2
>>                           Port i, Node 1 connected to Port i, Node 2
>> 
>>           If one interchanges the connection then one has to recorrelate
>> 
>>            the Link Id mappings..
>> 
>> Thanks in advance,
>> Rajesh
>
>


Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com


From owner-mpls@UU.NET  Wed Jul 25 19:49: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 TAA22383
	for ; Wed, 25 Jul 2001 19:49: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 QQkzgp04067;
	Wed, 25 Jul 2001 23:50:33 GMT
Received: by mail-control.mail.uu.net 
	id QQkzgp20579
	for mpls-outgoing; Wed, 25 Jul 2001 23:49:52 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 QQkzgp20561
	for ; Wed, 25 Jul 2001 23:49: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 QQkzgp20121
	for ; Wed, 25 Jul 2001 23:48:54 GMT
Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.186.47.7])
	id QQkzgp25483
	for ; Wed, 25 Jul 2001 23:48:53 GMT
Received: by newmail.coronanetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Jul 2001 16:50:23 -0700
Message-ID: 
From: Brijesh Kumar 
To: Ping Pan , mpls-list 
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Date: Wed, 25 Jul 2001 16:50:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C11564.91BC1560"
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_01C11564.91BC1560
Content-Type: text/plain;
	charset="iso-8859-1"


From this draft:

   When the ingress LSR suspects that the LSP may have failed and the
   RSVP control plane shows the LSP as operational, the ingress LSR MUST
   send LSP-ping messages to the egress over the LSP, periodically.  The
   value of the time interval should be configurable.


Could you please tell me what do you mean by "LSR suspects"? In other words,

what is the triggering input for LSR to start "suspecting" the LSP may have
failed?

It will be better if you replace "suspect" with "detect" in your draft as
suspect is an imprecise human emotion and no operator would like routers
that have negative emotions ;-). 

In addition, I do have issues with introducing a mechanism dependent on a
particular signalling protocol for a generic problem - testing liveness of
the label switched data path. Secondly, can we have some input/justification
with regards to the assumption that there is a need to detect such a failure
since only cause for such a failure given in the draft is "memory
Corruption". What causes so called memory corruption? Are we trying to
repair badly written code here?

Cheers,


--brijesh
Corona Networks Inc.


> -----Original Message-----
> From: Ping Pan [mailto:pingpan@juniper.net]
> Sent: Wednesday, July 25, 2001 8:54 AM
> To: mpls-list
> Subject: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> 
> 
> Hi,
> 
> Here is an updated version of LSP-ping. We have taken the suggestions
> from George and Sanjay.
> 
> Thanks!
> 
> - Ping
> 

------_=_NextPart_001_01C11564.91BC1560
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]






From this draft:




   When the ingress LSR suspects that the =
LSP may have failed and the

   RSVP control plane shows the LSP as =
operational, the ingress LSR MUST

   send LSP-ping messages to the egress =
over the LSP, periodically.  The

   value of the time interval should be =
configurable.






Could you please tell me what do you mean by =
"LSR suspects"? In other words, 

what is the triggering input for LSR to start =
"suspecting" the LSP may have failed?




It will be better if you replace "suspect" =
with "detect" in your draft as suspect is an imprecise human =
emotion and no operator would like routers that have negative emotions =
;-). 



In addition, I do have issues with introducing a =
mechanism dependent on a particular signalling protocol for a generic =
problem - testing liveness of the label switched data path. Secondly, =
can we have some input/justification with regards to the assumption =
that there is a need to detect such a failure since only cause for such =
a failure given in the draft is "memory Corruption". What =
causes so called memory corruption? Are we trying to repair badly =
written code here?



Cheers,






--brijesh

Corona Networks Inc.






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

> From: Ping Pan [mailto:pingpan@juniper.net]

> Sent: Wednesday, July 25, 2001 8:54 AM

> To: mpls-list

> Subject: [Fwd: I-D =
ACTION:draft-pan-lsp-ping-01.txt]

> 

> 

> Hi,

> 

> Here is an updated version of LSP-ping. We have =
taken the suggestions

> from George and Sanjay.

> 

> Thanks!

> 

> - Ping

> 





------_=_NextPart_001_01C11564.91BC1560--


From owner-mpls@UU.NET  Wed Jul 25 20:25: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 UAA24374
	for ; Wed, 25 Jul 2001 20:25: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 QQkzgr22466;
	Thu, 26 Jul 2001 00:26:04 GMT
Received: by mail-control.mail.uu.net 
	id QQkzgr12869
	for mpls-outgoing; Thu, 26 Jul 2001 00:25: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 QQkzgr12862
	for ; Thu, 26 Jul 2001 00:25: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 QQkzgr06001
	for ; Thu, 26 Jul 2001 00:24:41 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 QQkzgr29795
	for ; Thu, 26 Jul 2001 00:24:41 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA06346 for mpls@uu.net; Wed, 25 Jul 2001 20:24:40 -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 QQkzgr12765
	for ; Thu, 26 Jul 2001 00:23: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 QQkzgr00656
	for ; Thu, 26 Jul 2001 00:22:32 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQkzgr19956
	for ; Thu, 26 Jul 2001 00:22:26 GMT
Received: from juniper.net (panther.juniper.net [172.17.12.226])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6Q0MPH16157;
	Wed, 25 Jul 2001 17:22:26 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B5F62C1.2ED35809@juniper.net>
Date: Wed, 25 Jul 2001 17:22:25 -0700
From: Ping Pan 
Organization: Juniper Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Brijesh Kumar 
CC: mpls-list 
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> Brijesh Kumar wrote:
> 
> From this draft:
> 
>    When the ingress LSR suspects that the LSP may have failed and the
>    RSVP control plane shows the LSP as operational, the ingress LSR
> MUST
>    send LSP-ping messages to the egress over the LSP, periodically.
> The
>    value of the time interval should be configurable.
> 
> Could you please tell me what do you mean by "LSR suspects"? In other
> words,
> what is the triggering input for LSR to start "suspecting" the LSP may
> have failed?
> 
> It will be better if you replace "suspect" with "detect" in your draft
> as suspect is an imprecise human emotion and no operator would like
> routers that have negative emotions ;-).
> 

It's network operators suspect something may have gone wrong with some
LSP's....

> In addition, I do have issues with introducing a mechanism dependent
> on a particular signalling protocol for a generic problem - testing
> liveness of the label switched data path. 

OK. Do you have problem with the mechanism itself?

> Secondly, can we have some
> input/justification with regards to the assumption that there is a
> need to detect such a failure since only cause for such a failure
> given in the draft is "memory Corruption". What causes so called
> memory corruption? Are we trying to repair badly written code here?
> 

The problem did happen in the real network. I'm not going to point
fingers on the cause of the problem. But we (vendors and providers) did
realize from that incidence that we need to have a simple mechanism to
check LSP's data plane in today's operational networks.

The whole purpose on various proposals (fast reroute, graceful restart
and LSP-ping) is to make the whole network working nicely, even when we
have routers from other vendors that have badly written code.

- Ping



From owner-mpls@UU.NET  Thu Jul 26 00:32: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 AAA10833
	for ; Thu, 26 Jul 2001 00:32: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 QQkzhi21836;
	Thu, 26 Jul 2001 04:33:11 GMT
Received: by mail-control.mail.uu.net 
	id QQkzhi21074
	for mpls-outgoing; Thu, 26 Jul 2001 04:32: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 QQkzhi21053
	for ; Thu, 26 Jul 2001 04:32:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzhi28149
	for ; Thu, 26 Jul 2001 04:31:30 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQkzhi24717
	for ; Thu, 26 Jul 2001 04:31:28 GMT
Received: from multitech.co.in ([192.168.1.32])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6Q4Qen28171;
	Thu, 26 Jul 2001 09:56:40 +0530
Message-ID: <3B5F9DEB.87AACB0@multitech.co.in>
Date: Thu, 26 Jul 2001 10:04:51 +0530
From: abhay 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" 
CC: John Muston , mpls@UU.NET,
        Cheenu Srinivasan ,
        "Arun Viswanathan (E-mail)" 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
X-Priority: 2 (High)
References: <4.3.2.7.2.20010724142943.02886628@bucket.cisco.com> <4.3.2.7.2.20010725093431.02190e08@bucket.cisco.com>
Content-Type: multipart/alternative;
 boundary="------------61484D2989C7202132ABC70E"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------61484D2989C7202132ABC70E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

    Thanks for the assurance...

    Reminds me of after sales service....LOL,;)

    Regards,

    Abhay

"Thomas D. Nadeau" wrote:

>          Hi,
>
> >     This new explanation would have helped me sometime ago,
> >     It did take a while for me to get  what you were saying then.
> >     Better late than never..8)
>
>          Glad to have helped. In the future, please speak up if
> something is unclear, since if it is unclear to you, there
> are probably lots of others that it is unclear to as well. 8)
>
>          --Tom
>
> >     Thanks
> >
> >     Regards,
> >
> >     Abhay
> >
> >
> >"Thomas D. Nadeau" wrote:
> >> >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> >> >stack is shown as:
> >> >
> >> >         +------------------------------------------------+
> >> >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> >> >         +------------------------------------------------+
> >> >         |        MPLS-interface ifType = mpls(166)       |
> >> >         +------------------------------------------------+
> >> >         |               Underlying Layer                 |
> >> >         +------------------------------------------------+
> >> >
> >> >It is not clear to me how the particular lower layer of the tunnel
> >> >interface is chosen.
> >> >
> >> >In the case of a tunnel interface created but not yet signalled, I
> >> >imagine it would be layered over nothing (ifindex 0).
> >> >
> >> >Once signalled, would it be the mplsOutSegmentIfIndex of the
> >> >tunnel's underlying cross connect?
> >> >
> >> >If so, I assume a rerouted tunnel, since it might have a different egress
> >> >interface, might need to be restacked onto a different interface.
> >> >
> >> >Should a tunnel also be layered over the mplsInSegmentIfIndex (if
> >> >nonzero)?
> >>
> >>          Sorry for the confusion. The text in the draft needs
> >>a few sentences to clarify. Something like this:
> >>
> >>          In the case where the tunnel interface is
> >>present at the head-end of the tunnel, the
> >>tunnel interface should be stacked upon the
> >>outgoing MPLS interface.  In the case where
> >>the tunnel interface is optionally represented
> >>at the egress of the tunnel as well, it
> >>should be stacked upon the incoming MPLS
> >>interface. If the tunnel interface has been created,
> >>but no LSP has been signaled for the tunnel,
> >>the tunnel should not be stacked upon any underlying
> >>interface. If the tunnel's underlying LSP is
> >>changed, then the interface stacking should be
> >>changed accordingly to the new MPLS interface
> >>as described above.
> >>
> >>          --Tom

--------------61484D2989C7202132ABC70E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Tom,



    Thanks for the assurance...



    Reminds me of after sales service....LOL,;)



    Regards,



    Abhay




"Thomas D. Nadeau" wrote:

        
Hi,

>     This new explanation would have helped me
sometime ago,

>     It did take a while for me to get  what
you were saying then.

>     Better late than never..8)

         Glad to have helped.
In the future, please speak up if

something is unclear, since if it is unclear to you, there

are probably lots of others that it is unclear to as well. 8)

         --Tom

>     Thanks

>

>     Regards,

>

>     Abhay

>

>

>"Thomas D. Nadeau" wrote:

>> >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface

>> >stack is shown as:

>> >

>> >         +------------------------------------------------+

>> >         | MPLS-Tunnel-interface
ifType = mplsTunnel(150) |

>> >         +------------------------------------------------+

>> >         |       
MPLS-interface ifType = mpls(166)       |

>> >         +------------------------------------------------+

>> >         |              
Underlying Layer                
|

>> >         +------------------------------------------------+

>> >

>> >It is not clear to me how the particular lower layer of the tunnel

>> >interface is chosen.

>> >

>> >In the case of a tunnel interface created but not yet signalled,
I

>> >imagine it would be layered over nothing (ifindex 0).

>> >

>> >Once signalled, would it be the mplsOutSegmentIfIndex of the

>> >tunnel's underlying cross connect?

>> >

>> >If so, I assume a rerouted tunnel, since it might have a different
egress

>> >interface, might need to be restacked onto a different interface.

>> >

>> >Should a tunnel also be layered over the mplsInSegmentIfIndex (if

>> >nonzero)?

>>

>>          Sorry for
the confusion. The text in the draft needs

>>a few sentences to clarify. Something like this:

>>

>>          In the case
where the tunnel interface is

>>present at the head-end of the tunnel, the

>>tunnel interface should be stacked upon the

>>outgoing MPLS interface.  In the case where

>>the tunnel interface is optionally represented

>>at the egress of the tunnel as well, it

>>should be stacked upon the incoming MPLS

>>interface. If the tunnel interface has been created,

>>but no LSP has been signaled for the tunnel,

>>the tunnel should not be stacked upon any underlying

>>interface. If the tunnel's underlying LSP is

>>changed, then the interface stacking should be

>>changed accordingly to the new MPLS interface

>>as described above.

>>

>>          --Tom



--------------61484D2989C7202132ABC70E--



From owner-mpls@UU.NET  Thu Jul 26 00:58: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 AAA11745
	for ; Thu, 26 Jul 2001 00:58: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 QQkzhj12370;
	Thu, 26 Jul 2001 04:59:17 GMT
Received: by mail-control.mail.uu.net 
	id QQkzhj22942
	for mpls-outgoing; Thu, 26 Jul 2001 04:58: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 QQkzhj22927
	for ; Thu, 26 Jul 2001 04:58: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 QQkzhj01189
	for ; Thu, 26 Jul 2001 04:58:11 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzhj29409
	for ; Thu, 26 Jul 2001 04:58:06 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Jul 2001 10:25:52 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BAB7@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'mpls@UU.NET'" 
Subject: Doubts about MPLS-TE Mib
Date: Thu, 26 Jul 2001 10:25:49 +0530
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 have a few doubts about the MPLS-TE Mib.
Please note that the doubts are with regards to usage of RSVP-TE as the
signalling mechanism .

1. There are three similar objects in the mplsTunnelTable ....
mplsTunnelIndex , mplsTunnelInstance , mplsTunnelPrimaryInstance  .
 According to my understanding , mplsTunnelIndex is the same as the TunnelId
in the Session object .
 But how does mplsTunnelInstance and mplsTunnelPrimaryInstance fit into
RSVP-Te ?
 Are they outside the scope of RSVP-Te ?
 Or do they refer to LspIds of primary and secondary Lsps ? 

2. the object mplsTunnelIngressId is defined to be used as the
ExtendedTunnelId .
 But then where will the SenderTemplate object's Sender IP address come from
?

3. What is the difference between ARHopTable and CHop Table ?
   Do they refer to incoming and updated EROs ?

Thanks in advance
Apratim 


From owner-mpls@UU.NET  Thu Jul 26 01:57: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 BAA20097
	for ; Thu, 26 Jul 2001 01:57: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 QQkzhn09120;
	Thu, 26 Jul 2001 05:58:44 GMT
Received: by mail-control.mail.uu.net 
	id QQkzhn16952
	for mpls-outgoing; Thu, 26 Jul 2001 05:58: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 QQkzhn16936
	for ; Thu, 26 Jul 2001 05:58: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 QQkzhn19929
	for ; Thu, 26 Jul 2001 05:57:11 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQkzhn26408
	for ; Thu, 26 Jul 2001 05:57:08 GMT
Received: from multitech.co.in ([192.168.1.32])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6Q5qnn32148;
	Thu, 26 Jul 2001 11:22:49 +0530
Message-ID: <3B5FB224.BFC595B7@multitech.co.in>
Date: Thu, 26 Jul 2001 11:31:08 +0530
From: abhay 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Apratim Mukherjee 
CC: "'mpls@UU.NET'" 
Subject: Re: Doubts about MPLS-TE Mib
References: <13D467F625FAD511AE2A00D0B7B917D706BAB7@mailserver.netbrahma.com>
Content-Type: multipart/alternative;
 boundary="------------BBAD3959A35231D75D49C08D"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------BBAD3959A35231D75D49C08D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Arpatim Mukherjee,

You Asked....

*1. There are three similar objects in the mplsTunnelTable ....
*mplsTunnelIndex , mplsTunnelInstance , mplsTunnelPrimaryInstance  .
 *According to my understanding , mplsTunnelIndex is the same as the TunnelId
*in the Session object .
* But how does mplsTunnelInstance and mplsTunnelPrimaryInstance fit into
*RSVP-Te ?
* Are they outside the scope of RSVP-Te ?
* Or do they refer to LspIds of primary and secondary Lsps ?

                 If you are using RSVP-TE,you can have the following mapping:

                 1) mplsTunnelIndex -> Tunnel ID carried by RSVP

                 2) mplsTunnelInstance -> LSP ID carred by RSVP

                 mplsTunnelPrimaryInstance can be the LSP ID of the primary tunnel.

                 They are very much in scope with RSVP-TE



You asked....

> 2. the object mplsTunnelIngressId is defined to be used as the
> ExtendedTunnelId .
>  But then where will the SenderTemplate object's Sender IP address come from
> ?
>

I beleive it can be the same as the TunnelIngressID

You asked...

>
> 3. What is the difference between ARHopTable and CHop Table ?
>    Do they refer to incoming and updated EROs ?
>
> Thanks in advance
> Apratim

ARHopTable records the actual route taken by the LSP,which may be different from the specified one

and CHopTable contains entries which are populated with CSPF Calculated paths.

However both these tables are optional,if you dont have the RRO support in signaling and CSPF Module

to have Constraint based SPF's.

Regards,

Abhay

--------------BBAD3959A35231D75D49C08D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Arpatim Mukherjee,



You Asked....

*1. There are three similar objects in the mplsTunnelTable ....

*mplsTunnelIndex , mplsTunnelInstance , mplsTunnelPrimaryInstance 
.

 *According to my understanding , mplsTunnelIndex is the same
as the TunnelId

*in the Session object .

* But how does mplsTunnelInstance and mplsTunnelPrimaryInstance fit
into

*RSVP-Te ?

* Are they outside the scope of RSVP-Te ?

* Or do they refer to LspIds of primary and secondary Lsps ?

                 If you are using RSVP-TE,you can have the following mapping:



                 1) mplsTunnelIndex -> Tunnel ID carried by RSVP



                 2) mplsTunnelInstance -> LSP ID carred by RSVP



                 mplsTunnelPrimaryInstance can be the LSP ID of the primary tunnel.



                 They are very much in scope with RSVP-TE



 



You asked....



2. the object mplsTunnelIngressId is defined to be
used as the

ExtendedTunnelId .

 But then where will the SenderTemplate object's Sender IP address
come from

?

 



I beleive it can be the same as the TunnelIngressID






You asked...






 

3. What is the difference between ARHopTable and CHop Table ?

   Do they refer to incoming and updated EROs ?

Thanks in advance

Apratim



ARHopTable records the actual route taken by the LSP,which may be different from the specified one



and CHopTable contains entries which are populated with CSPF Calculated paths.



However both these tables are optional,if you dont have the RRO support in signaling and CSPF Module



to have Constraint based SPF's.



Regards,



Abhay



--------------BBAD3959A35231D75D49C08D--



From owner-mpls@UU.NET  Thu Jul 26 11:30:26 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 LAA17918
	for ; Thu, 26 Jul 2001 11:30: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 QQkziu15615;
	Thu, 26 Jul 2001 14:14:39 GMT
Received: by mail-control.mail.uu.net 
	id QQkziu18811
	for mpls-outgoing; Thu, 26 Jul 2001 14:14: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 QQkziu18803
	for ; Thu, 26 Jul 2001 14:14: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 QQkziu05135
	for ; Thu, 26 Jul 2001 14:13:44 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkziu14197
	for ; Thu, 26 Jul 2001 14:13:42 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Jul 2001 19:41:28 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BAB9@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'mpls@UU.NET'" , "'Thomas D. Nadeau'"
	 
Subject: RE: Doubts about MPLS-TE Mib
Date: Thu, 26 Jul 2001 19:41:27 +0530
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 ,
> 
> Thanks for the clarifications . But a few doubts persist ...
> >2. the object mplsTunnelIngressId is defined to be used as the
> >ExtendedTunnelId .
> 
>          Yes.
> 
> >But then where will the SenderTemplate object's
> >Sender IP address come from ?
> 
>          EgressTunnelId.
First , do you mean EgressLSRId by this ... but this could only be
IngressLSRId if anything . 

But , this is also being used as extended tunnel id , in which case it COULD
be 0 ... then isn't there an indexing problem ?

I realise that this question has been asked before but i could not find any
satisfactory conclusion to a thread that speaks about this . 
One of the promising threads ends on this note from David Charlap ( from the
archives : http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
>Then there is potential for conflict between the TE MIB and RSVP-TE
>itself. ...........
>I can only assume that the TE MIB was based upon the features of >RSVP-TE
that are commonly in use, and can not fully accomodate all of >its features.
If someone build a router that supports multipoint-to-point >LSPs using
RSVP-TE, the TE MIB will have to be updated, or that >implementation will be
unable to properly represent these kinds of LSPs >using it. 

Is this then an unresolved problem ?

Thanks ,
Apratim






From owner-mpls@UU.NET  Thu Jul 26 11:30: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 LAA17920
	for ; Thu, 26 Jul 2001 11:30: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 QQkziv17688;
	Thu, 26 Jul 2001 14:15:57 GMT
Received: by mail-control.mail.uu.net 
	id QQkziu18814
	for mpls-outgoing; Thu, 26 Jul 2001 14:14: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 QQkziu18785
	for ; Thu, 26 Jul 2001 14:13:48 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkziu01405
	for ; Thu, 26 Jul 2001 14:12: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 QQkziu11901
	for ; Thu, 26 Jul 2001 14:11:52 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04315 for ; Thu, 26 Jul 2001 10:11:52 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06807 for mpls@uu.net; Thu, 26 Jul 2001 10:11:41 -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 QQkzhk26229
	for ; Thu, 26 Jul 2001 05:00: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 QQkzhk04787
	for ; Thu, 26 Jul 2001 05:00:00 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQkzhj01874
	for ; Thu, 26 Jul 2001 04:59:59 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Jul 2001 10:43:52 +0530
Message-ID: <71E32B42DB71D511BC7900024419247C09B719@LAKSHMI>
From: Vijayanand C 
To: mpls@UU.NET
Cc: gopinathg@ctd.hctech.com
Subject: CR LDP Label Mapping
Date: Thu, 26 Jul 2001 10:41:47 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello all,
I have a question regarding label distribution in CR LDP.

Assume that a CR LSP is established and at an intermediate LSR a Next Hop
change occurs. When the intermeditate LSR requests for and gets a mapping
from the New Next hop it will propagate the mapping upstream since the HC/PV
values have changed(according to procedures in RFC3036 which is applicable
for CR LDP also). This mapping is, strictly speaking, an unsolicited
mapping. So, is this behaviour of propagating the mapping upstream because
the HC /PV attributes differ from the values in the previous mapping,
correct for Dod Ordered control .

If so, what will be the request message ID in the mapping message ?. In CR
LDP, the request message ID TLV is mandatory for the mapping message.  Would
it be correct to use the request ID of the last request received from
upstream, for which mapping was already sent. This strategy will prevent the
upstream from reusing that message ID indefinitly. 

Please clarify and correct me if I am wrong.

Thanks in advance,
Regards,
Vijay



From owner-mpls@UU.NET  Thu Jul 26 11:54: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 LAA19108
	for ; Thu, 26 Jul 2001 11:54:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzjb27237;
	Thu, 26 Jul 2001 15:55:03 GMT
Received: by mail-control.mail.uu.net 
	id QQkzjb18011
	for mpls-outgoing; Thu, 26 Jul 2001 15:54:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzjb17980
	for ; Thu, 26 Jul 2001 15:54:07 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 QQkzjb25429
	for ; Thu, 26 Jul 2001 15:53:40 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzjb00650
	for ; Thu, 26 Jul 2001 15:53:40 GMT
Message-ID: <3B603CFD.45884EB1@sandburst.com>
Date: Thu, 26 Jul 2001 11:53:33 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Vijayanand C 
Cc: mpls@UU.NET, gopinathg@ctd.hctech.com
Subject: Re: CR LDP Label Mapping
References: <71E32B42DB71D511BC7900024419247C09B719@LAKSHMI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vijay,

    Short answer: your assumption about propagation of HC/PV beyond
the intermediate LSR that intiates a 'local repair' is wrong.

    Both Hop Count and Path Vector would need to be included in a label
mapping message only to the extent that they were previously included.
When using explicit route objects, use of Hop Count or Path Vector is
somewhat redundant, since it is impossible to explicitly route a loop.
While this is particularly in the strict ERO case, since it is possible for
a loop to occur in that portion of an LSP that is either loosely specified,
or strictly specified using an abstract node (e.g. - an AS number), either
Hop Count or Path Vector need only to be used in loosely specified LSP
segments in order to ensure that the resulting LSP is loop free.  Also, it
is a general truth that - if you can be certain that ordered control is used
through out the length of an LSP, than you can be sure Label Mappings
will not be received by the ingress to any portion of the LSP if there is a
loop in the downstream LSP setup control path.

    In the case that you mention, for instance, as soon as the intermediate
LSR receives a Label Mapping - with or without a Hop Count or a Path
Vector - it may assume that the corresponding LSP is loop free.  Since -
in this case - this LSR is the originator of the initial Label Request, there
is no reason for it to send a new Label Mapping to any upstream peer.

    This brings up a minor failing in the protocol: if Hop Count is used to
set the TTL decrement value (at the ingress of the LSP) - for an ATM
LSP for example - then the only way for the intermediate LSR to ensure
that an accurate Hop Count is received by the ingress is to tear down the
LSP and force the ingress to re-establish it.  This is a minor failing since
the ingress can ensure that this happens by disallowing 'local repair' (the
process you describe in this case) during LSP setup.

--
Eric Gray

You wrote:

> Hello all,
> I have a question regarding label distribution in CR LDP.
>
> Assume that a CR LSP is established and at an intermediate LSR a Next Hop
> change occurs. When the intermeditate LSR requests for and gets a mapping
> from the New Next hop it will propagate the mapping upstream since the HC/PV
> values have changed(according to procedures in RFC3036 which is applicable
> for CR LDP also). This mapping is, strictly speaking, an unsolicited
> mapping. So, is this behaviour of propagating the mapping upstream because
> the HC /PV attributes differ from the values in the previous mapping,
> correct for Dod Ordered control .
>
> If so, what will be the request message ID in the mapping message ?. In CR
> LDP, the request message ID TLV is mandatory for the mapping message.  Would
> it be correct to use the request ID of the last request received from
> upstream, for which mapping was already sent. This strategy will prevent the
> upstream from reusing that message ID indefinitly.
>
> Please clarify and correct me if I am wrong.
>
> Thanks in advance,
> Regards,
> Vijay



From owner-mpls@UU.NET  Thu Jul 26 13:52: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 NAA26451
	for ; Thu, 26 Jul 2001 13: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 QQkzjj28871;
	Thu, 26 Jul 2001 17:53:08 GMT
Received: by mail-control.mail.uu.net 
	id QQkzjj10356
	for mpls-outgoing; Thu, 26 Jul 2001 17:52: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 QQkzjj10351
	for ; Thu, 26 Jul 2001 17:52:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzjj03696
	for ; Thu, 26 Jul 2001 17:51:42 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 QQkzjj18222
	for ; Thu, 26 Jul 2001 17:51:42 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA01114 for mpls@uu.net; Thu, 26 Jul 2001 13:51:41 -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 QQkzjj10167
	for ; Thu, 26 Jul 2001 17:51:04 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 QQkzjj29798
	for ; Thu, 26 Jul 2001 17:50:32 GMT
Received: from che-cse-104.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQkzjj25413
	for ; Thu, 26 Jul 2001 17:50:32 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f6QHoUJ07114; Thu, 26 Jul 2001 13:50:30 -0400 (EDT)
Date: Thu, 26 Jul 2001 13:50:30 -0400
From: Eric Osborne 
To: "Gopal@Cisco" 
Cc: avascan@cisco.com, mpls-list , thenrie@cisco.com
Subject: Re: MPLS TE migration question. ospf - ISIS
Message-ID: <20010726135029.B6480@che-cse-104.cisco.com>
References:  <3B5F62C1.2ED35809@juniper.net> <3B604847.7E959D5D@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <3B604847.7E959D5D@cisco.com>; from gnaganab@cisco.com on Thu, Jul 26, 2001 at 09:41:43AM -0700
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

um...not a good idea to send questions like this to mpls@uu.net.  :)
I'll answer this off-line.




eric

On Thu, Jul 26, 2001 at 09:41:43AM -0700, Gopal@Cisco wrote:
> 
> 
> HI All, For the following network scenerio;
> 
> TE.Head---OSPF Cloud-----ISIS Cloud-----TE.Tail
> 
> Customer wants to migrate OSPF network into the MPLS backbone and run 
> MPLS TE.
> Is this even possible?
> My question is  will the opaque Lsa's/TLV's  be redistributed during
> redistribution process. To clarify more, will ospf understand
> special-TLV's from ISIS and vice versa.
> 
> Any Input Highly Appreciated.
> 
> Thank You,
> Gopal



From owner-mpls@UU.NET  Thu Jul 26 13:56: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 NAA26755
	for ; Thu, 26 Jul 2001 13:56: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 QQkzjj06493;
	Thu, 26 Jul 2001 17:56:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkzjj10649
	for mpls-outgoing; Thu, 26 Jul 2001 17:56: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 QQkzjj10621
	for ; Thu, 26 Jul 2001 17:55:51 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 QQkzjj11150
	for ; Thu, 26 Jul 2001 17:55:27 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 QQkzjj23003
	for ; Thu, 26 Jul 2001 17:55:26 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA01457 for mpls@uu.net; Thu, 26 Jul 2001 13:55:26 -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 QQkzjj10503
	for ; Thu, 26 Jul 2001 17:54: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 QQkzjj10201
	for ; Thu, 26 Jul 2001 17:54:38 GMT
Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkzjj03810
	for ; Thu, 26 Jul 2001 17:54:38 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 f6QHsDT23954;
	Thu, 26 Jul 2001 10:54:13 -0700 (PDT)
Received: from cisco.com (skatukam-u5.cisco.com [171.71.213.88])
	by mira1.cisco.com (Mirapoint)
	with ESMTP id ACY04696;
	Thu, 26 Jul 2001 10:53:59 -0700 (PDT)
Message-ID: <3B605936.AD968396@cisco.com>
Date: Thu, 26 Jul 2001 10:53:58 -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: rajesh@tejasnetworks.com
CC: Martin Dubuc , mpls@UU.NET, jplang@calient.net,
        kireeti@juniper.net, ccamp@ops.ietf.org
Subject: Re: Queries regarding LMP.
References:  <3B5FF461.141BC03D@tejasnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Rajesh,

> >
> > Q3) Destination address can be multicast or any valid IP address of
> > destination node (most likely the NodeID of the destination node).
> 
> If it is the Node ID of the neighbour then how does one find it
> without manual configuration ?? Is it with the help of an IGP
> such as OSPF ? We would like to automate things as much as
> possible.

Initial Config message will go out on a multicast address. 
This makes it easy for initial communication.

All other messages will be addressed to Node ID. 
Section 9 of OIF2000.125.5. clairifies this issues. 

This may change again if Node ID is
not be a routable IP address. It should be really the source
IP address of the Config message to whom you should send
your LMP messages.

Thanks,
Suresh

> 
> If LMP is designed as an independent protocol then IMHO
> we should use a multicast address.
> 
> Regds,
> - Rajesh



From owner-mpls@UU.NET  Thu Jul 26 15:21: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 PAA05244
	for ; Thu, 26 Jul 2001 15:21: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 QQkzjf06429;
	Thu, 26 Jul 2001 16:57:01 GMT
Received: by mail-control.mail.uu.net 
	id QQkzjf14130
	for mpls-outgoing; Thu, 26 Jul 2001 16:56: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 QQkzjf14123
	for ; Thu, 26 Jul 2001 16:56:27 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 QQkzjf26268
	for ; Thu, 26 Jul 2001 16:56:19 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 QQkzjf00488
	for ; Thu, 26 Jul 2001 16:56:18 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA00004
	for ; Thu, 26 Jul 2001 12:56:18 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA07489 for mpls@uu.net; Thu, 26 Jul 2001 12:56:07 -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 QQkzje11658
	for ; Thu, 26 Jul 2001 16:33:35 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 QQkzje11884
	for ; Thu, 26 Jul 2001 16:32:25 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 QQkzje28575
	for ; Thu, 26 Jul 2001 16:32:25 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 f6QGT2o07761;
	Thu, 26 Jul 2001 09:29:02 -0700 (PDT)
Reply-To: 
From: "HariKishan" 
To: 
Cc: 
Subject: Retry timer value for Label Requests ?
Date: Thu, 26 Jul 2001 09:27:23 -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.00.2919.6600
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

	How much time does a LSR wait for a response to the
Label request it has sent? 

What timer value is used by most implementations ?

thanks,
Kishan




From owner-mpls@UU.NET  Thu Jul 26 16:03:53 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 QAA08413
	for ; Thu, 26 Jul 2001 16:03: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 QQkzig11953;
	Thu, 26 Jul 2001 10:44:06 GMT
Received: by mail-control.mail.uu.net 
	id QQkzig14935
	for mpls-outgoing; Thu, 26 Jul 2001 10:43: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 QQkzig14921
	for ; Thu, 26 Jul 2001 10:43: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 QQkzig09519
	for ; Thu, 26 Jul 2001 10:42:32 GMT
Received: from india.tejasnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.94.83])
	id QQkzig02851
	for ; Thu, 26 Jul 2001 10:42:24 GMT
Received: from tejasnetworks.com ([192.168.1.157])
	by india.tejasnetworks.com (8.9.3/8.9.3) with ESMTP id QAA22940;
	Thu, 26 Jul 2001 16:22:15 +0530
Message-ID: <3B5FF461.141BC03D@tejasnetworks.com>
Date: Thu, 26 Jul 2001 16:13:45 +0530
From: rajesh 
Reply-To: rajesh@tejasnetworks.com
Organization: Tejas Networks
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin Dubuc 
CC: mpls@UU.NET, jplang@calient.net, kireeti@juniper.net, ccamp@ops.ietf.org
Subject: Re: Queries regarding LMP.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Martin Dubuc wrote:

>
>
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).

If it is the Node ID of the neighbour then how does one find it
without manual configuration ?? Is it with the help of an IGP
such as OSPF ? We would like to automate things as much as
possible.

If LMP is designed as an independent protocol then IMHO
we should use a multicast address.

Regds,
- Rajesh



From owner-mpls@UU.NET  Thu Jul 26 17:45: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 RAA15316
	for ; Thu, 26 Jul 2001 17:45: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 QQkzio10022;
	Thu, 26 Jul 2001 12:40:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkzio00766
	for mpls-outgoing; Thu, 26 Jul 2001 12:39:39 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 QQkzio00751
	for ; Thu, 26 Jul 2001 12:39:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzio29459
	for ; Thu, 26 Jul 2001 12:39: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 QQkzio08977
	for ; Thu, 26 Jul 2001 12:39:01 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA07362 for mpls@uu.net; Thu, 26 Jul 2001 08:39:01 -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 QQkzio00715
	for ; Thu, 26 Jul 2001 12:38:27 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 QQkzio15581
	for ; Thu, 26 Jul 2001 12:38:19 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 QQkzio07412
	for ; Thu, 26 Jul 2001 12:38:19 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 IAA25577; Thu, 26 Jul 2001 08:38:19 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEL05333;
	Thu, 26 Jul 2001 08:38:17 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010726083647.0222f698@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 26 Jul 2001 08:42:49 -0400
To: Apratim Mukherjee , "'mpls@UU.NET'" 
From: "Thomas D. Nadeau" 
Subject: Re: Doubts about MPLS-TE Mib
In-Reply-To: <13D467F625FAD511AE2A00D0B7B917D706BAB7@mailserver.netbrahm
 a.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 10:25 AM 7/26/2001 +0530, Apratim Mukherjee wrote:
>Hi ,
>
>I have a few doubts about the MPLS-TE Mib.
>Please note that the doubts are with regards to usage of RSVP-TE as the
>signalling mechanism .
>
>1. There are three similar objects in the mplsTunnelTable ....
>mplsTunnelIndex , mplsTunnelInstance , mplsTunnelPrimaryInstance  .
>  According to my understanding , mplsTunnelIndex is the same as the TunnelId
>in the Session object .
>  But how does mplsTunnelInstance and mplsTunnelPrimaryInstance fit into
>RSVP-Te ?
>  Are they outside the scope of RSVP-Te ?
>  Or do they refer to LspIds of primary and secondary Lsps ?

         We really need to fix the descriptions to include this,
as I have had to explain this about 10 times now. ;) The four
objects come directly from and are required for uniqueness in
RSVP-TE and CR-LDP. Take a look at the session object in RSVP-TE
for example. Three of the objects are required to be unique for
CR-LDP (tunnelInstance = 0 for CR-LDP). You might want to
peruse the archives too, since this question has been asked
numerous times.

>2. the object mplsTunnelIngressId is defined to be used as the
>ExtendedTunnelId .

         Yes.

>But then where will the SenderTemplate object's
>Sender IP address come from ?

         EgressTunnelId.

>3. What is the difference between ARHopTable and CHop Table ?

         The ARHop table stands for "actual route hop table".
This is what returns in the RRO object, and is the
actual path taken by the tunnel. The CHop table stands
for "computed hop" table. This is what the CSPF calculation
spits out and will be (or is trying to be) used to
signal the tunnel. The difference is that the CHop
table is used for diagnostic purposes. If a tunnel
is not being signaled, it is nice to see what the heck
the head is trying to do. When all is working correctly,
the ARHops will be the same as the CHops.

         --Tom



>    Do they refer to incoming and updated EROs ?
>
>Thanks in advance
>Apratim



From owner-mpls@UU.NET  Thu Jul 26 18:02:00 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 SAA16476
	for ; Thu, 26 Jul 2001 18:01: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 QQkzka00231;
	Thu, 26 Jul 2001 22:02:26 GMT
Received: by mail-control.mail.uu.net 
	id QQkzka27331
	for mpls-outgoing; Thu, 26 Jul 2001 22:01: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 QQkzka27247
	for ; Thu, 26 Jul 2001 22:01:46 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 QQkzka01650
	for ; Thu, 26 Jul 2001 22:00:46 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 QQkzka09109
	for ; Thu, 26 Jul 2001 22:00:46 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA17477 for mpls@uu.net; Thu, 26 Jul 2001 18:00:45 -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 QQkzka24160
	for ; Thu, 26 Jul 2001 22:00: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 QQkzjz00141
	for ; Thu, 26 Jul 2001 21:57:22 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQkzjz23828
	for ; Thu, 26 Jul 2001 21:57:22 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 RAA09014
	for ; Thu, 26 Jul 2001 17:57:21 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA08675 for ; Thu, 26 Jul 2001 17:57:21 -0400 (EDT)
Message-Id: <200107262157.RAA08675@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: MPLS agenda items...
Date: Thu, 26 Jul 2001 17:57:21 -0400
From: George Swallow 
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks -

I've only seen direct request for timeslots for the drafts listed
below.  I've seen more drafts go by, but submitting a draft does not
equate to a request for agenda time.  Please let me know if you'd like
time.

...George


draft-atlas-local-protect-interop-00.txt	Alia Atlas

draft-gan-fast-reroute-00.txt			Ping Pan

draft-tempest-mpls-ccamp-rsvp-resync-00.txt	Osama Aboul-Magd

draft-pan-rsvp-te-restart-01.txt		Ping Pan

draft-tsenevir-mpls-lauth-01.txt		Tissa Senevirathne

draft-ganti-mpls-diffserv-elsp-00.txt		Sudhakar Ganti

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824






From owner-mpls@UU.NET  Thu Jul 26 18:06: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 SAA16819
	for ; Thu, 26 Jul 2001 18:06: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 QQkzje17345;
	Thu, 26 Jul 2001 16:44:51 GMT
Received: by mail-control.mail.uu.net 
	id QQkzje12714
	for mpls-outgoing; Thu, 26 Jul 2001 16:44: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 QQkzje12675
	for ; Thu, 26 Jul 2001 16:44:00 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 QQkzje25549
	for ; Thu, 26 Jul 2001 16:43:41 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 QQkzje18432
	for ; Thu, 26 Jul 2001 16:43:41 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA25552 for mpls@uu.net; Thu, 26 Jul 2001 12:43: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 QQkzje12568
	for ; Thu, 26 Jul 2001 16:42: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 QQkzje03534
	for ; Thu, 26 Jul 2001 16:41:47 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQkzje12824
	for ; Thu, 26 Jul 2001 16:41:47 GMT
Received: from cisco.com (sj-cse-155.cisco.com [171.68.200.172])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA14401;
	Thu, 26 Jul 2001 09:41:46 -0700 (PDT)
Message-ID: <3B604847.7E959D5D@cisco.com>
Date: Thu, 26 Jul 2001 09:41:43 -0700
From: "Gopal@Cisco" 
Organization: Cisco Systems Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: avascan@cisco.com, mpls-list , thenrie@cisco.com
Subject: MPLS TE migration question. ospf - ISIS
References:  <3B5F62C1.2ED35809@juniper.net>
Content-Type: multipart/mixed;
 boundary="------------8221BB5E376202996C6D4980"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------8221BB5E376202996C6D4980
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


HI All, For the following network scenerio;

TE.Head---OSPF Cloud-----ISIS Cloud-----TE.Tail

Customer wants to migrate OSPF network into the MPLS backbone and run 
MPLS TE.
Is this even possible?
My question is  will the opaque Lsa's/TLV's  be redistributed during
redistribution process. To clarify more, will ospf understand
special-TLV's from ISIS and vice versa.

Any Input Highly Appreciated.

Thank You,
Gopal
--------------8221BB5E376202996C6D4980
Content-Type: text/x-vcard; charset=us-ascii;
 name="gnaganab.vcf"
Content-Description: Card for Gopal@Cisco
Content-Disposition: attachment;
 filename="gnaganab.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Naganaboyina;Gopal
x-mozilla-html:FALSE
org:Cisco Systems Inc.;TAC-SJ-RP
adr:;;;;;;
version:2.1
email;internet:gnaganab@cisco.com
x-mozilla-cpt:;-11464
fn:Gopal@Cisco
end:vcard

--------------8221BB5E376202996C6D4980--



From owner-mpls@UU.NET  Thu Jul 26 18:19: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 SAA17503
	for ; Thu, 26 Jul 2001 18:19: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 QQkziv19568;
	Thu, 26 Jul 2001 14:17:34 GMT
Received: by mail-control.mail.uu.net 
	id QQkziv19403
	for mpls-outgoing; Thu, 26 Jul 2001 14:17: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 QQkziv19306
	for ; Thu, 26 Jul 2001 14:15:53 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 QQkziu12430
	for ; Thu, 26 Jul 2001 14:12:29 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQkziu12662
	for ; Thu, 26 Jul 2001 14:12:26 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA09256
	for ; Thu, 26 Jul 2001 10:12:26 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06817 for mpls@uu.net; Thu, 26 Jul 2001 10:12: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 QQkzit27370
	for ; Thu, 26 Jul 2001 13:55: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 QQkzit15176
	for ; Thu, 26 Jul 2001 13:53:21 GMT
Received: from brahma.roc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.125.87.14])
	id QQkzit16687
	for ; Thu, 26 Jul 2001 13:53:18 GMT
Received: from linux ([172.16.1.82])
	by brahma.roc.com (8.11.2/8.8.7) with SMTP id f6QDsFl10492
	for ; Thu, 26 Jul 2001 19:24:17 +0530
From: Srinivas Reddy 
Reply-To: lsreddy@trinc.com
Organization: ROC
To: mpls@UU.NET
Subject: Re: penultimate hop poping
Date: Wed, 25 Jul 2001 20:40:02 +0530
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
References: <751B6DD7A243D511AB9F0002557C56878B2BC5@HUAWEIMAIL>
In-Reply-To: <751B6DD7A243D511AB9F0002557C56878B2BC5@HUAWEIMAIL>
MIME-Version: 1.0
Message-Id: <01072520400200.00691@linux>
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

thnak all for u r suggestions,

now i my conclusion is for the timebeing i can think of that each LSR MUST 
support penultimate hop poping., and egress(LSR) also will assume that it has 
the capability of doing so.
in future this may not work.

once again thanks
regards
lsreddy
On Wednesday 25 July 2001  9:40 am, you wrote:

> > hello Chetan
>
>
>   The RFC3036 clearly mentions the following thing
>
> --------------------------------------------------------------------
> 6. Areas for Future Study
>
>    The following topics not addressed in this version of LDP are
>    possible areas for future study:
>
>       -  Section 2.16 of the MPLS architecture [RFC3031] requires that
>          the initial label distribution protocol negotiation between
>          peer LSRs enable each LSR to determine whether its peer is
>          capable of popping the label stack.  This version of LDP
>          assumes that LSRs support label popping for all link types
>          except ATM and Frame Relay.  A future version may specify means
>          to make this determination part of the session initiation
>          negotiation.
> ------------------------------------------------------------------------
>
> So the RFC is not missing anything but it is left for the future study
>
>
> Regds
> Ashwin
>
>
>
>
> -----Original Message-----
> From: chetan kumar s [mailto:chetan.kumar@wipro.com]
> Sent: Wednesday, July 25, 2001 8:30 AM
> To: Eric Gray
> Cc: lsreddy@trinc.com; mpls@UU.NET
> Subject: Re: penultimate hop poping
>
>
> Hi,
>
> >     Of course, some implementations may so far depend on PHP that they
> > will give the IMPLICIT NULL label again in this case - even though this
> > is a clear violation of the specification.
>
> 	'violation of specification' how ?? I do not see any such
> statements in any of the RFC, have I missed something ??
>
> And beyond that if I look at the RFC 3031 section 3.16 Page 19, it states
>
>    Initial label distribution protocol negotiations MUST allow each LSR
>    to determine whether its neighboring LSRS are capable of popping the
>    label stack.
>
> So, does the RFC 3036 missing something in the init message ??
>
> Thanks
> Chetan S
>
> > --
> > Eric Gray
> >
> > You wrote:
> > > Dear all,
> > >
> > >         as per rfc3031 under section 3.16.
> > > 1)Initial LDP negotiations MUST allow each LSR to determine whether its
> > > neighbouring LSRS are capable of poping the label stack.
> > >
> > > how can we(egress) determine that our neighbour has the capability of
>
> poping
>
> > > the stack.
> > >
> > > 2)A LSR MUST NOT Request a label distribution peer to pop the label
>
> stack
>
> > > unless it is capable of doing so.
> > >         is it possible that a LSR will not support the label stack
>
> poping.
>
> > > and under section 4.1.5 (rfc3031)
> > > LSR Rd distributes a binding between Implicit NULL and an address
> > > prefix
>
> X to
>
> > > LSR Ru if and only if :
> > >         1. the rules os -----------
> > >         2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it
>
> can pop the
>
> > > label stack) ...
> > > how can Rd (egress) knows that  Ru has support of poping of stack. or
> > > is
>
> it a
>
> > > MUST that each LSR should support penultimate hop poing.
> > >
> > > please calrify ,me about this.
> > > thanks in adv.
> > > regards
> > > lonka

----------------------------------------
Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
Content-Transfer-Encoding: quoted-printable
Content-Description: 
----------------------------------------



From owner-mpls@UU.NET  Fri Jul 27 02:17: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 CAA26293
	for ; Fri, 27 Jul 2001 02:17: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 QQkzlh10871;
	Fri, 27 Jul 2001 06:18:37 GMT
Received: by mail-control.mail.uu.net 
	id QQkzlh10072
	for mpls-outgoing; Fri, 27 Jul 2001 06:18: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 QQkzlh10065
	for ; Fri, 27 Jul 2001 06:18:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzlh12693
	for ; Fri, 27 Jul 2001 06:17:55 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzlh09991
	for ; Fri, 27 Jul 2001 06:17:52 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Jul 2001 11:45:35 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71FF0FF@mailserver.netbrahma.com>
From: Khuzema Pithewan 
To: "'mpls@uu.net'" 
Subject: mpls-te mib
Date: Fri, 27 Jul 2001 11:45:33 +0530
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,

In case of rsvp-te as signaling mechanism in place, how mpls-te mib values
are updated at LSRs?  Is it dyanamically updated on reception of path-resv
messages or updated by SNMP/CLI?

Regards
Khuzema.
------------------------------------------------
Net Brahma Technologies Private Limited
Internext Networking Software
A Microland Group Company
777, 3rd 'a' cross, 18th Main 
Koramangala VI th block
Bangalore-95
Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
Fax no        - (080) 5537233 
email : khuzemap@netbrahma.com
www.netbrahma.com



From owner-mpls@UU.NET  Fri Jul 27 02:21: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 CAA26359
	for ; Fri, 27 Jul 2001 02:21: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 QQkzlh06523;
	Fri, 27 Jul 2001 06:22:34 GMT
Received: by mail-control.mail.uu.net 
	id QQkzlh10392
	for mpls-outgoing; Fri, 27 Jul 2001 06:21:19 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzlh10340
	for ; Fri, 27 Jul 2001 06:21:06 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 QQkzlh27190
	for ; Fri, 27 Jul 2001 06:20:18 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzlh12816
	for ; Fri, 27 Jul 2001 06:20:16 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Jul 2001 11:48:02 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71FF100@mailserver.netbrahma.com>
From: Khuzema Pithewan 
To: "'mpls@uu.net'" 
Subject: Diffserv or Intserv with rsvp-te?
Date: Fri, 27 Jul 2001 11:48:01 +0530
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,

As rsvp-te carries IntServ Tspecs, is it necessary to be intserv mechanism
in place for rsvp-te to work, or there can be diffserv? 

If diffserv can be use then how does intserv Tspec maps to diffserv PHBs.?

Regards,
Khuzema.
------------------------------------------------
Net Brahma Technologies Private Limited
Internext Networking Software
A Microland Group Company
777, 3rd 'a' cross, 18th Main 
Koramangala VI th block
Bangalore-95
Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
Fax no        - (080) 5537233 
email : khuzemap@netbrahma.com
www.netbrahma.com



From owner-mpls@UU.NET  Fri Jul 27 06:10: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 GAA04926
	for ; Fri, 27 Jul 2001 06:10: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 QQkzlw25691;
	Fri, 27 Jul 2001 10:10:59 GMT
Received: by mail-control.mail.uu.net 
	id QQkzlw19253
	for mpls-outgoing; Fri, 27 Jul 2001 10:10:26 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 QQkzlw19243
	for ; Fri, 27 Jul 2001 10:10: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 QQkzlw26723
	for ; Fri, 27 Jul 2001 10:09:47 GMT
Received: from albatross-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	id QQkzlw06229
	for ; Fri, 27 Jul 2001 10:09:46 GMT
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6RA9jN27454
	for ; Fri, 27 Jul 2001 12:09:46 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jul 27 12:09:44 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Jul 2001 12:09:43 +0200
Message-ID: 
From: "Roberto Mameli (ERI)" 
To: "'mpls@uu.net'" 
Subject: RE: Diffserv or Intserv with rsvp-te?
Date: Fri, 27 Jul 2001 11:44:48 +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 Khuzema,

in  section 2.3 states:

"This document does not restrict the type of Integrated Service requests for reservations.  However, an implementation SHOULD support the Controlled-Load service [4] and the Class-of-Service service, see Section 4.8.".

Therefore it seems that there is a new service class for RSVP-TE extension, i.e. the Class-of-Service service. So, not a new TSpec type, but simply a new class of service defined within the IntServ TSpec. However, there is no section 4.8 that explains it, and unfortunately I've not been able to find references anywhere. By the way, is there anyone that knows something about it?

Moreover section 5.6 of  states that:

"Both E-LSPs and L-LSPs can be established with bandwidth reservation or without bandwidth reservation. As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP with bandwidth reservation, Int-Serv's Controlled Load service (or possibly Guaranteed Service) is used and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the path(respectively Resv) message. As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP without bandwidth reservation, the Null Service specified in [NULL] is used.".

So no Class-of-Service here is cited. Instead Controlled Load or Null Service type are suggested, and mapping between CoS and LSP is signaled through the DiffServ Object in the Path Message. Any clarification about that?

Regards
Roberto


> -----Original Message-----
> From: Khuzema Pithewan [mailto:KhuzemaP@netbrahma.com]
> Sent: Friday, July 27, 2001 8:18 AM
> To: 'mpls@uu.net'
> Subject: Diffserv or Intserv with rsvp-te?
> 
> 
> Hi,
> 
> As rsvp-te carries IntServ Tspecs, is it necessary to be 
> intserv mechanism
> in place for rsvp-te to work, or there can be diffserv? 
> 
> If diffserv can be use then how does intserv Tspec maps to 
> diffserv PHBs.?
> 
> Regards,
> Khuzema.
> ------------------------------------------------
> Net Brahma Technologies Private Limited
> Internext Networking Software
> A Microland Group Company
> 777, 3rd 'a' cross, 18th Main 
> Koramangala VI th block
> Bangalore-95
> Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
> Fax no        - (080) 5537233 
> email : khuzemap@netbrahma.com
> www.netbrahma.com
> 


From owner-mpls@UU.NET  Fri Jul 27 07:24: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 HAA07773
	for ; Fri, 27 Jul 2001 07:24:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzmb24699;
	Fri, 27 Jul 2001 11:25:11 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmb14703
	for mpls-outgoing; Fri, 27 Jul 2001 11:24: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 QQkzmb14695
	for ; Fri, 27 Jul 2001 11:24: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 QQkzmb03196
	for ; Fri, 27 Jul 2001 11:24:07 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 QQkzmb27086
	for ; Fri, 27 Jul 2001 11:24:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA20132 for mpls@uu.net; Fri, 27 Jul 2001 07:24:05 -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 QQkzmb14619
	for ; Fri, 27 Jul 2001 11: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 QQkzmb15831
	for ; Fri, 27 Jul 2001 11:23:30 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQkzmb26377
	for ; Fri, 27 Jul 2001 11:23:30 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07628;
	Fri, 27 Jul 2001 07:22:30 -0400 (EDT)
Message-Id: <200107271122.HAA07628@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-04.txt
Date: Fri, 27 Jul 2001 07:22:30 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Generalized MPLS Signaling - CR-LDP Extensions
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-cr-ldp-04.txt
	Pages		: 20
	Date		: 26-Jul-01
	
This document describes extensions to CR-LDP signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents a CR-LDP specific description of the
extensions.  An RSVP-TE specific description can be found in [GMPLS-
RSVP].  A generic functional description is presented in [GMPLS-SIG].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-cr-ldp-04.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726171026.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-generalized-cr-ldp-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726171026.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jul 27 07:25: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 SMTP id HAA07879
	for ; Fri, 27 Jul 2001 07:25: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 QQkzmb00077;
	Fri, 27 Jul 2001 11:26:25 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmb14853
	for mpls-outgoing; Fri, 27 Jul 2001 11:26: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 QQkzmb14712
	for ; Fri, 27 Jul 2001 11:24:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzmb27828
	for ; Fri, 27 Jul 2001 11:24:43 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 QQkzmb27803
	for ; Fri, 27 Jul 2001 11:24:43 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA20196 for mpls@uu.net; Fri, 27 Jul 2001 07:24:43 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzmb14672
	for ; Fri, 27 Jul 2001 11:24: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 QQkzmb25833
	for ; Fri, 27 Jul 2001 11:23:34 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQkzmb26470
	for ; Fri, 27 Jul 2001 11:23:34 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07640;
	Fri, 27 Jul 2001 07:22:35 -0400 (EDT)
Message-Id: <200107271122.HAA07640@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-04.txt
Date: Fri, 27 Jul 2001 07:22:34 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Generalized MPLS Signaling - RSVP-TE Extensions
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-rsvp-te-04.txt
	Pages		: 33
	Date		: 26-Jul-01
	
This document describes extensions to RSVP-TE signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents an RSVP-TE specific description of
the extensions.  A CR-LDP specific description can be found in
[GMPLS-LDP].  A generic functional description is presented in
[GMPLS-SIG].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-rsvp-te-04.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726171036.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-generalized-rsvp-te-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726171036.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jul 27 07:26: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 SMTP id HAA07938
	for ; Fri, 27 Jul 2001 07:26: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 QQkzmb02099;
	Fri, 27 Jul 2001 11:27:35 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmb14860
	for mpls-outgoing; Fri, 27 Jul 2001 11:26: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 QQkzmb14713
	for ; Fri, 27 Jul 2001 11:24:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzmb27826
	for ; Fri, 27 Jul 2001 11:24:43 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 QQkzmb27801
	for ; Fri, 27 Jul 2001 11:24:43 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA20195 for mpls@uu.net; Fri, 27 Jul 2001 07:24: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 QQkzmb14670
	for ; Fri, 27 Jul 2001 11:24:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzmb01603
	for ; Fri, 27 Jul 2001 11:23:20 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQkzmb26168
	for ; Fri, 27 Jul 2001 11:23:20 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07598;
	Fri, 27 Jul 2001 07:22:20 -0400 (EDT)
Message-Id: <200107271122.HAA07598@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-recovery-frmwrk-03.txt
Date: Fri, 27 Jul 2001 07:22:20 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Framework for MPLS-based Recovery
	Author(s)	: V. Sharma et al.
	Filename	: draft-ietf-mpls-recovery-frmwrk-03.txt
	Pages		: 32
	Date		: 26-Jul-01
	
Multi-protocol label switching (MPLS) [1] integrates the label 
swapping forwarding paradigm with network layer routing. To deliver 
reliable service, MPLS requires a set of procedures to provide 
protection of the traffic carried on different paths. This requires 
that the label switched routers (LSRs) support fault detection, fault 
notification, and fault recovery mechanisms, and that MPLS signaling 
[2], [3], [4], [5], [6], [7] support the configuration of recovery. 
With these objectives in mind, this document specifies a framework 
for MPLS based recovery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-recovery-frmwrk-03.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726171007.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-recovery-frmwrk-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726171007.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jul 27 07:28: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 HAA08003
	for ; Fri, 27 Jul 2001 07:28: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 QQkzmb17590;
	Fri, 27 Jul 2001 11:28:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmb15029
	for mpls-outgoing; Fri, 27 Jul 2001 11:28: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 QQkzmb14774
	for ; Fri, 27 Jul 2001 11:25:18 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 QQkzmb04562
	for ; Fri, 27 Jul 2001 11:24:44 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 QQkzmb27839
	for ; Fri, 27 Jul 2001 11:24:44 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA20207 for mpls@uu.net; Fri, 27 Jul 2001 07:24: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 QQkzmb14664
	for ; Fri, 27 Jul 2001 11:24:04 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 QQkzmb04061
	for ; Fri, 27 Jul 2001 11:23:25 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQkzmb26266
	for ; Fri, 27 Jul 2001 11:23:25 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07611;
	Fri, 27 Jul 2001 07:22:25 -0400 (EDT)
Message-Id: <200107271122.HAA07611@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-05.txt
Date: Fri, 27 Jul 2001 07:22:25 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Generalized MPLS - Signaling Functional Description
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-signaling-05.txt
	Pages		: 31
	Date		: 26-Jul-01
	
This document describes extensions to MPLS signaling required to
support Generalized MPLS.  Generalized MPLS extends the MPLS control
plane to encompass time-division (e.g. SONET ADMs), wavelength
(optical lambdas) and spatial switching (e.g. incoming port or fiber
to outgoing port or fiber).  This document presents a functional
description of the extensions.  Protocol specific formats and
mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP].  Technology
specific details are expected to be specified in independent
technology specific documents, e.g., [GMPLS-SONET].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-signaling-05.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726171016.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-generalized-signaling-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726171016.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jul 27 07:29: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 SMTP id HAA08077
	for ; Fri, 27 Jul 2001 07:29: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 QQkzmc05973;
	Fri, 27 Jul 2001 11:30:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmb15156
	for mpls-outgoing; Fri, 27 Jul 2001 11:29: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 QQkzmb15099
	for ; Fri, 27 Jul 2001 11:29:18 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 QQkzmb17015
	for ; Fri, 27 Jul 2001 11:24:28 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 QQkzmb27482
	for ; Fri, 27 Jul 2001 11:24:28 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA20163 for mpls@uu.net; Fri, 27 Jul 2001 07:24: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 QQkzmb14650
	for ; Fri, 27 Jul 2001 11:23:51 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 QQkzmb16040
	for ; Fri, 27 Jul 2001 11:23:39 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQkzmb26540
	for ; Fri, 27 Jul 2001 11:23:39 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07669;
	Fri, 27 Jul 2001 07:22:39 -0400 (EDT)
Message-Id: <200107271122.HAA07669@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-te-feed-02.txt
Date: Fri, 27 Jul 2001 07:22:39 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Improving Topology Data Base Accuracy with LSP 
                          Feedback
	Author(s)	: P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki
	Filename	: draft-ietf-mpls-te-feed-02.txt
	Pages		: 10
	Date		: 26-Jul-01
	
One key component of traffic engineering is a concept known as 
constraint based routing. In constraint based routing a topology 
database is maintained on all participating nodes. This database 
contains a complete list of all the links in the network that 
participate in traffic engineering and for each of these links a set 
of constraints, which those links can meet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-te-feed-02.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-te-feed-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726171047.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-te-feed-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-te-feed-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726171047.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jul 27 08:32: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 IAA12291
	for ; Fri, 27 Jul 2001 08: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 QQkzmg27404;
	Fri, 27 Jul 2001 12:33:29 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmg10205
	for mpls-outgoing; Fri, 27 Jul 2001 12:32: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 QQkzmg10199
	for ; Fri, 27 Jul 2001 12:32: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 QQkzmg01713
	for ; Fri, 27 Jul 2001 12:30:38 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 QQkzmg24851
	for ; Fri, 27 Jul 2001 12:30:37 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA15612 for ; Fri, 27 Jul 2001 08:30:37 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA10966 for mpls@uu.net; Fri, 27 Jul 2001 08:30:25 -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 QQkzld14535
	for ; Fri, 27 Jul 2001 05:18:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzld16192
	for ; Fri, 27 Jul 2001 05:16:08 GMT
Received: from yamuna.ctd.hcltech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.140.153.6])
	id QQkzld13607
	for ; Fri, 27 Jul 2001 05:16:07 GMT
Received: by YAMUNA with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Jul 2001 10:49:55 +0530
Message-ID: <71E32B42DB71D511BC7900024419247C0D05A6@LAKSHMI>
From: Vijayanand C 
To: Eric Gray 
Cc: mpls@UU.NET
Subject: RE: CR LDP Label Mapping
Date: Fri, 27 Jul 2001 10:57:42 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,
For Dod Ordered control there is no need for checking the loop
parameters(HC/PV) in the mapping message. This brings us to the question of
why it is used in Mapping messages of CR-LDP. The understanding was that it
helps the ingress to measure the TTL of the LSP for non- TTL decerementing
doamins.Now,according to what you say, this purpose seems to be lost!

Also in RFC 3036, in the procedure to handle to Label Mapping message(which
is applicable for CR LDP also) , the mapping is redistributed to the
upstream peers if the loop attributes change(LMP 22 to LMP 27), regardless
of the distribution and control modes. So should this be modified or
interpreted differently for CR LDP?

Regards,
Vijay

-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Thursday, July 26, 2001 9:24 PM
To: Vijayanand C
Cc: mpls@UU.NET; gopinathg@ctd.hctech.com
Subject: Re: CR LDP Label Mapping


Vijay,

    Short answer: your assumption about propagation of HC/PV beyond
the intermediate LSR that intiates a 'local repair' is wrong.

    Both Hop Count and Path Vector would need to be included in a label
mapping message only to the extent that they were previously included.
When using explicit route objects, use of Hop Count or Path Vector is
somewhat redundant, since it is impossible to explicitly route a loop.
While this is particularly in the strict ERO case, since it is possible for
a loop to occur in that portion of an LSP that is either loosely specified,
or strictly specified using an abstract node (e.g. - an AS number), either
Hop Count or Path Vector need only to be used in loosely specified LSP
segments in order to ensure that the resulting LSP is loop free.  Also, it
is a general truth that - if you can be certain that ordered control is used
through out the length of an LSP, than you can be sure Label Mappings
will not be received by the ingress to any portion of the LSP if there is a
loop in the downstream LSP setup control path.

    In the case that you mention, for instance, as soon as the intermediate
LSR receives a Label Mapping - with or without a Hop Count or a Path
Vector - it may assume that the corresponding LSP is loop free.  Since -
in this case - this LSR is the originator of the initial Label Request,
there
is no reason for it to send a new Label Mapping to any upstream peer.

    This brings up a minor failing in the protocol: if Hop Count is used to
set the TTL decrement value (at the ingress of the LSP) - for an ATM
LSP for example - then the only way for the intermediate LSR to ensure
that an accurate Hop Count is received by the ingress is to tear down the
LSP and force the ingress to re-establish it.  This is a minor failing since
the ingress can ensure that this happens by disallowing 'local repair' (the
process you describe in this case) during LSP setup.

--
Eric Gray

You wrote:

> Hello all,
> I have a question regarding label distribution in CR LDP.
>
> Assume that a CR LSP is established and at an intermediate LSR a Next Hop
> change occurs. When the intermeditate LSR requests for and gets a mapping
> from the New Next hop it will propagate the mapping upstream since the
HC/PV
> values have changed(according to procedures in RFC3036 which is applicable
> for CR LDP also). This mapping is, strictly speaking, an unsolicited
> mapping. So, is this behaviour of propagating the mapping upstream because
> the HC /PV attributes differ from the values in the previous mapping,
> correct for Dod Ordered control .
>
> If so, what will be the request message ID in the mapping message ?. In CR
> LDP, the request message ID TLV is mandatory for the mapping message.
Would
> it be correct to use the request ID of the last request received from
> upstream, for which mapping was already sent. This strategy will prevent
the
> upstream from reusing that message ID indefinitly.
>
> Please clarify and correct me if I am wrong.
>
> Thanks in advance,
> Regards,
> Vijay



From owner-mpls@UU.NET  Fri Jul 27 10:08:53 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 KAA19607
	for ; Fri, 27 Jul 2001 10:08:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzmm04767;
	Fri, 27 Jul 2001 14:09:38 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmm28099
	for mpls-outgoing; Fri, 27 Jul 2001 14:09: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 QQkzmm27887
	for ; Fri, 27 Jul 2001 14:08: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 QQkzmm26071
	for ; Fri, 27 Jul 2001 14:07:44 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 QQkzmm29987
	for ; Fri, 27 Jul 2001 14:07:43 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25033 for ; Fri, 27 Jul 2001 10:07:43 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11531 for mpls@uu.net; Fri, 27 Jul 2001 10:07: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 QQkzmh12014
	for ; Fri, 27 Jul 2001 12:55: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 QQkzmh27107
	for ; Fri, 27 Jul 2001 12:54:52 GMT
Received: from swan.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: swan.mail.pas.earthlink.net [207.217.120.123])
	id QQkzmh17747
	for ; Fri, 27 Jul 2001 12:54:51 GMT
Received: from homedt (1Cust27.VR1.MSP1.broadband.uu.net [63.13.185.27])
	by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id FAA17666;
	Fri, 27 Jul 2001 05:54:48 -0700 (PDT)
From: "Jeanne Gilbertson" 
To: 
Cc: 
Subject: Re: TE Mib, tunnel interfaces, ifstack layering?
Date: Fri, 27 Jul 2001 08:03:00 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: 
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Tom,

  I want to make sure I understand how you are using the MPLS mibs to 
associate one tunnel with multiple LSPs.  Does the following configuration 
agree with your example?

   Your example:
         mplsTunnel1->mplsInterface1->enet3
                    ->mplsInterface2->enet4	

   In mplsOutSegmentTable I have the following entries:

      mplsOutSegmentIfIndex.4 = 1  (for mplsInterface1)
      mplsOutSegmentIfIndex.5 = 2  (for mplsInterface2)

   In mplsXCTable I have two entries with mplsXCIndex = 25 that map to the
   two out segments associated with this cross-connect:
	mplsXCIndex.25.0.10.4 = 25            
      mplsOutSegmentIndex.25.0.10.4 = 4

      mplsXCIndex.25.0.20.5 = 25
      mplsOutSegmentIndex.25.0.20.5 = 5

   In mplsTunnelTable I have one entry for mplsTunnel1:
     mplsTunnelIndex.1.1.168496141.168562177 = 1,
     mplsTunnelXCPointer.1.1.168496141.168562177 = mplsXCIndex.25.0.10.4

   Therefore, since mplsXCIndex.25.0.20.5 = mplsXCIndex.25.0.10.4 = 25,
   mplsInterface2 is also associated with mplsTunnel1.  Is this correct?
   
--Jeanne


>At 01:16 PM 7/25/2001 -0500, John Muston wrote:
> >On Wed, Jul 25, 2001 at 09:25:07AM -0400, Thomas D. Nadeau wrote:
> > > At 07:30 PM 7/24/2001 -0400, Joan Cucchiara wrote:
> > >
> > >
> > > >"Thomas D. Nadeau" wrote:
> > > > >
> > > > > >In section 7 of draft-ietf-mpls-te-mib-06.txt the interface
> > > > > >stack is shown as:
> > > > > >
> > > > > >         +------------------------------------------------+
> > > > > >         | MPLS-Tunnel-interface ifType = mplsTunnel(150) |
> > > > > >         +------------------------------------------------+
> > > > > >         |        MPLS-interface ifType = mpls(166)       |
> > > > > >         +------------------------------------------------+
> > > > > >         |               Underlying Layer                 |
> > > > > >         +------------------------------------------------+
> > > >
> > > >
> > > >Hi Tom,
> > > >
> > > >Is it possible to have more than one Underlying Layer?
> > > >Should the above be changed to "Underlying Layer(s)"?
> > >
> > >          Yes. You are correct. Nice catch. Since it is
> > > possible to have more than one LSP servicing
> > > the tunnel, there could be multiple underlying interfaces.
> >
> >I thought that an mplsTunnelEntry refers to a single mplsXCTable row
> >(via the mplsTunnelXCPointer), which in turn describes a single LSP.
> >What am I missing?
> 
>          Not necessarily. Remember that the XC pointer can refer to a
> "group" of in/out segments. For example, if you were doing some
> sort of load sharing with your LSP, so that multiple paths met
> the constraints of the tunnel, it would be possible to share
> these paths. These paths might run over different outgoing
> interfaces (mpls) or physical (underlying layer), depending on
> how the mpls interfaces are stacked upon what lies under them.
> For example, the tunnel1 below uses 1 XC pointer, but this
> XC index specifies 2 outgoing labels which run over two
> different outgoing MPLS interfaces, which in-turn run
> over two different ethernet interfaces:
> 
>          mplsTunnel1->mplsInterface1->enet3
>                     ->mplsInterface2->enet4
> 
> You can also have a case where the tunnel1 uses 1 XC pointer,
> its XC index specifies 2 outgoing labels which run over ONE
> outgoing MPLS interface, which in-turn runs over
> one ethernet interface:
> 
>          mplsTunnel1->mplsInterface1->enet3
>                     ->mplsInterface2->enet3
> 
>          I think that in the majority of cases, however, the
> stacking situation will be the intuitive, one-to-one
> scenario:
> 
>          mplsTunnel1->mplsInterface1->enet
> 
> >If there were multiple LSPs under a tunnel, wouldn't that mean multiple
> >MPLS-iftype interfaces under an mplsTunnel-iftype interface, not
> >necessarily multiple layers below the MPLS-iftype interface?
> >
> >Though I can see having multiple layers below the MPLS-iftype interface
> >in cases like TE Link Bundling though.
> 
>          Yes.
> 
>          --Tom
> 



From owner-mpls@UU.NET  Fri Jul 27 10:43:33 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 KAA22918
	for ; Fri, 27 Jul 2001 10:43:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzmo05920;
	Fri, 27 Jul 2001 14:43:06 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmo03142
	for mpls-outgoing; Fri, 27 Jul 2001 14:42: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 QQkzmo03131
	for ; Fri, 27 Jul 2001 14:42: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 QQkzmo25340
	for ; Fri, 27 Jul 2001 14:41:31 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzmo21837
	for ; Fri, 27 Jul 2001 14:41:30 GMT
Message-ID: <3B617D99.B4AE055C@sandburst.com>
Date: Fri, 27 Jul 2001 10:41:29 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Vijayanand C 
Cc: mpls@UU.NET
Subject: Re: CR LDP Label Mapping
References: <71E32B42DB71D511BC7900024419247C0D05A6@LAKSHMI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vijay,

    Although it is intended to be informational, rather than standards track,
the LDP state machine draft actually provides perhaps clearer information
on handling local repair.  Not that 'local repair' in this sense is an artifact
of CR-LDP - hence it would not be explained in the LDP specification.

    Also, the fact that you do not need to propagate attribute changes all the
way to the ingress as a result of a local repair does not mean that you can't
get an accurate hop count.  I thought I made that clear.  If having an accurate
hop count is important, than local repair should be disallowed.  Simple enough,
really.

    Finally, the really long answer is that you CAN return a hop count as an
'unsolicited' label mapping even when operating in the DoD mode.  To see
why this is needed, think about the case where I have a mix of DoD, ordered
control and DU independent control mode LSRs involved in an LSP in basic
LDP.  In this mode, it is likely that a DoD LSR will receive an initial Label
Mapping with a Hop Count that is unknown and this will subsequently have
to be updated (when the LSP is established all the way to an egress).  When
this is necessary, no Label Request Message ID is required to determine the
context for the Label Mapping - the LSP 'request' (which was essentially
satisfied earlier) that it pertains to can be determined directly from the
Label.

--
Eric Gray

You wrote:

> Hello,
> For Dod Ordered control there is no need for checking the loop
> parameters(HC/PV) in the mapping message. This brings us to the question of
> why it is used in Mapping messages of CR-LDP. The understanding was that it
> helps the ingress to measure the TTL of the LSP for non- TTL decerementing
> doamins.Now,according to what you say, this purpose seems to be lost!
>
> Also in RFC 3036, in the procedure to handle to Label Mapping message(which
> is applicable for CR LDP also) , the mapping is redistributed to the
> upstream peers if the loop attributes change(LMP 22 to LMP 27), regardless
> of the distribution and control modes. So should this be modified or
> interpreted differently for CR LDP?
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Thursday, July 26, 2001 9:24 PM
> To: Vijayanand C
> Cc: mpls@UU.NET; gopinathg@ctd.hctech.com
> Subject: Re: CR LDP Label Mapping
>
> Vijay,
>
>     Short answer: your assumption about propagation of HC/PV beyond
> the intermediate LSR that intiates a 'local repair' is wrong.
>
>     Both Hop Count and Path Vector would need to be included in a label
> mapping message only to the extent that they were previously included.
> When using explicit route objects, use of Hop Count or Path Vector is
> somewhat redundant, since it is impossible to explicitly route a loop.
> While this is particularly in the strict ERO case, since it is possible for
> a loop to occur in that portion of an LSP that is either loosely specified,
> or strictly specified using an abstract node (e.g. - an AS number), either
> Hop Count or Path Vector need only to be used in loosely specified LSP
> segments in order to ensure that the resulting LSP is loop free.  Also, it
> is a general truth that - if you can be certain that ordered control is used
> through out the length of an LSP, than you can be sure Label Mappings
> will not be received by the ingress to any portion of the LSP if there is a
> loop in the downstream LSP setup control path.
>
>     In the case that you mention, for instance, as soon as the intermediate
> LSR receives a Label Mapping - with or without a Hop Count or a Path
> Vector - it may assume that the corresponding LSP is loop free.  Since -
> in this case - this LSR is the originator of the initial Label Request,
> there
> is no reason for it to send a new Label Mapping to any upstream peer.
>
>     This brings up a minor failing in the protocol: if Hop Count is used to
> set the TTL decrement value (at the ingress of the LSP) - for an ATM
> LSP for example - then the only way for the intermediate LSR to ensure
> that an accurate Hop Count is received by the ingress is to tear down the
> LSP and force the ingress to re-establish it.  This is a minor failing since
> the ingress can ensure that this happens by disallowing 'local repair' (the
> process you describe in this case) during LSP setup.
>
> --
> Eric Gray
>
> You wrote:
>
> > Hello all,
> > I have a question regarding label distribution in CR LDP.
> >
> > Assume that a CR LSP is established and at an intermediate LSR a Next Hop
> > change occurs. When the intermeditate LSR requests for and gets a mapping
> > from the New Next hop it will propagate the mapping upstream since the
> HC/PV
> > values have changed(according to procedures in RFC3036 which is applicable
> > for CR LDP also). This mapping is, strictly speaking, an unsolicited
> > mapping. So, is this behaviour of propagating the mapping upstream because
> > the HC /PV attributes differ from the values in the previous mapping,
> > correct for Dod Ordered control .
> >
> > If so, what will be the request message ID in the mapping message ?. In CR
> > LDP, the request message ID TLV is mandatory for the mapping message.
> Would
> > it be correct to use the request ID of the last request received from
> > upstream, for which mapping was already sent. This strategy will prevent
> the
> > upstream from reusing that message ID indefinitly.
> >
> > Please clarify and correct me if I am wrong.
> >
> > Thanks in advance,
> > Regards,
> > Vijay



From owner-mpls@UU.NET  Fri Jul 27 10:47: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 KAA23280
	for ; Fri, 27 Jul 2001 10:47: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 QQkzmp11263;
	Fri, 27 Jul 2001 14:47:49 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmp03772
	for mpls-outgoing; Fri, 27 Jul 2001 14:47: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 QQkzmp03767
	for ; Fri, 27 Jul 2001 14:47: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 QQkzmp01610
	for ; Fri, 27 Jul 2001 14:46:11 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 QQkzmp23735
	for ; Fri, 27 Jul 2001 14:46:11 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 KAA17107
	for ; Fri, 27 Jul 2001 10:46:07 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08549
	for ; Fri, 27 Jul 2001 10:46:09 -0400 (EDT)
Message-ID: <3B617EA1.4B339521@marconi.com>
Date: Fri, 27 Jul 2001 10:45: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: Diffserv or Intserv with rsvp-te?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Roberto Mameli (ERI)" wrote:
> 
> in  section 2.3 states:
> 
> "This document does not restrict the type of Integrated Service
> requests for reservations.  However, an implementation SHOULD
> support the Controlled-Load service [4] and the Class-of-Service
> service, see Section 4.8.".

This is vestigial from a previous revision.

The CoS C-Type was deleted in revision -08 of the RSVP-TE draft. 
Instead, IntServ Null-Service should be used when signaling those kinds
of LSPs.

This has been answered many times in the past.  See the mailing list
archives for more discussion.

-- David


From owner-mpls@UU.NET  Fri Jul 27 10:52: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 KAA23928
	for ; Fri, 27 Jul 2001 10:52: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 QQkzmp16387;
	Fri, 27 Jul 2001 14:52:34 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmp04262
	for mpls-outgoing; Fri, 27 Jul 2001 14:52:03 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 QQkzmp04192
	for ; Fri, 27 Jul 2001 14:51:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzmp07177
	for ; Fri, 27 Jul 2001 14:50:34 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzmp01082
	for ; Fri, 27 Jul 2001 14:50:34 GMT
Message-ID: <3B617FB8.C13620B4@sandburst.com>
Date: Fri, 27 Jul 2001 10:50:32 -0400
From: Eric Gray 
MIME-Version: 1.0
To: "Roberto Mameli (ERI)" ,
        George Swallow 
Cc: "'mpls@uu.net'" 
Subject: Re: Diffserv or Intserv with rsvp-te?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Roberto,

    The dangling reference has been previously pointed out on the list
and George Swallow has previously promised to fix it in the final
editing of the draft.  Last I heard (a small number of weeks ago),
George was really close to having that final editing version done.

    How about it George?

--
Eric Gray

You wrote:

> Hi Khuzema,
>
> in  section 2.3 states:
>
> "This document does not restrict the type of Integrated Service requests for reservations.  However, an implementation SHOULD support the Controlled-Load service [4] and the Class-of-Service service, see Section 4.8.".
>
> Therefore it seems that there is a new service class for RSVP-TE extension, i.e. the Class-of-Service service. So, not a new TSpec type, but simply a new class of service defined within the IntServ TSpec. However, there is no section 4.8 that explains it, and unfortunately I've not been able to find references anywhere. By the way, is there anyone that knows something about it?
>
> Moreover section 5.6 of  states that:
>
> "Both E-LSPs and L-LSPs can be established with bandwidth reservation or without bandwidth reservation. As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP with bandwidth reservation, Int-Serv's Controlled Load service (or possibly Guaranteed Service) is used and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the path(respectively Resv) message. As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP without bandwidth reservation, the Null Service specified in [NULL] is used.".
>
> So no Class-of-Service here is cited. Instead Controlled Load or Null Service type are suggested, and mapping between CoS and LSP is signaled through the DiffServ Object in the Path Message. Any clarification about that?
>
> Regards
> Roberto
>
> > -----Original Message-----
> > From: Khuzema Pithewan [mailto:KhuzemaP@netbrahma.com]
> > Sent: Friday, July 27, 2001 8:18 AM
> > To: 'mpls@uu.net'
> > Subject: Diffserv or Intserv with rsvp-te?
> >
> >
> > Hi,
> >
> > As rsvp-te carries IntServ Tspecs, is it necessary to be
> > intserv mechanism
> > in place for rsvp-te to work, or there can be diffserv?
> >
> > If diffserv can be use then how does intserv Tspec maps to
> > diffserv PHBs.?
> >
> > Regards,
> > Khuzema.
> > ------------------------------------------------
> > Net Brahma Technologies Private Limited
> > Internext Networking Software
> > A Microland Group Company
> > 777, 3rd 'a' cross, 18th Main
> > Koramangala VI th block
> > Bangalore-95
> > Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
> > Fax no        - (080) 5537233
> > email : khuzemap@netbrahma.com
> > www.netbrahma.com
> >



From owner-mpls@UU.NET  Fri Jul 27 11:00: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 SMTP id LAA24653
	for ; Fri, 27 Jul 2001 11:00: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 QQkzmq25919;
	Fri, 27 Jul 2001 15:01:03 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmq06582
	for mpls-outgoing; Fri, 27 Jul 2001 15:00: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 QQkzmq05859
	for ; Fri, 27 Jul 2001 15:00:19 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 QQkzmq12138
	for ; Fri, 27 Jul 2001 15:00:06 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 QQkzmq10770
	for ; Fri, 27 Jul 2001 15:00:06 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA05504 for mpls@uu.net; Fri, 27 Jul 2001 11:00:06 -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 QQkzmp04703
	for ; Fri, 27 Jul 2001 14:59:41 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 QQkzmp10599
	for ; Fri, 27 Jul 2001 14:59:23 GMT
Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brussels.cisco.com [144.254.15.68])
	id QQkzmp24058
	for ; Fri, 27 Jul 2001 14:59:23 GMT
Received: from BDEWONCK-W2K.cisco.com (dhcp-vlan6-3-182.cisco.com [64.103.3.182])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA28596
	for ; Fri, 27 Jul 2001 16:59:22 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20010727165909.01a96c68@brussels.cisco.com>
X-Sender: bdewonck@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 27 Jul 2001 16:59:21 +0200
To: mpls@UU.NET
From: Benoit Dewonck 
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

mpls@UU.NET



From owner-mpls@UU.NET  Fri Jul 27 11:23: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 LAA26960
	for ; Fri, 27 Jul 2001 11:23: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 QQkzmr20675;
	Fri, 27 Jul 2001 15:24:20 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmr26479
	for mpls-outgoing; Fri, 27 Jul 2001 15:23: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 QQkzmr26382
	for ; Fri, 27 Jul 2001 15:23: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 QQkzmr22517
	for ; Fri, 27 Jul 2001 15:23:09 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQkzmr19415
	for ; Fri, 27 Jul 2001 15:23:09 GMT
Received: from BLIULAPTOP ([172.16.24.62]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 27 Jul 2001 11:17:35 -0400
Message-ID: <007f01c116af$86ae1cd0$21eb883e@movaz.com>
From: "Adrian Farrel" 
To: "Khuzema Pithewan" 
Cc: "'mpls@uu.net'" 
References: <13D467F625FAD511AE2A00D0B7B917D71FF0FF@mailserver.netbrahma.com>
Subject: Re: mpls-te mib
Date: Fri, 27 Jul 2001 11:14:14 -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: 27 Jul 2001 15:17:36.0843 (UTC) FILETIME=[448F89B0:01C116AF]
Sender: owner-mpls@UU.NET
Precedence: bulk

Khuzema,

The TE MIB at transit nodes should (normally) be seen as read-only from an SNMP
point of view.  It is, therefore, updated by the protocol code.

Note that the exception is for 'static' LSPs where information about the LSPs
could be written to the TE MIB at transit nodes.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com
----- Original Message -----
From: "Khuzema Pithewan" 
To: "'mpls@uu.net'" 
Sent: Friday, July 27, 2001 2:15 AM
Subject: mpls-te mib


> Hi,
>
> In case of rsvp-te as signaling mechanism in place, how mpls-te mib values
> are updated at LSRs?  Is it dyanamically updated on reception of path-resv
> messages or updated by SNMP/CLI?
>
> Regards
> Khuzema.
> ------------------------------------------------
> Net Brahma Technologies Private Limited
> Internext Networking Software
> A Microland Group Company
> 777, 3rd 'a' cross, 18th Main
> Koramangala VI th block
> Bangalore-95
> Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
> Fax no        - (080) 5537233
> email : khuzemap@netbrahma.com
> www.netbrahma.com
>




From owner-mpls@UU.NET  Fri Jul 27 11:30: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 LAA27625
	for ; Fri, 27 Jul 2001 11:30: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 QQkzms28008;
	Fri, 27 Jul 2001 15:31:06 GMT
Received: by mail-control.mail.uu.net 
	id QQkzms27054
	for mpls-outgoing; Fri, 27 Jul 2001 15:30: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 QQkzms27043
	for ; Fri, 27 Jul 2001 15:30: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 QQkzms16317
	for ; Fri, 27 Jul 2001 15:30:06 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 QQkzms10944
	for ; Fri, 27 Jul 2001 15:30:06 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA08105 for mpls@uu.net; Fri, 27 Jul 2001 11: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 QQkzmr26916
	for ; Fri, 27 Jul 2001 15:29: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 QQkzmr14478
	for ; Fri, 27 Jul 2001 15:29:07 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQkzmr09872
	for ; Fri, 27 Jul 2001 15:29:07 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 LAA04959; Fri, 27 Jul 2001 11:29:06 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA24531; Fri, 27 Jul 2001 11:29:06 -0400 (EDT)
Message-Id: <200107271529.LAA24531@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: David Charlap 
cc: "'mpls@uu.net'" , swallow@cisco.com
Subject: Re: Diffserv or Intserv with rsvp-te? 
In-reply-to: Your message of "Fri, 27 Jul 2001 10:45:53 EDT."
             <3B617EA1.4B339521@marconi.com> 
Date: Fri, 27 Jul 2001 11:29:06 -0400
From: George Swallow 
Sender: owner-mpls@UU.NET
Precedence: bulk

> This is vestigial from a previous revision.

Yes.  In fact the dangling reference has been corrected in draft-09.
But I was asked to hold up publication of that while the IANA did a
final pass.  That ball seems to have been dropped and I've been
pinging folks to get it moving again.

> The CoS C-Type was deleted in revision -08 of the RSVP-TE draft. 
> Instead, IntServ Null-Service should be used when signaling those kinds
> of LSPs.
> 
> This has been answered many times in the past.  See the mailing list
> archives for more discussion.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Fri Jul 27 11:38: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 SMTP id LAA28253
	for ; Fri, 27 Jul 2001 11:38:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzms06654;
	Fri, 27 Jul 2001 15:39:08 GMT
Received: by mail-control.mail.uu.net 
	id QQkzms27679
	for mpls-outgoing; Fri, 27 Jul 2001 15:38: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 QQkzms27669
	for ; Fri, 27 Jul 2001 15:38:25 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzms27959
	for ; Fri, 27 Jul 2001 15:37:39 GMT
Received: from ws9.cdotb.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.41.72.121])
	id QQkzms23403
	for ; Fri, 27 Jul 2001 15:30:22 GMT
Received: from jnana.cdotb.ernet.in (jnana.cdotb.ernet.in [192.168.51.201])
	by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id UAA16306
	for ; Fri, 27 Jul 2001 20:48:11 +0500 (GMT+0500)
Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/28Nov00-1214PM)
	id UAA0000002856; Fri, 27 Jul 2001 20:49:49 +0500 (GMT+0500)
Message-ID: <3B6189A4.22294BA8@cdotb.ernet.in>
Date: Fri, 27 Jul 2001 21:02:53 +0530
From: "N.Suresh" 
Organization: C-DoT
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Some queries about MPLS implementation
Content-Type: multipart/alternative;
 boundary="------------5AA9ABAB17684D99CE3915B2"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------5AA9ABAB17684D99CE3915B2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,
    I am implementing the LDP on linux..
    i have some queries.

   (1)   The Hello Message send on as multicast on a Multicast socket.
Suppose
  that after adjacency discvery a connection is established between the
  two machines. Furthor LDP message transmission is going on the TCP
  socket. To identify the link usage we want again tranceive Hello
  message. I have the doubt that which socket we want to be use for the
  Hello message, whether the multicasted socket or the TCP socket.

(2)  If the  next hop has changed, and I have sent Label Abort msg to
that
  hop. Will it be reach at there?. Then what is the significance of the
  Label Aborted message?

(3)  The Address message is used to send the Interface message to the
next
  hop. But the Address Family field of the Address message tells the
  address types are either IPv4 or IPv6. What is it .

  (3.1) Is it a string value?. Actually interface address is a 48 bit
address of the
   interface.
  (3.2) So how it can be either IPv4 or IPv6?.
  (3.3) The interface address are taken care by the Link Level Layers.
   So what is the need for the LDP to care by the interface address.
   One of the ans. is to identify the link through which the Hello
   msg. is comming.

    anybody has any idea?

    thanx in advance
    regards

--
!============================================================================!
= Suresh N., Research Engineer, C-DoT, Bangalore.                            =
= Call me at : OFF: 2383951(Dir) / 2263399 (268)                             =
=              RES: 3334248  MOBILE: 98441 77782                             =
= Alternate email :  nsur_mys@email.com                                      =
= QOT: For fast-acting relief, try slowing down.
!============================================================================!



--------------5AA9ABAB17684D99CE3915B2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi all,

    I am implementing the LDP on linux..

    i have some queries.

   (1)   The Hello Message send on as multicast
on a Multicast socket. Suppose

  that after adjacency discvery a connection is established between
the

  two machines. Furthor LDP message transmission is going on the
TCP

  socket. To identify the link usage we want again tranceive Hello

  message. I have the doubt that which socket we want to be use
for the

  Hello message, whether the multicasted socket or the TCP socket.

(2)  If the  next hop has changed, and I have sent Label Abort
msg to that

  hop. Will it be reach at there?. Then what is the significance
of the

  Label Aborted message?

(3)  The Address message is used to send the Interface message
to the next

  hop. But the Address Family field of the Address message tells
the

  address types are either IPv4 or IPv6. What is it .

  (3.1) Is it a string value?. Actually interface address is a
48 bit address of the

   interface.

  (3.2) So how it can be either IPv4 or IPv6?.

  (3.3) The interface address are taken care by the Link Level
Layers.

   So what is the need for the LDP to care by the interface
address.

   One of the ans. is to identify the link through which
the Hello

   msg. is comming.

    anybody has any idea?

    thanx in advance

    regards

-- 
!============================================================================!
= Suresh N., Research Engineer, C-DoT, Bangalore.                            =
= Call me at : OFF: 2383951(Dir) / 2263399 (268)                             =
=              RES: 3334248  MOBILE: 98441 77782                             =
= Alternate email :  nsur_mys@email.com                                      =
= QOT: For fast-acting relief, try slowing down.
!============================================================================!

 

--------------5AA9ABAB17684D99CE3915B2--



From owner-mpls@UU.NET  Fri Jul 27 11:55: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 SMTP id LAA29996
	for ; Fri, 27 Jul 2001 11:55: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 QQkzmt07627;
	Fri, 27 Jul 2001 15:56:17 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmt29542
	for mpls-outgoing; Fri, 27 Jul 2001 15:55: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 QQkzmt29522
	for ; Fri, 27 Jul 2001 15:55:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzmt00806
	for ; Fri, 27 Jul 2001 15:54:28 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 QQkzmt05619
	for ; Fri, 27 Jul 2001 15:54:28 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA10445 for mpls@uu.net; Fri, 27 Jul 2001 11:54:27 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzmt29302
	for ; Fri, 27 Jul 2001 15:53:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzmt22981
	for ; Fri, 27 Jul 2001 15:49:33 GMT
Received: from nero.doit.wisc.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQkzmt19211
	for ; Fri, 27 Jul 2001 15:49:32 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id KAA17786;
	Fri, 27 Jul 2001 10:46:10 -0500
Date: Fri, 27 Jul 2001 10:46:09 -0500
From: "James R. Leu" 
To: "N.Suresh" 
Cc: mpls@UU.NET
Subject: Re: Some queries about MPLS implementation
Message-ID: <20010727104609.E17664@nero.doit.wisc.edu>
Reply-To: jleu@mindspring.com
References: <3B6189A4.22294BA8@cdotb.ernet.in>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <3B6189A4.22294BA8@cdotb.ernet.in>; from nsuresh@cdotb.ernet.in on Fri, Jul 27, 2001 at 09:02:53PM +0530
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

If you are referring to the ldp-portable package that is part of the
"MPLS for Linux" project, please post questions to the appropriate mailing
list:

http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

Thanks,
Jim

On Fri, Jul 27, 2001 at 09:02:53PM +0530, N.Suresh wrote:
> Hi all, 
>     I am implementing the LDP on linux.. 
>     i have some queries. 
> 
>    (1)   The Hello Message send on as multicast on a Multicast socket.
> Suppose 
>   that after adjacency discvery a connection is established between the 
>   two machines. Furthor LDP message transmission is going on the TCP 
>   socket. To identify the link usage we want again tranceive Hello 
>   message. I have the doubt that which socket we want to be use for the 
>   Hello message, whether the multicasted socket or the TCP socket. 
> 
> 
> (2)  If the  next hop has changed, and I have sent Label Abort msg to
> that 
>   hop. Will it be reach at there?. Then what is the significance of the 
>   Label Aborted message? 
> 
> 
> (3)  The Address message is used to send the Interface message to the
> next 
>   hop. But the Address Family field of the Address message tells the 
>   address types are either IPv4 or IPv6. What is it . 
> 
> 
>   (3.1) Is it a string value?. Actually interface address is a 48 bit
> address of the 
>    interface. 
>   (3.2) So how it can be either IPv4 or IPv6?. 
>   (3.3) The interface address are taken care by the Link Level Layers. 
>    So what is the need for the LDP to care by the interface address. 
>    One of the ans. is to identify the link through which the Hello 
>    msg. is comming. 
> 
> 
>     anybody has any idea? 
> 
> 
>     thanx in advance 
>     regards 
> 
> -- 
> 
> !=======================================================================
> =====!
> 
> = Suresh N., Research Engineer, C-DoT, Bangalore.
> =
> 
> = Call me at : OFF: 2383951(Dir) / 2263399 (268)
> =
> 
> =              RES: 3334248  MOBILE: 98441 77782
> =
> 
> = Alternate email :  nsur_mys@email.com
> =
> 
> = QOT: For fast-acting relief, try slowing down.
> 
> !=======================================================================
> =====!
>  

-- 
James R. Leu



From owner-mpls@UU.NET  Fri Jul 27 12:10: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 MAA01449
	for ; Fri, 27 Jul 2001 12:10: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 QQkzmu18298;
	Fri, 27 Jul 2001 16:10:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzmu20076
	for mpls-outgoing; Fri, 27 Jul 2001 16:10: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 QQkzmu20051
	for ; Fri, 27 Jul 2001 16:10: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 QQkzmu02803
	for ; Fri, 27 Jul 2001 16:09:10 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzmu21471
	for ; Fri, 27 Jul 2001 16:09:10 GMT
Message-ID: <3B619224.5ECAF457@sandburst.com>
Date: Fri, 27 Jul 2001 12:09:08 -0400
From: Eric Gray 
MIME-Version: 1.0
To: "N.Suresh" 
Cc: mpls@UU.NET
Subject: Re: Some queries about MPLS implementation
References: <3B6189A4.22294BA8@cdotb.ernet.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"N.Suresh" wrote:

> Hi all,
>     I am implementing the LDP on linux..
>     i have some queries.
>
>    (1)   The Hello Message send on as multicast on a Multicast socket. Suppose
>
>   that after adjacency discvery a connection is established between the
>   two machines. Furthor LDP message transmission is going on the TCP
>   socket. To identify the link usage we want again tranceive Hello
>   message. I have the doubt that which socket we want to be use for the
>   Hello message, whether the multicasted socket or the TCP socket.

Hello messages continue to be sent using UDP.

>
>
> (2)  If the  next hop has changed, and I have sent Label Abort msg to that
>   hop. Will it be reach at there?. Then what is the significance of the
>   Label Aborted message?

Two issues here: lost contact with next hop LDP peer and simple change
in routing resulting in a next hop change relative to a FEC.  In the first case
- where the Label Abort message would not be able to reach the peer - the
Label Abort is not indicated; you would instead purge all state relative to
this LDP peer, including any state relative to Label Requests.  In the latter
case, the Label Request Abort accelerates the process of making labels
and other LSP resources available in downstream LSRs when it is found
that this particular portion of the LSP is not needed.

>
>
> (3)  The Address message is used to send the Interface message to the next
>   hop. But the Address Family field of the Address message tells the
>   address types are either IPv4 or IPv6. What is it.

Correct.

>
>
>   (3.1) Is it a string value?. Actually interface address is a 48 bit address
> of the
>    interface.
>   (3.2) So how it can be either IPv4 or IPv6?.

Formats for these are explicitly defined in the specification (RFC 3036).

>
>   (3.3) The interface address are taken care by the Link Level Layers.
>    So what is the need for the LDP to care by the interface address.
>    One of the ans. is to identify the link through which the Hello
>    msg. is comming.

LDP needs to know what next hop addresses it may know an LDP peer
by through other means.  This is needed in order to allow the LSR to
bind labels received on an upstream interface to corresponding labels
distributed for a FEC from an LDP peer that is the routing next hop.

>
>
>     anybody has any idea?
>
>     thanx in advance
>     regards
>
> --
> !============================================================================!
> = Suresh N., Research Engineer, C-DoT, Bangalore.                            =
> = Call me at : OFF: 2383951(Dir) / 2263399 (268)                             =
> =              RES: 3334248  MOBILE: 98441 77782                             =
> = Alternate email :  nsur_mys@email.com                                      =
> = QOT: For fast-acting relief, try slowing down.
> !============================================================================!
>
>



From owner-mpls@UU.NET  Fri Jul 27 13:46:30 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 NAA12545
	for ; Fri, 27 Jul 2001 13:46: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 QQkznb12290;
	Fri, 27 Jul 2001 17:47:03 GMT
Received: by mail-control.mail.uu.net 
	id QQkznb18439
	for mpls-outgoing; Fri, 27 Jul 2001 17:46:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkznb18370
	for ; Fri, 27 Jul 2001 17:46: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 QQkznb26121
	for ; Fri, 27 Jul 2001 17:45:25 GMT
Received: from mail1.telefonica.com.ar by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQkznb05802
	for ; Fri, 27 Jul 2001 17:45:24 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Fri, 27 Jul 2001 14:45:19 -0300
Message-ID: <3D9C91EAD5D1D411851300508BCF243F02B1E7B3@MSTELEFONICA3>
From: Fabris Sergio 
To: mpls@UU.NET
Subject: Ordered aggregate
Date: Fri, 27 Jul 2001 14:45:13 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

what is the meaning for ORDERER AGGREGATE ? 
I read that E-LSP allows multiple ordered aggregates.  Then I read that an
E-LSP support eight BAs (behavior aggregates).

Does OA have a relation with BA??

Thank.

Sergio


From owner-mpls@UU.NET  Fri Jul 27 14:36: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 OAA17833
	for ; Fri, 27 Jul 2001 14:36: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 QQkzne19899;
	Fri, 27 Jul 2001 18:37:36 GMT
Received: by mail-control.mail.uu.net 
	id QQkzne12038
	for mpls-outgoing; Fri, 27 Jul 2001 18: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 QQkzne12029
	for ; Fri, 27 Jul 2001 18:36: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 QQkzne28862
	for ; Fri, 27 Jul 2001 18:34:46 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzne24368
	for ; Fri, 27 Jul 2001 18:34:46 GMT
Message-ID: <3B61B444.14876B63@sandburst.com>
Date: Fri, 27 Jul 2001 14:34:44 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Fabris Sergio 
Cc: mpls@UU.NET
Subject: Re: Ordered aggregate
References: <3D9C91EAD5D1D411851300508BCF243F02B1E7B3@MSTELEFONICA3>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sergio,

    Please see below.  BA='Behavior Aggregate', OA='Ordered Aggregate'.

You wrote:

> what is the meaning for ORDERER AGGREGATE ?

That's when you have a group of people arriving at a fast food restaurant
all at the same time. :-)

An 'ordered aggregate' is defined in "MPLS Support of Differentiated Services"
(at http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.txt), as
"The set of Behavior Aggregates which share an ordering constraint" where
a Behavior Aggregate is a set of "IP packets crossing a link and requiring the
same Diff-Serv behavior".

Sharing an ordering constraint seems to mean that the packets with in an OA
need to depart in the same order as they arrive.

An often used example of an OA is an AF Class - where different packets in
the same AF class get the same service, except that they may have different
drop precendents.  In this example, packets that are not dropped, should be in
the same order when they depart as the order in which they arrived.


>
> I read that E-LSP allows multiple ordered aggregates.  Then I read that an
> E-LSP support eight BAs (behavior aggregates).
>
> Does OA have a relation with BA??

See above.

>
>
> Thank.
>
> Sergio



From owner-mpls@UU.NET  Fri Jul 27 15:12: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 PAA21430
	for ; Fri, 27 Jul 2001 15:12: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 QQkzng04669;
	Fri, 27 Jul 2001 19:12:48 GMT
Received: by mail-control.mail.uu.net 
	id QQkzng04484
	for mpls-outgoing; Fri, 27 Jul 2001 19:12:15 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 QQkzng04421
	for ; Fri, 27 Jul 2001 19:11:53 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 QQkzng13773
	for ; Fri, 27 Jul 2001 19:11:42 GMT
Received: from mizar.Teleglobe.CA by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mizar.teleglobe.ca [199.202.44.68])
	id QQkzng08863
	for ; Fri, 27 Jul 2001 19:11:42 GMT
Received: from usresms03.teleglobe.com (usresms03.teleglobe.com [192.168.46.23])
	by mizar.Teleglobe.CA (MailDemon) with ESMTP
	id D99021E746; Fri, 27 Jul 2001 19:12:59 +0000 (GMT)
Received: by usresms03.teleglobe.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Jul 2001 15:11:41 -0400
Message-ID: <170E5E7779BCD3118C2A0008C7F40C19022D28DE@usresms03.teleglobe.com>
From: "St. Amour, Kevin" 
To: "'Eric Gray'" ,
        Fabris Sergio 
Cc: mpls@UU.NET
Subject: RE: Ordered aggregate
Date: Fri, 27 Jul 2001 15:11:40 -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



Kevin St.Amour
Teleglobe International
> 3900 Skyhawk Drive
> Chantilly, Virginia 20151
* IP Provisioning Engineer
*  703-871-7560
*kstamour@teleglobe.com
Chantilly, VA USA Office Hours: Monday through Friday 3 P.M - 11 P.M. EST




> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Friday, July 27, 2001 2:35 PM
> To: Fabris Sergio
> Cc: mpls@UU.NET
> Subject: Re: Ordered aggregate
> 
> 
> Sergio,
> 
>     Please see below.  BA='Behavior Aggregate', OA='Ordered 
> Aggregate'.
> 
> You wrote:
> 
> > what is the meaning for ORDERER AGGREGATE ?
> 
> That's when you have a group of people arriving at a fast 
> food restaurant
> all at the same time. :-)


So... Is BA='Behavior Aggregate'  when people request separate checks at one
table in a sit down restaurant?




> 
> An 'ordered aggregate' is defined in "MPLS Support of 
> Differentiated Services"
> (at 
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-0
9.txt), as
"The set of Behavior Aggregates which share an ordering constraint" where
a Behavior Aggregate is a set of "IP packets crossing a link and requiring
the
same Diff-Serv behavior".

Sharing an ordering constraint seems to mean that the packets with in an OA
need to depart in the same order as they arrive.

An often used example of an OA is an AF Class - where different packets in
the same AF class get the same service, except that they may have different
drop precendents.  In this example, packets that are not dropped, should be
in
the same order when they depart as the order in which they arrived.


>
> I read that E-LSP allows multiple ordered aggregates.  Then I read that an
> E-LSP support eight BAs (behavior aggregates).
>
> Does OA have a relation with BA??

See above.

>
>
> Thank.
>
> Sergio


From owner-mpls@UU.NET  Fri Jul 27 15:34: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 PAA23542
	for ; Fri, 27 Jul 2001 15:34: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 QQkzni02893;
	Fri, 27 Jul 2001 19:35:35 GMT
Received: by mail-control.mail.uu.net 
	id QQkzni06627
	for mpls-outgoing; Fri, 27 Jul 2001 19:35: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 QQkzni06562
	for ; Fri, 27 Jul 2001 19:34:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzni24786
	for ; Fri, 27 Jul 2001 19:34:23 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQkzni01603
	for ; Fri, 27 Jul 2001 19:34:22 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Fri, 27 Jul 2001 16:34:23 -0300
Message-ID: <3D9C91EAD5D1D411851300508BCF243F02BE1577@MSTELEFONICA3>
From: Fabris Sergio 
To: mpls@UU.NET
Subject: SLA
Date: Fri, 27 Jul 2001 16:34:09 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Is SLA (Service Level Agreement) a term for DiffServ networks only?
Can it be used in an MPLS network?


Thanks.

Sergio.


From owner-mpls@UU.NET  Fri Jul 27 15:41:17 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 PAA24400
	for ; Fri, 27 Jul 2001 15:41:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzni21291;
	Fri, 27 Jul 2001 19:41:59 GMT
Received: by mail-control.mail.uu.net 
	id QQkzni07277
	for mpls-outgoing; Fri, 27 Jul 2001 19:41:29 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 QQkzni07227
	for ; Fri, 27 Jul 2001 19:41: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 QQkzni13141
	for ; Fri, 27 Jul 2001 19:39:14 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQkzni07228
	for ; Fri, 27 Jul 2001 19:39:14 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Fri, 27 Jul 2001 16:39:11 -0300
Message-ID: <3D9C91EAD5D1D411851300508BCF243F02BE1587@MSTELEFONICA3>
From: Fabris Sergio 
To: mpls@UU.NET
Subject: E-LSP L-LSP
Date: Fri, 27 Jul 2001 16:39:05 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

if a domain is using E-LSP it doesn't use L-LSP. I am correct?
sergio.



From owner-mpls@UU.NET  Fri Jul 27 15:52:00 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 PAA25413
	for ; Fri, 27 Jul 2001 15:52:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkznj02527;
	Fri, 27 Jul 2001 19:52:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkznj08892
	for mpls-outgoing; Fri, 27 Jul 2001 19:52: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 QQkznj08790
	for ; Fri, 27 Jul 2001 19:51: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 QQkznj03555
	for ; Fri, 27 Jul 2001 19:51:56 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 QQkznj20995
	for ; Fri, 27 Jul 2001 19:51:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA28605 for mpls@uu.net; Fri, 27 Jul 2001 15:51: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 QQkznj08732
	for ; Fri, 27 Jul 2001 19:51:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkznj00159
	for ; Fri, 27 Jul 2001 19:50:32 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 QQkznj10444
	for ; Fri, 27 Jul 2001 19:50:32 GMT
Received: (qmail 28409 invoked by uid 104); 27 Jul 2001 19:50:31 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.374051 secs); 27/07/2001 12:50:30
Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227)
  by mother.pmc-sierra.bc.ca with SMTP; 27 Jul 2001 19:50:30 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6RJodP21353;
	Fri, 27 Jul 2001 12:50:39 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Jul 2001 12:54:31 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6DB9@BBY1EXM01>
From: Shahram Davari 
To: "'Fabris Sergio'" , mpls@UU.NET
Subject: RE: E-LSP L-LSP
Date: Fri, 27 Jul 2001 12:54:30 -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

You can use both in the same network.

-Shahram

> -----Original Message-----
> From: Fabris Sergio [mailto:fabriss@TELEFONICA.COM.AR]
> Sent: Friday, July 27, 2001 3:39 PM
> To: mpls@UU.NET
> Subject: E-LSP L-LSP
> 
> 
> if a domain is using E-LSP it doesn't use L-LSP. I am correct?
> sergio.
> 



From owner-mpls@UU.NET  Fri Jul 27 16:45: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 QAA01694
	for ; Fri, 27 Jul 2001 16:45: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 QQkznn18981;
	Fri, 27 Jul 2001 20:46:23 GMT
Received: by mail-control.mail.uu.net 
	id QQkznn03526
	for mpls-outgoing; Fri, 27 Jul 2001 20:45: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 QQkznn03511
	for ; Fri, 27 Jul 2001 20:45: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 QQkznm00691
	for ; Fri, 27 Jul 2001 20:44:54 GMT
Received: from ns1.arch.bellsouth.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2])
	id QQkznm16841
	for ; Fri, 27 Jul 2001 20:44:54 GMT
Received: (from ck@localhost)
	by ns1.arch.bellsouth.net (goaway/goaway) id f6RKijI11787;
	Fri, 27 Jul 2001 16:44:45 -0400 (EDT)
Date: Fri, 27 Jul 2001 16:44:45 -0400
From: Christian Kuhtz 
To: Fabris Sergio 
Cc: mpls@UU.NET
Subject: Re: SLA
Message-ID: <20010727164445.N2975@ns1.arch.bellsouth.net>
References: <3D9C91EAD5D1D411851300508BCF243F02BE1577@MSTELEFONICA3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <3D9C91EAD5D1D411851300508BCF243F02BE1577@MSTELEFONICA3>; from Fabris Sergio on Fri, Jul 27, 2001 at 04:34:09PM -0300
Sender: owner-mpls@UU.NET
Precedence: bulk


On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> Is SLA (Service Level Agreement) a term for DiffServ networks only?
> Can it be used in an MPLS network?

Sergio,

You can define an SLA for literally anything, including the performance of
your dry cleaner.  

And an MPLS network can be a 'DiffServ network'; I presume you intend to 
describe a network in which differentiated services of some kind are 
offered...

SLA per se has nothing to do with differentiated services, other than that 
differentiated services with methods and tools as proposed by IETF DiffServ 
can be used to provide a service as described by an SLA.  Note also that many 
SLAs actually have little to do with a direct link to the technology
underneath; it is possible that the service you purchase w/ SLA is identical 
to the service you purchase w/out SLA, or the service w/ SLA may be very 
different than the one w/out SLA.  An SLA can be a marketing gimmick,  a 
financial tool, a technology constraint, or any combination of the above.

The term SLA is a very much abused term, often driven more by marketecture and
marketeering than technology.  And then there's the set of issues around SLA's 
with teeth..

But, I'm rambling..  What specifically are you looking for?

Cheers,
Chris

-- 
Christian Kuhtz  -wk,  -hm
Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
"I speak for myself only.""


From owner-mpls@UU.NET  Fri Jul 27 17:02: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 RAA03455
	for ; Fri, 27 Jul 2001 17:02: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 QQkzno18936;
	Fri, 27 Jul 2001 21:03:31 GMT
Received: by mail-control.mail.uu.net 
	id QQkzno09444
	for mpls-outgoing; Fri, 27 Jul 2001 21:03: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 QQkzno09281
	for ; Fri, 27 Jul 2001 21:02:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzno02409
	for ; Fri, 27 Jul 2001 21:01:55 GMT
Received: from maildev.edc.gov.ab.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [142.229.18.133])
	id QQkzno07855
	for ; Fri, 27 Jul 2001 21:01:54 GMT
Received: by maildev.edc.gov.ab.ca with Internet Mail Service (5.5.2653.19)
	id <3CQQYK2F>; Fri, 27 Jul 2001 14:59:37 -0600
Message-ID: 
From: Mooney Sherman 
To: "'Christian Kuhtz'" ,
        Fabris Sergio
	 
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Fri, 27 Jul 2001 14:59:36 -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

I agree with some of your comments . It can be a marketing tool (gimmick?)
but normally a client has certain expectations or need - such as a certain
level of bandwidth requirement for the acceptable performance by an
application - say video streaming. So the Telco guarantees a certain
bandwidth that is acceptable or perhaps a maximum downtime in the form of
SLA. SLA is simply an agreement that a vendor or supplier can and will
deliver to a client. It can also be used in the context of an application
i.e. an application can process/ redirect at least Xnumber of tags for
instance in MPLS. Then this would be the SLA for it.

-----Original Message-----
From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
Sent: Friday, July 27, 2001 2:45 PM
To: Fabris Sergio
Cc: mpls@UU.NET
Subject: Re: SLA



On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> Is SLA (Service Level Agreement) a term for DiffServ networks only?
> Can it be used in an MPLS network?

Sergio,

You can define an SLA for literally anything, including the performance of
your dry cleaner.  

And an MPLS network can be a 'DiffServ network'; I presume you intend to 
describe a network in which differentiated services of some kind are 
offered...

SLA per se has nothing to do with differentiated services, other than that 
differentiated services with methods and tools as proposed by IETF DiffServ 
can be used to provide a service as described by an SLA.  Note also that
many 
SLAs actually have little to do with a direct link to the technology
underneath; it is possible that the service you purchase w/ SLA is identical

to the service you purchase w/out SLA, or the service w/ SLA may be very 
different than the one w/out SLA.  An SLA can be a marketing gimmick,  a 
financial tool, a technology constraint, or any combination of the above.

The term SLA is a very much abused term, often driven more by marketecture
and
marketeering than technology.  And then there's the set of issues around
SLA's 
with teeth..

But, I'm rambling..  What specifically are you looking for?

Cheers,
Chris

-- 
Christian Kuhtz  -wk,  -hm
Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
"I speak for myself only.""


From owner-mpls@UU.NET  Sat Jul 28 20:12: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 UAA04753
	for ; Sat, 28 Jul 2001 20:12: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 QQkzoc03267;
	Sat, 28 Jul 2001 00:44:18 GMT
Received: by mail-control.mail.uu.net 
	id QQkzoc10604
	for mpls-outgoing; Sat, 28 Jul 2001 00:43:48 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 QQkzoc10578
	for ; Sat, 28 Jul 2001 00:43: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 QQkzoc04828
	for ; Sat, 28 Jul 2001 00:41:43 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f185.law11.hotmail.com [64.4.17.185])
	id QQkzoc20522
	for ; Sat, 28 Jul 2001 00:41:43 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 27 Jul 2001 17:41:42 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Sat, 28 Jul 2001 00:41:42 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" 
To: Mooney.Sherman@gov.ab.ca, ck@arch.bellsouth.net, fabriss@TELEFONICA.COM.AR
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Fri, 27 Jul 2001 20:41:42 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 28 Jul 2001 00:41:42.0432 (UTC) FILETIME=[121A9200:01C116FE]
Sender: owner-mpls@UU.NET
Precedence: bulk

Fabriss,

Earlier comments are generally true. But recent SPs have tightened
the SLA spec which is specified in term of the following,

Bandwidth=100 Mbits,
Delay= less than 50 msecs,
and uptime = 99.999 %
and some more parameters ....

And vendors are getting serious in engineering their products
to meet and exceed these expectations.

Now the this can be implemented using several techologies and
frameworks, where MPLS and Diffserv both can be used mutually
or exclusively to meet the SLA.

I can go on and on but look at this article which gives a good
view on SLA.

http://www.networkmagazine.com/article/NMG20010521S0002

Irfan Lateef





>From: Mooney Sherman 
>To: 'Christian Kuhtz' ,        Fabris Sergio  
>
>CC: mpls@UU.NET
>Subject: RE: SLA
>Date: Fri, 27 Jul 2001 14:59:36 -0600
>
>I agree with some of your comments . It can be a marketing tool (gimmick?)
>but normally a client has certain expectations or need - such as a certain
>level of bandwidth requirement for the acceptable performance by an
>application - say video streaming. So the Telco guarantees a certain
>bandwidth that is acceptable or perhaps a maximum downtime in the form of
>SLA. SLA is simply an agreement that a vendor or supplier can and will
>deliver to a client. It can also be used in the context of an application
>i.e. an application can process/ redirect at least Xnumber of tags for
>instance in MPLS. Then this would be the SLA for it.
>
>-----Original Message-----
>From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
>Sent: Friday, July 27, 2001 2:45 PM
>To: Fabris Sergio
>Cc: mpls@UU.NET
>Subject: Re: SLA
>
>
>
>On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> > Is SLA (Service Level Agreement) a term for DiffServ networks only?
> > Can it be used in an MPLS network?
>
>Sergio,
>
>You can define an SLA for literally anything, including the performance of
>your dry cleaner.
>
>And an MPLS network can be a 'DiffServ network'; I presume you intend to
>describe a network in which differentiated services of some kind are
>offered...
>
>SLA per se has nothing to do with differentiated services, other than that
>differentiated services with methods and tools as proposed by IETF DiffServ
>can be used to provide a service as described by an SLA.  Note also that
>many
>SLAs actually have little to do with a direct link to the technology
>underneath; it is possible that the service you purchase w/ SLA is 
>identical
>
>to the service you purchase w/out SLA, or the service w/ SLA may be very
>different than the one w/out SLA.  An SLA can be a marketing gimmick,  a
>financial tool, a technology constraint, or any combination of the above.
>
>The term SLA is a very much abused term, often driven more by marketecture
>and
>marketeering than technology.  And then there's the set of issues around
>SLA's
>with teeth..
>
>But, I'm rambling..  What specifically are you looking for?
>
>Cheers,
>Chris
>
>--
>Christian Kuhtz  -wk,  -hm
>Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
>"I speak for myself only.""


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



From owner-mpls@UU.NET  Sat Jul 28 20:23: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 UAA08875
	for ; Sat, 28 Jul 2001 20:23: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 QQkzrb19756;
	Sat, 28 Jul 2001 19:50:20 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrb20901
	for mpls-outgoing; Sat, 28 Jul 2001 19:49: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 QQkzrb20866
	for ; Sat, 28 Jul 2001 19:49:41 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzrb13434
	for ; Sat, 28 Jul 2001 19:49:31 GMT
Received: from lennier.cc.vt.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lennier.cc.vt.edu [198.82.162.213])
	id QQkzrb21678
	for ; Sat, 28 Jul 2001 19:49:31 GMT
Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id f6SJnU7461044
	for ; Sat, 28 Jul 2001 15:49:30 -0400 (EDT)
Received: from flaw.vt.edu ([198.82.82.148])
 by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10)
 with ESMTP id <0GH700D3B8EH39@gkar.cc.vt.edu> for mpls@UU.NET; Sat,
 28 Jul 2001 15:49:30 -0400 (EDT)
Date: Sat, 28 Jul 2001 15:51:08 -0400
From: Raymond Law 
Subject: LSP utilization
X-Sender: flaw/mail.vt.edu@127.0.0.1
To: mpls@UU.NET
Message-id: <4.3.0.20010728154751.00af4100@127.0.0.1>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Content-type: text/plain; format=flowed; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

What is the utilization of LSPs in a real MPLS domain?  It seems that the 
LSP utilization should be efficient since the LSPs are configured as such 
by traffic analysis and administrative means.  Is there a situation in 
which a LSP is overutilized and another LSP may be underutilized?

Thanks.
Ray,



From owner-mpls@UU.NET  Sat Jul 28 20:42: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 UAA12226
	for ; Sat, 28 Jul 2001 20:42: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 QQkzrc07984;
	Sat, 28 Jul 2001 20:02:04 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrc26733
	for mpls-outgoing; Sat, 28 Jul 2001 20:01:34 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzrc26328
	for ; Sat, 28 Jul 2001 20:01: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 QQkzrc06307
	for ; Sat, 28 Jul 2001 20:01:08 GMT
Received: from lennier.cc.vt.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lennier.cc.vt.edu [198.82.162.213])
	id QQkzrc16852
	for ; Sat, 28 Jul 2001 20:01:08 GMT
Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id f6SK0x7462321;
	Sat, 28 Jul 2001 16:00:59 -0400 (EDT)
Received: from flaw.vt.edu ([198.82.82.148])
 by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10)
 with ESMTP id <0GH700B878XMGA@gkar.cc.vt.edu>; Sat,
 28 Jul 2001 16:00:58 -0400 (EDT)
Date: Sat, 28 Jul 2001 16:02:37 -0400
From: Raymond Law 
Subject: Re: LSP utilization
In-reply-to: <20010728155809.L15901@ns1.arch.bellsouth.net>
X-Sender: flaw/mail.vt.edu@127.0.0.1
To: Christian Kuhtz 
Cc: mpls@UU.NET
Message-id: <4.3.0.20010728160147.048ffd70@127.0.0.1>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Content-type: text/plain; format=flowed; charset=us-ascii
References: <4.3.0.20010728154751.00af4100@127.0.0.1>
 <4.3.0.20010728154751.00af4100@127.0.0.1>
Sender: owner-mpls@UU.NET
Precedence: bulk

So has anyone looked into increasing the efficiency of LSP usage in a MPLS 
domain or is there any solution already out there?

Thanks.
Ray,

At 03:58 PM 7/28/01 -0400, you wrote:

>Of course there is.  It's called 'real world'.
>
>TE is a tool, but not everything in the world (or anywhere near to that) is
>always TE'ed.
>
>Any notion that MPLS LSP utilization is always efficient is ridiculous.
>
>On Sat, Jul 28, 2001 at 03:51:08PM -0400, Raymond Law wrote:
> > What is the utilization of LSPs in a real MPLS domain?  It seems that the
> > LSP utilization should be efficient since the LSPs are configured as such
> > by traffic analysis and administrative means.  Is there a situation in
> > which a LSP is overutilized and another LSP may be underutilized?
> >
> > Thanks.
> > Ray,
> >
>
>--
>Christian Kuhtz  -wk,  -hm
>Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
>"I speak for myself only.""



From owner-mpls@UU.NET  Sat Jul 28 20:57:32 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 UAA15841
	for ; Sat, 28 Jul 2001 20:57: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 QQkzrv17272;
	Sun, 29 Jul 2001 00:58:00 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrv22818
	for mpls-outgoing; Sun, 29 Jul 2001 00:57:29 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 QQkzrv22807
	for ; Sun, 29 Jul 2001 00:57:17 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 QQkzrv05473
	for ; Sun, 29 Jul 2001 00:57:13 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 QQkzrv15672
	for ; Sun, 29 Jul 2001 00:57:12 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA10549 for mpls@uu.net; Sat, 28 Jul 2001 20:57:12 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzrv22789
	for ; Sun, 29 Jul 2001 00: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 QQkzrv20848
	for ; Sun, 29 Jul 2001 00:56:18 GMT
Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQkzrv10028
	for ; Sun, 29 Jul 2001 00:56:17 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6T0sUJ27341;
	Sat, 28 Jul 2001 17:54:30 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-10.cisco.com [10.21.96.10])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ADS05173 (AUTH rraszuk);
	Sat, 28 Jul 2001 17:56:15 -0700 (PDT)
Message-ID: <3B635EB3.CE1F9CAC@cisco.com>
Date: Sat, 28 Jul 2001 17:54:11 -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: Raymond Law 
CC: mpls@UU.NET
Subject: Re: LSP utilization
References: <4.3.0.20010728160147.048ffd70@127.0.0.1>
	 <4.3.0.20010728154751.00af4100@127.0.0.1>
	 <4.3.0.20010728154751.00af4100@127.0.0.1>
	 <20010728155809.L15901@ns1.arch.bellsouth.net>
	 <4.3.0.20010728160147.048ffd70@127.0.0.1> <4.3.0.20010728193810.03eb0580@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Ray,

What you are describing is in fact very true. In can be caused by nature
of Internet or even by geographic/time zone characteristics of your
users.

That was also the reason why some providers has requested the ability to
dynamically redimention the configured LSPs (just build a new one with a
adjusted bw). Now this new bw value is taken from the averaged real
traffic rates flowing via such an LSPs. 

I don't think such an ability requires an IETF draft as the solution to
address this is pretty simple, is contained within a router itself and
can be enabled by just one knob.

R. 

> Raymond Law wrote:
> 
> For example, once an MPLS solution is deployed after a pre-deployment
> analysis or simulation which found an optimal LSP setup in which all LSPs
> have 50% utilization. If some LSPs have 80% utilization whereas other LSPs
> have 30% utilization in deployment.
> 
> Or, due to the dynamic nature of Internet traffic, some LSPs become
> congested while other LSPs are underutilized.  Maybe a LSP setup
> specifically for best effort traffic experience a large amount of traffic
> during the busy hours and that LSP become overutilized.
> 
> Does any drafts address this problem or has any solution been attempted or
> proposed in dealing with this issue?
> 
> Thanks.
> Ray,
> 
> At 06:54 PM 7/28/01 -0400, you wrote:
> >On Sat, Jul 28, 2001 at 04:02:37PM -0400, Raymond Law wrote:
> > > So has anyone looked into increasing the efficiency of LSP usage in a MPLS
> > > domain or is there any solution already out there?
> > >
> >
> >Define "efficient".  Then we can start talking about what the problem
> >may be, whether it needs to be solved, and how to solve it.
> >
> >
> >
> >eric
> >
> > > Thanks.
> > > Ray,
> > >
> > > At 03:58 PM 7/28/01 -0400, you wrote:
> > >
> > > >Of course there is.  It's called 'real world'.
> > > >
> > > >TE is a tool, but not everything in the world (or anywhere near to
> > that) is
> > > >always TE'ed.
> > > >
> > > >Any notion that MPLS LSP utilization is always efficient is ridiculous.
> > > >
> > > >On Sat, Jul 28, 2001 at 03:51:08PM -0400, Raymond Law wrote:
> > > > > What is the utilization of LSPs in a real MPLS domain?  It seems
> > that the
> > > > > LSP utilization should be efficient since the LSPs are configured
> > as such
> > > > > by traffic analysis and administrative means.  Is there a situation in
> > > > > which a LSP is overutilized and another LSP may be underutilized?
> > > > >
> > > > > Thanks.
> > > > > Ray,
> > > > >
> > > >
> > > >--
> > > >Christian Kuhtz  -wk,  -hm
> > > >Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA,
> > U.S.
> > > >"I speak for myself only.""



From owner-mpls@UU.NET  Sat Jul 28 21:05: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 VAA17131
	for ; Sat, 28 Jul 2001 21:05: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 QQkzrw22366;
	Sun, 29 Jul 2001 01:06:35 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrw12568
	for mpls-outgoing; Sun, 29 Jul 2001 01:05: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 QQkzrw12283
	for ; Sun, 29 Jul 2001 01:05: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 QQkzrw03733
	for ; Sun, 29 Jul 2001 01:02:59 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 QQkzrw27045
	for ; Sun, 29 Jul 2001 01:02:59 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA11183 for mpls@uu.net; Sat, 28 Jul 2001 21:02: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 QQkzrw02975
	for ; Sun, 29 Jul 2001 01:02:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzrw09893
	for ; Sun, 29 Jul 2001 01:00:44 GMT
Received: from che-cse-104.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQkzrw17272
	for ; Sun, 29 Jul 2001 01:00:44 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f6T10go14704; Sat, 28 Jul 2001 21:00:42 -0400 (EDT)
Date: Sat, 28 Jul 2001 21:00:42 -0400
From: Eric Osborne 
To: Raymond Law 
Cc: Eric Osborne , mpls@UU.NET
Subject: Re: LSP utilization
Message-ID: <20010728210042.E12212@che-cse-104.cisco.com>
References: <4.3.0.20010728160147.048ffd70@127.0.0.1> <4.3.0.20010728154751.00af4100@127.0.0.1> <4.3.0.20010728154751.00af4100@127.0.0.1> <20010728155809.L15901@ns1.arch.bellsouth.net> <4.3.0.20010728160147.048ffd70@127.0.0.1> <20010728185429.B12212@che-cse-104.cisco.com> <4.3.0.20010728193810.03eb0580@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <4.3.0.20010728193810.03eb0580@127.0.0.1>; from rlaw@vt.edu on Sat, Jul 28, 2001 at 07:43:55PM -0400
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Sat, Jul 28, 2001 at 07:43:55PM -0400, Raymond Law wrote:
> For example, once an MPLS solution is deployed after a pre-deployment 
> analysis or simulation which found an optimal LSP setup in which all LSPs 
> have 50% utilization. If some LSPs have 80% utilization whereas other LSPs 
> have 30% utilization in deployment.

So first off, I assume you really mean s/MPLS/MPLS-TE/ in this
context.

TE LSPs (or most LDP LSPs) map to FECs.  A FEC is (currently) a
combination of address/mask.  And most traffic is going to be
headed to a FEC that is the BGP next-hop for a particular set of
traffic.  So what you're really asking is (I think) how to balance
traffic to BGP exit points - right?

One thing MPLS-TE can give you is better load-balancing than IP
forwarding, because of the opportunity for unequal-cost forwarding.
Since this is mpls@uu.net, I'll leave the issue of such forwarding
algorithms alone other than to say that they're vendor specific.  But
in the one implementation I'm intimately familiar with, there's a fair 
bit of control as to how you balance between multiple LSPs to the same 
FEC.

> Or, due to the dynamic nature of Internet traffic, some LSPs become 
> congested while other LSPs are underutilized.  Maybe a LSP setup 
> specifically for best effort traffic experience a large amount of traffic 
> during the busy hours and that LSP become overutilized.
> 
> Does any drafts address this problem or has any solution been attempted or 
> proposed in dealing with this issue?

I believe (but have not looked recently) that some of the
operationally-focused TE drafts discuss this.  If I understand what
you're saying (and I may not understand), then this is the same type
of traffic engineering problem one has with ATM VCs and other dynamic, 
bandwidth/QoS-related traffic-trunk stuff.  So since the question
probably reduces to the same whether it's MPLS or ATM, the answer for
ATM (mostly periodic reoptimization) should be the same.




eric 

> 
> Thanks.
> Ray,
> 
> 
> At 06:54 PM 7/28/01 -0400, you wrote:
> >On Sat, Jul 28, 2001 at 04:02:37PM -0400, Raymond Law wrote:
> > > So has anyone looked into increasing the efficiency of LSP usage in a MPLS
> > > domain or is there any solution already out there?
> > >
> >
> >Define "efficient".  Then we can start talking about what the problem
> >may be, whether it needs to be solved, and how to solve it.
> >
> >
> >
> >eric
> >
> > > Thanks.
> > > Ray,
> > >
> > > At 03:58 PM 7/28/01 -0400, you wrote:
> > >
> > > >Of course there is.  It's called 'real world'.
> > > >
> > > >TE is a tool, but not everything in the world (or anywhere near to 
> > that) is
> > > >always TE'ed.
> > > >
> > > >Any notion that MPLS LSP utilization is always efficient is ridiculous.
> > > >
> > > >On Sat, Jul 28, 2001 at 03:51:08PM -0400, Raymond Law wrote:
> > > > > What is the utilization of LSPs in a real MPLS domain?  It seems 
> > that the
> > > > > LSP utilization should be efficient since the LSPs are configured 
> > as such
> > > > > by traffic analysis and administrative means.  Is there a situation in
> > > > > which a LSP is overutilized and another LSP may be underutilized?
> > > > >
> > > > > Thanks.
> > > > > Ray,
> > > > >
> > > >
> > > >--
> > > >Christian Kuhtz  -wk,  -hm
> > > >Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, 
> > U.S.
> > > >"I speak for myself only.""



From owner-mpls@UU.NET  Sat Jul 28 21:24: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 VAA19436
	for ; Sat, 28 Jul 2001 21:24: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 QQkzrn06778;
	Sat, 28 Jul 2001 22:57:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrn04374
	for mpls-outgoing; Sat, 28 Jul 2001 22:57: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 QQkzrn04362
	for ; Sat, 28 Jul 2001 22:56: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 QQkzrn15357
	for ; Sat, 28 Jul 2001 22:55:19 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 QQkzrn02212
	for ; Sat, 28 Jul 2001 22:55:18 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA05210 for mpls@uu.net; Sat, 28 Jul 2001 18:55:18 -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 QQkzrn04162
	for ; Sat, 28 Jul 2001 22:54: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 QQkzrn05417
	for ; Sat, 28 Jul 2001 22:54:41 GMT
Received: from che-cse-104.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQkzrn11916
	for ; Sat, 28 Jul 2001 22:54:40 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f6SMsTI14288; Sat, 28 Jul 2001 18:54:29 -0400 (EDT)
Date: Sat, 28 Jul 2001 18:54:29 -0400
From: Eric Osborne 
To: Raymond Law 
Cc: Christian Kuhtz , mpls@UU.NET
Subject: Re: LSP utilization
Message-ID: <20010728185429.B12212@che-cse-104.cisco.com>
References: <4.3.0.20010728154751.00af4100@127.0.0.1> <4.3.0.20010728154751.00af4100@127.0.0.1> <20010728155809.L15901@ns1.arch.bellsouth.net> <4.3.0.20010728160147.048ffd70@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <4.3.0.20010728160147.048ffd70@127.0.0.1>; from rlaw@vt.edu on Sat, Jul 28, 2001 at 04:02:37PM -0400
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Sat, Jul 28, 2001 at 04:02:37PM -0400, Raymond Law wrote:
> So has anyone looked into increasing the efficiency of LSP usage in a MPLS 
> domain or is there any solution already out there?
> 

Define "efficient".  Then we can start talking about what the problem
may be, whether it needs to be solved, and how to solve it.



eric

> Thanks.
> Ray,
> 
> At 03:58 PM 7/28/01 -0400, you wrote:
> 
> >Of course there is.  It's called 'real world'.
> >
> >TE is a tool, but not everything in the world (or anywhere near to that) is
> >always TE'ed.
> >
> >Any notion that MPLS LSP utilization is always efficient is ridiculous.
> >
> >On Sat, Jul 28, 2001 at 03:51:08PM -0400, Raymond Law wrote:
> > > What is the utilization of LSPs in a real MPLS domain?  It seems that the
> > > LSP utilization should be efficient since the LSPs are configured as such
> > > by traffic analysis and administrative means.  Is there a situation in
> > > which a LSP is overutilized and another LSP may be underutilized?
> > >
> > > Thanks.
> > > Ray,
> > >
> >
> >--
> >Christian Kuhtz  -wk,  -hm
> >Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
> >"I speak for myself only.""



From owner-mpls@UU.NET  Sat Jul 28 22:23: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 WAA24827
	for ; Sat, 28 Jul 2001 22:23: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 QQkzrr16374;
	Sat, 28 Jul 2001 23:45:28 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrq27353
	for mpls-outgoing; Sat, 28 Jul 2001 23:44: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 QQkzrq27341
	for ; Sat, 28 Jul 2001 23:44: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 QQkzrq10388
	for ; Sat, 28 Jul 2001 23:42:22 GMT
Received: from lennier.cc.vt.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lennier.cc.vt.edu [198.82.162.213])
	id QQkzrq00371
	for ; Sat, 28 Jul 2001 23:42:22 GMT
Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id f6SNgK7484366;
	Sat, 28 Jul 2001 19:42:20 -0400 (EDT)
Received: from flaw.vt.edu ([198.82.82.148])
 by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10)
 with ESMTP id <0GH70076LJ6JKW@gkar.cc.vt.edu>; Sat,
 28 Jul 2001 19:42:19 -0400 (EDT)
Date: Sat, 28 Jul 2001 19:43:55 -0400
From: Raymond Law 
Subject: Re: LSP utilization
In-reply-to: <20010728185429.B12212@che-cse-104.cisco.com>
X-Sender: flaw/mail.vt.edu@127.0.0.1
To: Eric Osborne 
Cc: mpls@UU.NET
Message-id: <4.3.0.20010728193810.03eb0580@127.0.0.1>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Content-type: text/plain; format=flowed; charset=us-ascii
References: <4.3.0.20010728160147.048ffd70@127.0.0.1>
 <4.3.0.20010728154751.00af4100@127.0.0.1>
 <4.3.0.20010728154751.00af4100@127.0.0.1>
 <20010728155809.L15901@ns1.arch.bellsouth.net>
 <4.3.0.20010728160147.048ffd70@127.0.0.1>
Sender: owner-mpls@UU.NET
Precedence: bulk

For example, once an MPLS solution is deployed after a pre-deployment 
analysis or simulation which found an optimal LSP setup in which all LSPs 
have 50% utilization. If some LSPs have 80% utilization whereas other LSPs 
have 30% utilization in deployment.

Or, due to the dynamic nature of Internet traffic, some LSPs become 
congested while other LSPs are underutilized.  Maybe a LSP setup 
specifically for best effort traffic experience a large amount of traffic 
during the busy hours and that LSP become overutilized.

Does any drafts address this problem or has any solution been attempted or 
proposed in dealing with this issue?

Thanks.
Ray,


At 06:54 PM 7/28/01 -0400, you wrote:
>On Sat, Jul 28, 2001 at 04:02:37PM -0400, Raymond Law wrote:
> > So has anyone looked into increasing the efficiency of LSP usage in a MPLS
> > domain or is there any solution already out there?
> >
>
>Define "efficient".  Then we can start talking about what the problem
>may be, whether it needs to be solved, and how to solve it.
>
>
>
>eric
>
> > Thanks.
> > Ray,
> >
> > At 03:58 PM 7/28/01 -0400, you wrote:
> >
> > >Of course there is.  It's called 'real world'.
> > >
> > >TE is a tool, but not everything in the world (or anywhere near to 
> that) is
> > >always TE'ed.
> > >
> > >Any notion that MPLS LSP utilization is always efficient is ridiculous.
> > >
> > >On Sat, Jul 28, 2001 at 03:51:08PM -0400, Raymond Law wrote:
> > > > What is the utilization of LSPs in a real MPLS domain?  It seems 
> that the
> > > > LSP utilization should be efficient since the LSPs are configured 
> as such
> > > > by traffic analysis and administrative means.  Is there a situation in
> > > > which a LSP is overutilized and another LSP may be underutilized?
> > > >
> > > > Thanks.
> > > > Ray,
> > > >
> > >
> > >--
> > >Christian Kuhtz  -wk,  -hm
> > >Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, 
> U.S.
> > >"I speak for myself only.""



From owner-mpls@UU.NET  Sat Jul 28 22:52: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 WAA28213
	for ; Sat, 28 Jul 2001 22:52: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 QQkzoc22389;
	Sat, 28 Jul 2001 00:42:54 GMT
Received: by mail-control.mail.uu.net 
	id QQkzoc10549
	for mpls-outgoing; Sat, 28 Jul 2001 00:42: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 QQkzoc10541
	for ; Sat, 28 Jul 2001 00:42:18 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 QQkzoc23263
	for ; Sat, 28 Jul 2001 00:42:08 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f82.law11.hotmail.com [64.4.17.82])
	id QQkzoc21157
	for ; Sat, 28 Jul 2001 00:42:08 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 27 Jul 2001 17:42:07 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Sat, 28 Jul 2001 00:42:07 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" 
To: Mooney.Sherman@gov.ab.ca, ck@arch.bellsouth.net, fabriss@TELEFONICA.COM.AR
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Fri, 27 Jul 2001 20:42:07 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 28 Jul 2001 00:42:07.0428 (UTC) FILETIME=[2100A840:01C116FE]
Sender: owner-mpls@UU.NET
Precedence: bulk

Fabriss,

Earlier comments are generally true. But recent SPs have tightened
the SLA spec which is specified in term of the following,

Bandwidth=100 Mbits,
Delay= less than 50 msecs,
and uptime = 99.999 %
and some more parameters ....

And vendors are getting serious in engineering their products
to meet and exceed these expectations.

Now the this can be implemented using several techologies and
frameworks, where MPLS and Diffserv both can be used mutually
or exclusively to meet the SLA.

I can go on and on but look at this article which gives a good
view on SLA.

http://www.networkmagazine.com/article/NMG20010521S0002

Irfan Lateef





>From: Mooney Sherman 
>To: 'Christian Kuhtz' ,        Fabris Sergio  
>
>CC: mpls@UU.NET
>Subject: RE: SLA
>Date: Fri, 27 Jul 2001 14:59:36 -0600
>
>I agree with some of your comments . It can be a marketing tool (gimmick?)
>but normally a client has certain expectations or need - such as a certain
>level of bandwidth requirement for the acceptable performance by an
>application - say video streaming. So the Telco guarantees a certain
>bandwidth that is acceptable or perhaps a maximum downtime in the form of
>SLA. SLA is simply an agreement that a vendor or supplier can and will
>deliver to a client. It can also be used in the context of an application
>i.e. an application can process/ redirect at least Xnumber of tags for
>instance in MPLS. Then this would be the SLA for it.
>
>-----Original Message-----
>From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
>Sent: Friday, July 27, 2001 2:45 PM
>To: Fabris Sergio
>Cc: mpls@UU.NET
>Subject: Re: SLA
>
>
>
>On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> > Is SLA (Service Level Agreement) a term for DiffServ networks only?
> > Can it be used in an MPLS network?
>
>Sergio,
>
>You can define an SLA for literally anything, including the performance of
>your dry cleaner.
>
>And an MPLS network can be a 'DiffServ network'; I presume you intend to
>describe a network in which differentiated services of some kind are
>offered...
>
>SLA per se has nothing to do with differentiated services, other than that
>differentiated services with methods and tools as proposed by IETF DiffServ
>can be used to provide a service as described by an SLA.  Note also that
>many
>SLAs actually have little to do with a direct link to the technology
>underneath; it is possible that the service you purchase w/ SLA is 
>identical
>
>to the service you purchase w/out SLA, or the service w/ SLA may be very
>different than the one w/out SLA.  An SLA can be a marketing gimmick,  a
>financial tool, a technology constraint, or any combination of the above.
>
>The term SLA is a very much abused term, often driven more by marketecture
>and
>marketeering than technology.  And then there's the set of issues around
>SLA's
>with teeth..
>
>But, I'm rambling..  What specifically are you looking for?
>
>Cheers,
>Chris
>
>--
>Christian Kuhtz  -wk,  -hm
>Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
>"I speak for myself only.""


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



From owner-mpls@UU.NET  Sat Jul 28 22:55:32 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 WAA28401
	for ; Sat, 28 Jul 2001 22:55:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzqc03503;
	Sat, 28 Jul 2001 13:37:53 GMT
Received: by mail-control.mail.uu.net 
	id QQkzqc24336
	for mpls-outgoing; Sat, 28 Jul 2001 13:37: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 QQkzqc24319
	for ; Sat, 28 Jul 2001 13:37:04 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzqc18861
	for ; Sat, 28 Jul 2001 13:33:55 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzqc29618
	for ; Sat, 28 Jul 2001 13:33:52 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Jul 2001 19:01:35 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BABA@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: mpls@UU.NET
Subject: mplsTunnelHopTableIndex and mplsTunnelPathInUse
Date: Sat, 28 Jul 2001 19:01:35 +0530
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,

Could someone explain as to what is the difference between the
mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the
mplsTunnelTable . Dont they both point to an Explicit Route for the tunnel ?

Thanks,
Apratim 


From owner-mpls@UU.NET  Sun Jul 29 03:51: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 DAA08339
	for ; Sun, 29 Jul 2001 03:51: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 QQkzrz25468;
	Sun, 29 Jul 2001 01:49:06 GMT
Received: by mail-control.mail.uu.net 
	id QQkzrz16536
	for mpls-outgoing; Sun, 29 Jul 2001 01:48: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 QQkzrz16526
	for ; Sun, 29 Jul 2001 01:48:31 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 QQkzrz10139
	for ; Sun, 29 Jul 2001 01:47:15 GMT
Received: from smtp07.phx.gblx.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp07.phx.gblx.net [64.211.219.56])
	id QQkzrz27780
	for ; Sun, 29 Jul 2001 01:47:14 GMT
Received: (from daemon@localhost)
	by smtp07.phx.gblx.net (8.9.3/8.9.3) id SAA95626;
	Sat, 28 Jul 2001 18:46:05 -0700
Received: from 209-130-138-78.nas3.ROC.gblx.net(209.130.138.78), claiming to be "plonka"
 via SMTP by smtp07.phx.gblx.net, id smtpdX6AEaa; Sat Jul 28 18:45:52 2001
From: Jonathon Plonka 
To: "Irfan Lateef" 
Cc: Mooney.Sherman@gov.ab.ca, ck@arch.bellsouth.net, fabriss@TELEFONICA.COM.AR,
        mpls@UU.NET
Subject: Re: SLA
Date: Sat, 28 Jul 2001 21:46:36 -0400
Organization: Personal Account
Reply-To: jnplonka@earthlink.net
Message-ID: 
References: 
In-Reply-To: 
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hmm delay less than 50 ms on a global network,  Must be that new fangled
faster than light tacyon networking.

On Fri, 27 Jul 2001 20:41:42 -0400, Irfan Lateef wrote:

>Fabriss,
>
>Earlier comments are generally true. But recent SPs have tightened
>the SLA spec which is specified in term of the following,
>
>Bandwidth=100 Mbits,
>Delay= less than 50 msecs,
>and uptime = 99.999 %
>and some more parameters ....
>
>And vendors are getting serious in engineering their products
>to meet and exceed these expectations.
>
>Now the this can be implemented using several techologies and
>frameworks, where MPLS and Diffserv both can be used mutually
>or exclusively to meet the SLA.
>
>I can go on and on but look at this article which gives a good
>view on SLA.
>
>http://www.networkmagazine.com/article/NMG20010521S0002
>
>Irfan Lateef
>
>
>
>
>
>>From: Mooney Sherman 
>>To: 'Christian Kuhtz' ,        Fabris Sergio  
>>
>>CC: mpls@UU.NET
>>Subject: RE: SLA
>>Date: Fri, 27 Jul 2001 14:59:36 -0600
>>
>>I agree with some of your comments . It can be a marketing tool (gimmick?)
>>but normally a client has certain expectations or need - such as a certain
>>level of bandwidth requirement for the acceptable performance by an
>>application - say video streaming. So the Telco guarantees a certain
>>bandwidth that is acceptable or perhaps a maximum downtime in the form of
>>SLA. SLA is simply an agreement that a vendor or supplier can and will
>>deliver to a client. It can also be used in the context of an application
>>i.e. an application can process/ redirect at least Xnumber of tags for
>>instance in MPLS. Then this would be the SLA for it.
>>
>>-----Original Message-----
>>From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
>>Sent: Friday, July 27, 2001 2:45 PM
>>To: Fabris Sergio
>>Cc: mpls@UU.NET
>>Subject: Re: SLA
>>
>>
>>
>>On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
>> > Is SLA (Service Level Agreement) a term for DiffServ networks only?
>> > Can it be used in an MPLS network?
>>
>>Sergio,
>>
>>You can define an SLA for literally anything, including the performance of
>>your dry cleaner.
>>
>>And an MPLS network can be a 'DiffServ network'; I presume you intend to
>>describe a network in which differentiated services of some kind are
>>offered...
>>
>>SLA per se has nothing to do with differentiated services, other than that
>>differentiated services with methods and tools as proposed by IETF DiffServ
>>can be used to provide a service as described by an SLA.  Note also that
>>many
>>SLAs actually have little to do with a direct link to the technology
>>underneath; it is possible that the service you purchase w/ SLA is 
>>identical
>>
>>to the service you purchase w/out SLA, or the service w/ SLA may be very
>>different than the one w/out SLA.  An SLA can be a marketing gimmick,  a
>>financial tool, a technology constraint, or any combination of the above.
>>
>>The term SLA is a very much abused term, often driven more by marketecture
>>and
>>marketeering than technology.  And then there's the set of issues around
>>SLA's
>>with teeth..
>>
>>But, I'm rambling..  What specifically are you looking for?
>>
>>Cheers,
>>Chris
>>
>>--
>>Christian Kuhtz  -wk,  -hm
>>Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
>>"I speak for myself only.""
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Sun Jul 29 22:48: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 WAA12822
	for ; Sun, 29 Jul 2001 22:48: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 QQkzvv18724;
	Mon, 30 Jul 2001 02:49:27 GMT
Received: by mail-control.mail.uu.net 
	id QQkzvv20120
	for mpls-outgoing; Mon, 30 Jul 2001 02:48: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 QQkzvv20112
	for ; Mon, 30 Jul 2001 02:48:43 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 QQkzvv26919
	for ; Mon, 30 Jul 2001 02:47:23 GMT
Received: from lennier.cc.vt.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lennier.cc.vt.edu [198.82.162.213])
	id QQkzvv05993
	for ; Mon, 30 Jul 2001 02:47:23 GMT
Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id f6U2lMR48654
	for ; Sun, 29 Jul 2001 22:47:22 -0400 (EDT)
Received: from flaw.vt.edu ([198.82.82.148])
 by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10)
 with ESMTP id <0GH900JA7MEX26@gkar.cc.vt.edu> for mpls@UU.NET; Sun,
 29 Jul 2001 22:47:22 -0400 (EDT)
Date: Sun, 29 Jul 2001 22:48:36 -0400
From: Raymond Law 
Subject: Re: LSP utilization
X-Sender: flaw/mail.vt.edu@127.0.0.1
To: mpls@UU.NET
Message-id: <4.3.0.20010729224019.05780b40@127.0.0.1>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Content-type: text/plain; format=flowed; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

I agree the problem that I posed may not be MPLS specific; it applies to 
ATM circuits as well.  I think this may be more of a TE problem than a MPLS 
problem.

Basically I heard two solutions from the list.  The first solution is to 
assign a new LSP with the adjusted (measured from the first initial LSP) 
bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and 
the delay to do so) involved in this solution worth what it provides 
(better LSP utilization)?

The second solution is to do load balancing when setting up LSPs.  I agree 
that load balancing can definitely lead to better utilization of the 
LSPs.  However, I am more interested in the situation where, after load 
balancing and setting up LSPs for the FECs, the amount of traffic sent 
through the LSPs change, resulting in over- and under-utilization of some LSPs.

Ray,



From owner-mpls@UU.NET  Mon Jul 30 00:21: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 AAA15383
	for ; Mon, 30 Jul 2001 00:21: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 QQkzwb16726;
	Mon, 30 Jul 2001 04:21:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzwb06742
	for mpls-outgoing; Mon, 30 Jul 2001 04:21:16 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzwb06681
	for ; Mon, 30 Jul 2001 04:21: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 QQkzwb09586
	for ; Mon, 30 Jul 2001 04:19:42 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQkzwb14633
	for ; Mon, 30 Jul 2001 04:19:40 GMT
Received: from multitech.co.in ([192.168.1.32])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6U4FeP21300;
	Mon, 30 Jul 2001 09:45:41 +0530
Message-ID: <3B64E162.15115A57@multitech.co.in>
Date: Mon, 30 Jul 2001 09:54:02 +0530
From: abhay 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Apratim Mukherjee 
CC: mpls@UU.NET
Subject: Re: mplsTunnelHopTableIndex and mplsTunnelPathInUse
X-Priority: 2 (High)
References: <13D467F625FAD511AE2A00D0B7B917D706BABA@mailserver.netbrahma.com>
Content-Type: multipart/alternative;
 boundary="------------C148439EB1E0838E2AD14D06"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------C148439EB1E0838E2AD14D06
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Apratim,

       mplsTunnelHopTableIndex refers to the index of the configured explicit paths.

       But it was Cisco's great invention of of getting the path option and mplsTunnel

       PathInUse contains the index of the configured hops currently used by the tunnel

       Yes they both point to the explicit route.

       On  lighter note,it was written to confuse the readers..

       Regards,

       Abhay

Apratim Mukherjee wrote:

> Hi,
>
> Could someone explain as to what is the difference between the
> mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the
> mplsTunnelTable . Dont they both point to an Explicit Route for the tunnel ?
>
> Thanks,
> Apratim

--------------C148439EB1E0838E2AD14D06
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Apratim,



       mplsTunnelHopTableIndex refers to the index of the configured explicit paths.



       But it was Cisco's great invention of of getting the path option and mplsTunnel



       PathInUse contains the index of the configured hops currently used by the tunnel



       Yes they both point to the explicit route.



       On  lighter note,it was written to confuse the readers..



       Regards,



       Abhay




Apratim Mukherjee wrote:

Hi,

Could someone explain as to what is the difference between the

mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the

mplsTunnelTable . Dont they both point to an Explicit Route for the
tunnel ?

Thanks,

Apratim



--------------C148439EB1E0838E2AD14D06--



From owner-mpls@UU.NET  Mon Jul 30 00:30: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 AAA15641
	for ; Mon, 30 Jul 2001 00:30: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 QQkzwc07845;
	Mon, 30 Jul 2001 04:30:47 GMT
Received: by mail-control.mail.uu.net 
	id QQkzwc07298
	for mpls-outgoing; Mon, 30 Jul 2001 04:30: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 QQkzwc07283
	for ; Mon, 30 Jul 2001 04:30:02 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 QQkzwb06316
	for ; Mon, 30 Jul 2001 04:27:52 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQkzwb02374
	for ; Mon, 30 Jul 2001 04:27:49 GMT
Received: from multitech.co.in ([192.168.1.32])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f6U4NhP21704;
	Mon, 30 Jul 2001 09:53:43 +0530
Message-ID: <3B64E345.8AF70684@multitech.co.in>
Date: Mon, 30 Jul 2001 10:02:05 +0530
From: abhay 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Khuzema Pithewan 
CC: "'mpls@uu.net'" 
Subject: Re: mpls-te mib
X-Priority: 2 (High)
References: <13D467F625FAD511AE2A00D0B7B917D71FF0FF@mailserver.netbrahma.com>
Content-Type: multipart/alternative;
 boundary="------------C8E5472BD91D5AE5ADC9DE6A"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------C8E5472BD91D5AE5ADC9DE6A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Khuzema,

       MPLS-TE MIB values are according to these rules which I follow:

       1) Static LSP's and Configured Tunnels can be created by CLI/SNMP at the head end

       2)The Signaling protocol,whatever it is,will update the values in the transit and

         the egress routers.

       3)The only thing SNMP can do is generate traps ,if defined for some immediate user

         notification such as tunnel going down.

       4)A Transit router can be a head end for another tunnel.

         Generally you might wonder,what if you give the same tunnel name..?
         on the transit router,here u have a chance that there are 2 tunnels with

         the same identifiers,here comes the indices of the mplsTunnelName into picture.

         This will solve all the nasty problems..

         Regards,

         Abhay



Khuzema Pithewan wrote:

> Hi,
>
> In case of rsvp-te as signaling mechanism in place, how mpls-te mib values
> are updated at LSRs?  Is it dyanamically updated on reception of path-resv
> messages or updated by SNMP/CLI?
>
> Regards
> Khuzema.
> ------------------------------------------------
> Net Brahma Technologies Private Limited
> Internext Networking Software
> A Microland Group Company
> 777, 3rd 'a' cross, 18th Main
> Koramangala VI th block
> Bangalore-95
> Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
> Fax no        - (080) 5537233
> email : khuzemap@netbrahma.com
> www.netbrahma.com

--------------C8E5472BD91D5AE5ADC9DE6A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Khuzema,



       MPLS-TE MIB values are according to these rules which I follow:



       1) Static LSP's and Configured Tunnels can be created by CLI/SNMP at the head end



       2)The Signaling protocol,whatever it is,will update the values in the transit and



         the egress routers.



       3)The only thing SNMP can do is generate traps ,if defined for some immediate user



         notification such as tunnel going down.



       4)A Transit router can be a head end for another tunnel.



         Generally you might wonder,what if you give the same tunnel name..?
         on the transit router,here u have a chance that there are 2 tunnels with



         the same identifiers,here comes the indices of the mplsTunnelName into picture.



         This will solve all the nasty problems..



         Regards,



         Abhay



 




Khuzema Pithewan wrote:

Hi,

In case of rsvp-te as signaling mechanism in place, how mpls-te mib
values

are updated at LSRs?  Is it dyanamically updated on reception
of path-resv

messages or updated by SNMP/CLI?

Regards

Khuzema.

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

Net Brahma Technologies Private Limited

Internext Networking Software

A Microland Group Company

777, 3rd 'a' cross, 18th Main

Koramangala VI th block

Bangalore-95

Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232

Fax no        - (080) 5537233

email : khuzemap@netbrahma.com

www.netbrahma.com



--------------C8E5472BD91D5AE5ADC9DE6A--



From owner-mpls@UU.NET  Mon Jul 30 03:26:53 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 DAA04879
	for ; Mon, 30 Jul 2001 03:26: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 QQkzwn14709;
	Mon, 30 Jul 2001 07:27:31 GMT
Received: by mail-control.mail.uu.net 
	id QQkzwn19433
	for mpls-outgoing; Mon, 30 Jul 2001 07:27: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 QQkzwn19425
	for ; Mon, 30 Jul 2001 07:26:48 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 QQkzwn20280
	for ; Mon, 30 Jul 2001 07:24:50 GMT
Received: from manali.in.allegronetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.94.179])
	id QQkzwn18548
	for ; Mon, 30 Jul 2001 07:24:47 GMT
Received: by manali.in.allegronetworks.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 30 Jul 2001 12:54:44 +0530
Message-ID: <2310F01DA869D411A86900508BD635411E7BAA@manali.in.allegronetworks.com>
From: Abhishek Choudhary 
To: "'Apratim Mukherjee'" 
Cc: "'mpls@UU.NET'" 
Subject: RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse
Date: Mon, 30 Jul 2001 12:54:41 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C118C8.B2C40080"
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_01C118C8.B2C40080
Content-Type: text/plain;
	charset="iso-8859-1"

Apratim
	if u look at the mplstunnelHopTable it's triply indexed.
mplsTunnelHopTableIndex is the first and mpldTunnelPathInUse is the second
index to that table. using these two indexes u get a list of hops which is
being used by this tunnel instance.



-----Original Message-----
From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]
Sent: Saturday, July 28, 2001 7:02 PM
To: mpls@UU.NET
Subject: mplsTunnelHopTableIndex and mplsTunnelPathInUse


Hi,

Could someone explain as to what is the difference between the
mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the
mplsTunnelTable . Dont they both point to an Explicit Route for the tunnel ?

Thanks,
Apratim 

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






RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse




Apratim

        if u look =
at the mplstunnelHopTable it's triply indexed. mplsTunnelHopTableIndex =
is the first and mpldTunnelPathInUse is the second index to that table. =
using these two indexes u get a list of hops which is being used by =
this tunnel instance.







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

From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com=
]

Sent: Saturday, July 28, 2001 7:02 PM

To: mpls@UU.NET

Subject: mplsTunnelHopTableIndex and =
mplsTunnelPathInUse






Hi,




Could someone explain as to what is the difference =
between the

mplsTunnelHopTableIndex and mplsTunnelPathInUse =
objects in the

mplsTunnelTable . Dont they both point to an =
Explicit Route for the tunnel ?




Thanks,

Apratim 





------_=_NextPart_001_01C118C8.B2C40080--


From owner-mpls@UU.NET  Mon Jul 30 05:08: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 SMTP id FAA09826
	for ; Mon, 30 Jul 2001 05:08: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 QQkzwu19714;
	Mon, 30 Jul 2001 09:09:01 GMT
Received: by mail-control.mail.uu.net 
	id QQkzwu06136
	for mpls-outgoing; Mon, 30 Jul 2001 09:08: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 QQkzwu06108
	for ; Mon, 30 Jul 2001 09:08:18 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 QQkzwu03413
	for ; Mon, 30 Jul 2001 09:07:53 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzwu18347
	for ; Mon, 30 Jul 2001 09:07:48 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Jul 2001 14:35:27 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BABC@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'Abhishek Choudhary'" 
Cc: "'mpls@UU.NET'" 
Subject: RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse
Date: Mon, 30 Jul 2001 14:35:23 +0530
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 Abhishek,

	> if u look at the mplstunnelHopTable it's triply indexed.
>mplsTunnelHopTableIndex is the first and mpldTunnelPathInUse is the >second
index to that table. using these two indexes u get a list of hops >which is
being used by this tunnel instance.

Ya , you are right . But would not the values of the two indexes be the same
for any tunnel instance , as Abhay also pointed out . If two indexes have
the same value , wouldn't that mean a duplication ? Or is that the Hop Table
could look like this :

HopListLindex  PathOptionIndex HopIndex [ Hop Details ]
	1			1              1		ERO1
	1			1              2                   ERO1
	1			1	    3                   ERO1
	1			2              4                   ERO2
	1			2              5                   ERO2
	1			2              6                   ERO2
	1			2              7                   ERO2

	where the ERO1's denote the subobjects of the primary ERO
	and ERO2's denote the subobjects of the secondary ERO ?

	In the normal case then HopListIndex = PathOptionIndex always and
also HopListIndex is a misleading name as it is the index to TWO hop lists
and is not an unique identifier of a Hop List .

	Thanks 
	Apratim

> -----Original Message----- 
> From: Apratim Mukherjee [ mailto:ApratimM@netbrahma.com] 
> Sent: Saturday, July 28, 2001 7:02 PM 
> To: mpls@UU.NET 
> Subject: mplsTunnelHopTableIndex and mplsTunnelPathInUse 
> 
> 
> Hi, 
> 
> Could someone explain as to what is the difference between the 
> mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the 
> mplsTunnelTable . Dont they both point to an Explicit Route for the tunnel
> ? 
> 
> Thanks, 
> Apratim 
> 
> 


From owner-mpls@UU.NET  Mon Jul 30 05:34:30 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 FAA11111
	for ; Mon, 30 Jul 2001 05:34: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 QQkzww23221;
	Mon, 30 Jul 2001 09:35:05 GMT
Received: by mail-control.mail.uu.net 
	id QQkzww08321
	for mpls-outgoing; Mon, 30 Jul 2001 09:34: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 QQkzww08316
	for ; Mon, 30 Jul 2001 09:34:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzww08361
	for ; Mon, 30 Jul 2001 09:32:27 GMT
Received: from manali.in.allegronetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.94.179])
	id QQkzww12651
	for ; Mon, 30 Jul 2001 09:32:24 GMT
Received: by manali.in.allegronetworks.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 30 Jul 2001 15:02:20 +0530
Message-ID: <2310F01DA869D411A86900508BD635411E7BAB@manali.in.allegronetworks.com>
From: Abhishek Choudhary 
To: "'Apratim Mukherjee'" 
Cc: "'mpls@UU.NET'" 
Subject: RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse
Date: Mon, 30 Jul 2001 15:02:19 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C118DA.872FD2C0"
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_01C118DA.872FD2C0
Content-Type: text/plain;
	charset="iso-8859-1"

Apratim
	see it this way. normally every tunnel will have one corresponding
HopListIndex(mplsTunnelHopTableIndex), which will have multiple
PathOptionIndex corresponding to each instance of the
tunnel(mplsTunnelPathInUse), each consisting of multiple HopIndex(es). 

so two tunnel instances will have the same HopListIndex but different
PathOptionIndex.

abhishek

-----Original Message-----
From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]
Sent: Monday, July 30, 2001 2:35 PM
To: 'Abhishek Choudhary'
Cc: 'mpls@UU.NET'
Subject: RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse


Hi Abhishek,

	> if u look at the mplstunnelHopTable it's triply indexed.
>mplsTunnelHopTableIndex is the first and mpldTunnelPathInUse is the >second
index to that table. using these two indexes u get a list of hops >which is
being used by this tunnel instance.

Ya , you are right . But would not the values of the two indexes be the same
for any tunnel instance , as Abhay also pointed out . If two indexes have
the same value , wouldn't that mean a duplication ? Or is that the Hop Table
could look like this :

HopListLindex  PathOptionIndex HopIndex [ Hop Details ]
	1			1              1		ERO1
	1			1              2                   ERO1
	1			1	    3                   ERO1
	1			2              4                   ERO2
	1			2              5                   ERO2
	1			2              6                   ERO2
	1			2              7                   ERO2

	where the ERO1's denote the subobjects of the primary ERO
	and ERO2's denote the subobjects of the secondary ERO ?

	In the normal case then HopListIndex = PathOptionIndex always and
also HopListIndex is a misleading name as it is the index to TWO hop lists
and is not an unique identifier of a Hop List .

	Thanks 
	Apratim

> -----Original Message----- 
> From: Apratim Mukherjee [ mailto:ApratimM@netbrahma.com] 
> Sent: Saturday, July 28, 2001 7:02 PM 
> To: mpls@UU.NET 
> Subject: mplsTunnelHopTableIndex and mplsTunnelPathInUse 
> 
> 
> Hi, 
> 
> Could someone explain as to what is the difference between the 
> mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the 
> mplsTunnelTable . Dont they both point to an Explicit Route for the tunnel
> ? 
> 
> Thanks, 
> Apratim 
> 
> 

------_=_NextPart_001_01C118DA.872FD2C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse




Apratim

        see it =
this way. normally every tunnel will have one corresponding =
HopListIndex(mplsTunnelHopTableIndex), which will have multiple =
PathOptionIndex corresponding to each instance of the =
tunnel(mplsTunnelPathInUse), each consisting of multiple HopIndex(es). =




so two tunnel instances will have the same =
HopListIndex but different PathOptionIndex.




abhishek




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

From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com=
]

Sent: Monday, July 30, 2001 2:35 PM

To: 'Abhishek Choudhary'

Cc: 'mpls@UU.NET'

Subject: RE: mplsTunnelHopTableIndex and =
mplsTunnelPathInUse






Hi Abhishek,




        > if u =
look at the mplstunnelHopTable it's triply indexed.

>mplsTunnelHopTableIndex is the first and =
mpldTunnelPathInUse is the >second

index to that table. using these two indexes u get a =
list of hops >which is

being used by this tunnel instance.




Ya , you are right . But would not the values of the =
two indexes be the same

for any tunnel instance , as Abhay also pointed out =
. If two indexes have

the same value , wouldn't that mean a duplication ? =
Or is that the Hop Table

could look like this :




HopListLindex  PathOptionIndex HopIndex [ Hop =
Details ]

        1       =
        =
        =
1            =
;  1        =
        ERO1

        1       =
        =
        =
1            =
;  =
2            =
;       ERO1

        1       =
        =
        =
1           =
3            =
;       ERO1

        1       =
        =
        =
2            =
;  =
4            =
;       ERO2

        1       =
        =
        2    &nbs=
p;         =
5            =
;       ERO2

        1       =
        =
        =
2            =
;  =
6            =
;       ERO2

        1       =
        =
        =
2            =
;  =
7            =
;       ERO2




        where the =
ERO1's denote the subobjects of the primary ERO

        and =
ERO2's denote the subobjects of the secondary ERO ?




        In the =
normal case then HopListIndex =3D PathOptionIndex always and

also HopListIndex is a misleading name as it is the =
index to TWO hop lists

and is not an unique identifier of a Hop List =
.




        Thanks =


        Apratim




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

> From: Apratim Mukherjee [ mailto:ApratimM@netbrahma.com=
] 

> Sent: Saturday, July 28, 2001 7:02 PM 

> To: mpls@UU.NET 

> Subject: mplsTunnelHopTableIndex and =
mplsTunnelPathInUse 

> 

> 

> Hi, 

> 

> Could someone explain as to what is the =
difference between the 

> mplsTunnelHopTableIndex and mplsTunnelPathInUse =
objects in the 

> mplsTunnelTable . Dont they both point to an =
Explicit Route for the tunnel

> ? 

> 

> Thanks, 

> Apratim 

> 

> 





------_=_NextPart_001_01C118DA.872FD2C0--


From owner-mpls@UU.NET  Mon Jul 30 07:25: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 HAA17210
	for ; Mon, 30 Jul 2001 07:25: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 QQkzxd22106;
	Mon, 30 Jul 2001 11:25:38 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxd26174
	for mpls-outgoing; Mon, 30 Jul 2001 11:25: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 QQkzxd26116
	for ; Mon, 30 Jul 2001 11:24: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 QQkzxd25606
	for ; Mon, 30 Jul 2001 11:24:47 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzxd21149
	for ; Mon, 30 Jul 2001 11:24:44 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Jul 2001 16:52:24 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D750E62A@mailserver.netbrahma.com>
From: Katta Sambasiva Rao 
To: "'mpls@uu.net'" 
Subject: CR-LDP - AS fld. len. limitation
Date: Mon, 30 Jul 2001 16:52:17 +0530
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,
In CR-LDP draft, it is assumed that Autonomous System (AS) number length as
2 bytes. (Section: 4.7.3)

But work is underway in IETF, for supporting 4 octet AS number.
There is a draft in progress by IDR work group which is talking about
extending BGP to support 4 octet AS number.

I am not sure whether the 4 octet AS number support is a BGP required
feature or it is a general requirement for Internet.

If 4 octet AS number support is necessary , it is better to encode AS number
as TLV or AS number field can be declared as variable length filed which can
be extracted using length filed of ER-HOP TLV.

Regards,
Katta




From owner-mpls@UU.NET  Mon Jul 30 07:39: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 SMTP id HAA17541
	for ; Mon, 30 Jul 2001 07:39: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 QQkzxe03867;
	Mon, 30 Jul 2001 11:40:03 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxe27131
	for mpls-outgoing; Mon, 30 Jul 2001 11:39: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 QQkzxe27119
	for ; Mon, 30 Jul 2001 11:39: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 QQkzxe16490
	for ; Mon, 30 Jul 2001 11:38:54 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzxe06924
	for ; Mon, 30 Jul 2001 11:38:48 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Jul 2001 17:06:25 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71FF105@mailserver.netbrahma.com>
From: Khuzema Pithewan 
To: "'mpls@uu.net'" 
Subject: multipoint-to-point tunnel
Date: Mon, 30 Jul 2001 17:06:17 +0530
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,

As mplsTunnelIndexNext in mpls-te mib is read-only, so it should be
generated by system (cannot be supplied by administrator). In case if
signaling protocol is RSVP-TE, then at LSR two tunnels might end up in same
SESSION (TunnelId and Egress IPAddress are same for the tunnel generating
from different Ingresses)object. However, we can differentiate these 2
tunnels by extended tunnel ID(Ingress IPAddress), but ext. tunnel id is
optional. 

If this is the case, then multipoint-to-point tunnels cant be established.
for multipoint-to-point tunnels tunnel id should have global significance in
mpls domain?? 



Regards,
Khuzema.



From owner-mpls@UU.NET  Mon Jul 30 08:36: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 IAA19658
	for ; Mon, 30 Jul 2001 08:36: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 QQkzxi21359;
	Mon, 30 Jul 2001 12:36:47 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxi21677
	for mpls-outgoing; Mon, 30 Jul 2001 12:36: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 QQkzxi21632
	for ; Mon, 30 Jul 2001 12:36:05 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 QQkzxi23159
	for ; Mon, 30 Jul 2001 12:35:52 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzxi20038
	for ; Mon, 30 Jul 2001 12:35:49 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Jul 2001 18:03:29 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71FF106@mailserver.netbrahma.com>
From: Khuzema Pithewan 
To: "'mpls@uu.net'" 
Subject: Tunnel Resource Table 
Date: Mon, 30 Jul 2001 18:03:23 +0530
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
  
  How are the mplsTunnelResourceTable parameters mapped to the Tspec Object
parameters used by RSVP-TE?

Regards
Khuzema P


From owner-mpls@UU.NET  Mon Jul 30 08:51: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 IAA20134
	for ; Mon, 30 Jul 2001 08:51: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 QQkzxj14396;
	Mon, 30 Jul 2001 12:52:09 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxj23262
	for mpls-outgoing; Mon, 30 Jul 2001 12:51: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 QQkzxj23254
	for ; Mon, 30 Jul 2001 12:51: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 QQkzxj03336
	for ; Mon, 30 Jul 2001 12:50:40 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzxj10974
	for ; Mon, 30 Jul 2001 12:50:38 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Jul 2001 18:18:19 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D750E62B@mailserver.netbrahma.com>
From: Katta Sambasiva Rao 
To: "'mpls@uu.net'" 
Subject: route pinning - CR-LDP
Date: Mon, 30 Jul 2001 18:18:14 +0530
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 have a doubt in Route pinning of CR-LDP.

Suppose an LSP is pinned to a route. The draft says if there is a new better
route for the established LSP, it should not be considered for pinned LSP.

But if the route becomes completely un-available (say next-hop) failed and
an alternate path which meets LSP requirements exist, what action needs to
be taken. Does the CR-LSP should be teared down as pinning condition cant be
met or the alternate path which meets the requirements should be considered
to set-up LSP from failed point considering the view point that pinning was
for avoiding disruption of services.

problem explained with example: 

A,B,C,D is Explicit route specified, with C as loose hop.
Suppose LSP is set-up with nodes A,B,Z,C,D and pinned.
Now node Z failed, but there is alternate path B,X,C which meets LSP
requirements.
Now what action B should take when it detects it cant reach Z. Should it try
to change LSP path as A,B,X,C,D or tear down the LSP.

If it is implemetation choice, please give your analysis of pros and cons of
each approach.

Thanks in advance.

regards,
Katta


From owner-mpls@UU.NET  Mon Jul 30 08:52:53 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 IAA20157
	for ; Mon, 30 Jul 2001 08:52: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 QQkzxj27159;
	Mon, 30 Jul 2001 12:53:27 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxj23326
	for mpls-outgoing; Mon, 30 Jul 2001 12:52: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 QQkzxj23308
	for ; Mon, 30 Jul 2001 12:52:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzxj18726
	for ; Mon, 30 Jul 2001 12:50:08 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 QQkzxj12353
	for ; Mon, 30 Jul 2001 12:50:07 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA28291 for mpls@uu.net; Mon, 30 Jul 2001 08:50: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 QQkzxj22980
	for ; Mon, 30 Jul 2001 12:49:24 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 QQkzxj07543
	for ; Mon, 30 Jul 2001 12:47:21 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 QQkzxj17132
	for ; Mon, 30 Jul 2001 12:47: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 IAA10564; Mon, 30 Jul 2001 08:47:20 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEW00466;
	Mon, 30 Jul 2001 08:47:12 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010730084242.026ad318@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 30 Jul 2001 08:52:45 -0400
To: Apratim Mukherjee ,
        "'Abhishek Choudhary'" 
From: "Thomas D. Nadeau" 
Subject: RE: mplsTunnelHopTableIndex and mplsTunnelPathInUse
Cc: "'mpls@UU.NET'" 
In-Reply-To: <13D467F625FAD511AE2A00D0B7B917D706BABC@mailserver.netbrahm
 a.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:35 PM 7/30/2001 +0530, Apratim Mukherjee wrote:
>Hi Abhishek,
>
>         > if u look at the mplstunnelHopTable it's triply indexed.
> >mplsTunnelHopTableIndex is the first and mpldTunnelPathInUse is the >second
>index to that table. using these two indexes u get a list of hops >which is
>being used by this tunnel instance.
>
>Ya , you are right . But would not the values of the two indexes be the same
>for any tunnel instance , as Abhay also pointed out . If two indexes have
>the same value , wouldn't that mean a duplication ? Or is that the Hop Table
>could look like this :
>
>HopListLindex  PathOptionIndex HopIndex [ Hop Details ]
>         1                       1              1                ERO1
>         1                       1              2                   ERO1
>         1                       1           3                   ERO1
>         1                       2              4                   ERO2
>         1                       2              5                   ERO2
>         1                       2              6                   ERO2
>         1                       2              7                   ERO2
>
>         where the ERO1's denote the subobjects of the primary ERO
>         and ERO2's denote the subobjects of the secondary ERO ?
>
>         In the normal case then HopListIndex = PathOptionIndex always and
>also HopListIndex is a misleading name as it is the index to TWO hop lists
>and is not an unique identifier of a Hop List .

         If you have the same first two indexes, you
are indicating hops that are part of the SAME
path option. Any of the hops denoted by the third
index in this case are all considered to be part
of the same path option. What might be confusing is that
the description clause in the mplsTunnelHopTable has
not been updated to reflect the tertiary indexing.
We will update this as part of the IESG review of
the document.

         Incidentally, the purpose of having the indexes the
way that we do is to allow one to configure a tunnel
instance to have multiple paths (i.e.: what you were
referring to as path options before). For example, the
following demonstrates how one would configure two
paths for a particular tunnel:

         (mplsTunnelHopListIndex,
         mplsTunnelHopPathOptionIndex,
          mplsTunnelHopIndex ):          hop address

         -- first path option
         (1,1,1):        1.2.3.1
         (1,1,2):        2.3.4.1
         (1,1,3):        4.5.6.1

         -- second path option
         (1,2,1):        1.2.4.1
         (1,2,2):        5.6.5.1
         (1,2,3):        7.8.1.1

         ...


         --Tom




>         Thanks
>         Apratim
>
> > -----Original Message-----
> > From: Apratim Mukherjee [ mailto:ApratimM@netbrahma.com]
> > Sent: Saturday, July 28, 2001 7:02 PM
> > To: mpls@UU.NET
> > Subject: mplsTunnelHopTableIndex and mplsTunnelPathInUse
> >
> >
> > Hi,
> >
> > Could someone explain as to what is the difference between the
> > mplsTunnelHopTableIndex and mplsTunnelPathInUse objects in the
> > mplsTunnelTable . Dont they both point to an Explicit Route for the tunnel
> > ?
> >
> > Thanks,
> > Apratim
> >
> >



From owner-mpls@UU.NET  Mon Jul 30 09:10: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 JAA20586
	for ; Mon, 30 Jul 2001 09:10: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 QQkzxk08348;
	Mon, 30 Jul 2001 13:11:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxk14199
	for mpls-outgoing; Mon, 30 Jul 2001 13:11: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 QQkzxk14163
	for ; Mon, 30 Jul 2001 13:10: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 QQkzxk06802
	for ; Mon, 30 Jul 2001 13:10:25 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzxk23240
	for ; Mon, 30 Jul 2001 13:10:25 GMT
Message-ID: <3B655CBF.4B47D2EF@sandburst.com>
Date: Mon, 30 Jul 2001 09:10:23 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Katta Sambasiva Rao 
Cc: "'mpls@uu.net'" 
Subject: Re: CR-LDP - AS fld. len. limitation
References: <13D467F625FAD511AE2A00D0B7B917D750E62A@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Katta,

    I am certain that - when a new size for AS numbers is defined - then
a number of protocols will need to be looked at to see if there is a need to
extend them to support this new size.  As it is, most newer protocols are
defined in such a way that it is not too hard to extned them for just such
an occasion.  CR-LDP and RSVP-TE are both extensible in this way.

    Hence, no particular change is immediately required for either of these
MPLS explicit route signaling protocols.

--
Eric Gray

You wrote:

> Hi,
> In CR-LDP draft, it is assumed that Autonomous System (AS) number length as
> 2 bytes. (Section: 4.7.3)
>
> But work is underway in IETF, for supporting 4 octet AS number.
> There is a draft in progress by IDR work group which is talking about
> extending BGP to support 4 octet AS number.
>
> I am not sure whether the 4 octet AS number support is a BGP required
> feature or it is a general requirement for Internet.
>
> If 4 octet AS number support is necessary , it is better to encode AS number
> as TLV or AS number field can be declared as variable length filed which can
> be extracted using length filed of ER-HOP TLV.
>
> Regards,
> Katta



From owner-mpls@UU.NET  Mon Jul 30 09:34: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 JAA21527
	for ; Mon, 30 Jul 2001 09:34: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 QQkzxm06854;
	Mon, 30 Jul 2001 13:35:00 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxm16269
	for mpls-outgoing; Mon, 30 Jul 2001 13:34: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 QQkzxm16264
	for ; Mon, 30 Jul 2001 13:34: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 QQkzxm05759
	for ; Mon, 30 Jul 2001 13:34:02 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 QQkzxm29465
	for ; Mon, 30 Jul 2001 13:34:02 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA01924 for mpls@uu.net; Mon, 30 Jul 2001 09:34:01 -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 QQkzxm16173
	for ; Mon, 30 Jul 2001 13:33:17 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 QQkzxm14074
	for ; Mon, 30 Jul 2001 13:33:11 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 QQkzxm28908
	for ; Mon, 30 Jul 2001 13:33:10 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 JAA14571; Mon, 30 Jul 2001 09:33:10 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEY00156;
	Mon, 30 Jul 2001 09:33:06 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010730093710.026bc0d0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 30 Jul 2001 09:38:41 -0400
To: Apratim Mukherjee , "'mpls@UU.NET'" 
From: "Thomas D. Nadeau" 
Subject: RE: Doubts about MPLS-TE Mib
In-Reply-To: <13D467F625FAD511AE2A00D0B7B917D706BAB9@mailserver.netbrahm
 a.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:41 PM 7/26/2001 +0530, Apratim Mukherjee wrote:
> > Hi ,
> >
> > Thanks for the clarifications . But a few doubts persist ...
> > >2. the object mplsTunnelIngressId is defined to be used as the
> > >ExtendedTunnelId .
> >
> >          Yes.
> >
> > >But then where will the SenderTemplate object's
> > >Sender IP address come from ?
> >
> >          EgressTunnelId.
>First , do you mean EgressLSRId by this ... but this could only be
>IngressLSRId if anything .
>
>But , this is also being used as extended tunnel id , in which case it COULD
>be 0 ... then isn't there an indexing problem ?

         Why? 0 is a perfectly valid index.

>I realise that this question has been asked before but i could not find any
>satisfactory conclusion to a thread that speaks about this .
>One of the promising threads ends on this note from David Charlap ( from the
>archives : http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
> >Then there is potential for conflict between the TE MIB and RSVP-TE
> >itself. ...........
> >I can only assume that the TE MIB was based upon the features of >RSVP-TE
>that are commonly in use, and can not fully accomodate all of >its features.
>If someone build a router that supports multipoint-to-point >LSPs using
>RSVP-TE, the TE MIB will have to be updated, or that >implementation will be
>unable to properly represent these kinds of LSPs >using it.
>
>Is this then an unresolved problem ?

         I don't think that this is still a problem. The current indexing
comes right from the RSVP/CR-LDP specifications, so if there is
a problem, those protocols will be broken too.

         --Tom




From owner-mpls@UU.NET  Mon Jul 30 09:53: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 JAA22138
	for ; Mon, 30 Jul 2001 09:53: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 QQkzxn00450;
	Mon, 30 Jul 2001 13:53:14 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxn18269
	for mpls-outgoing; Mon, 30 Jul 2001 13:52: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 QQkzxn18156
	for ; Mon, 30 Jul 2001 13:52:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzxn14393
	for ; Mon, 30 Jul 2001 13:51:29 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQkzxn24552
	for ; Mon, 30 Jul 2001 13:51:23 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Jul 2001 19:19:00 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BABD@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'Thomas D. Nadeau'" 
Cc: "'mpls@UU.NET'" 
Subject: RE: Doubts about MPLS-TE Mib
Date: Mon, 30 Jul 2001 19:18:50 +0530
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 Tom ,

Thanks for the clarification .
	>>But , this is also being used as extended tunnel id , in which
case it COULD
	>>be 0 ... then isn't there an indexing problem ?
	>        Why? 0 is a perfectly valid index.
What i meant here is that if extended tunnel id is 0 , then IngressLSRId is
0 (If Extended Tunnel Id is ALWAYS same as IngressLSRId). If IngressLSRId is
0 , then Sender Template ip address is 0.0.0.0  , if this is same as Ingress
LSR Id  . This is wrong since information about the sender Ip address is
absolutely essential . I  think there shoud be a separate field for Extended
Tunnel Id as this has no necessary relation with IngressLSRId . ( They only
MIGHT be same ) . 

Hope this is more clear
Thanks
Apratim

	----------
	From: 	Thomas D. Nadeau[SMTP:tnadeau@cisco.com]
	Sent: 	Monday, July 30, 2001 7:08 PM
	To: 	Apratim Mukherjee; 'mpls@UU.NET'
	Subject: 	RE: Doubts about MPLS-TE Mib

	At 07:41 PM 7/26/2001 +0530, Apratim Mukherjee wrote:
	> > Hi ,
	> >
	> > Thanks for the clarifications . But a few doubts persist ...
	> > >2. the object mplsTunnelIngressId is defined to be used as the
	> > >ExtendedTunnelId .
	> >
	> >          Yes.
	> >
	> > >But then where will the SenderTemplate object's
	> > >Sender IP address come from ?
	> >
	> >          EgressTunnelId.
	>First , do you mean EgressLSRId by this ... but this could only be
	>IngressLSRId if anything .
	>
	>But , this is also being used as extended tunnel id , in which case
it COULD
	>be 0 ... then isn't there an indexing problem ?

	         Why? 0 is a perfectly valid index.

	>I realise that this question has been asked before but i could not
find any
	>satisfactory conclusion to a thread that speaks about this .
	>One of the promising threads ends on this note from David Charlap (
from the
	>archives :
http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
	> >Then there is potential for conflict between the TE MIB and
RSVP-TE
	> >itself. ...........
	> >I can only assume that the TE MIB was based upon the features of
>RSVP-TE
	>that are commonly in use, and can not fully accomodate all of >its
features.
	>If someone build a router that supports multipoint-to-point >LSPs
using
	>RSVP-TE, the TE MIB will have to be updated, or that
>implementation will be
	>unable to properly represent these kinds of LSPs >using it.
	>
	>Is this then an unresolved problem ?

	         I don't think that this is still a problem. The current
indexing
	comes right from the RSVP/CR-LDP specifications, so if there is
	a problem, those protocols will be broken too.

	         --Tom




From owner-mpls@UU.NET  Mon Jul 30 10:20: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 KAA23643
	for ; Mon, 30 Jul 2001 10:20: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 QQkzxp13985;
	Mon, 30 Jul 2001 14:20:25 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxp11623
	for mpls-outgoing; Mon, 30 Jul 2001 14:20: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 QQkzxp11558
	for ; Mon, 30 Jul 2001 14:19:53 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 QQkzxp28758
	for ; Mon, 30 Jul 2001 14:18:07 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 QQkzxp28492
	for ; Mon, 30 Jul 2001 14:18:06 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA05585 for mpls@uu.net; Mon, 30 Jul 2001 10:18:06 -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 QQkzxp11473
	for ; Mon, 30 Jul 2001 14:17:26 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 QQkzxo24008
	for ; Mon, 30 Jul 2001 14:12:54 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 QQkzxo18476
	for ; Mon, 30 Jul 2001 14:12:54 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 KAA19373; Mon, 30 Jul 2001 10:12:53 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEY00702;
	Mon, 30 Jul 2001 10:12:50 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 30 Jul 2001 10:18:25 -0400
To: Apratim Mukherjee 
From: "Thomas D. Nadeau" 
Subject: RE: Doubts about MPLS-TE Mib
Cc: "'mpls@UU.NET'" 
In-Reply-To: <13D467F625FAD511AE2A00D0B7B917D706BABD@mailserver.netbrahm
 a.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:18 PM 7/30/2001 +0530, Apratim Mukherjee wrote:
>Hi Tom ,
>
>Thanks for the clarification .
>         >>But , this is also being used as extended tunnel id , in which
>case it COULD
>         >>be 0 ... then isn't there an indexing problem ?
>         >        Why? 0 is a perfectly valid index.
>What i meant here is that if extended tunnel id is 0 , then IngressLSRId is
>0 (If Extended Tunnel Id is ALWAYS same as IngressLSRId). If IngressLSRId is
>0 , then Sender Template ip address is 0.0.0.0  , if this is same as Ingress
>LSR Id  . This is wrong since information about the sender Ip address is
>absolutely essential . I  think there shoud be a separate field for Extended
>Tunnel Id as this has no necessary relation with IngressLSRId . ( They only
>MIGHT be same ) .

         This is an artifact of how the protocol works,
and the MIB models the protocols. I personally think
that the protocol should have made the Ingress
LSR Id mandatory for the reason you stated, but it
didn't. Fortunately, all of the implementations I know
of to insert the loopback address in this field, so
operationally there should not be any problem
(and have not been from what I have heard/seen).

         --Tom



>Hope this is more clear
>Thanks
>Apratim
>
>         ----------
>         From:   Thomas D. Nadeau[SMTP:tnadeau@cisco.com]
>         Sent:   Monday, July 30, 2001 7:08 PM
>         To:     Apratim Mukherjee; 'mpls@UU.NET'
>         Subject:        RE: Doubts about MPLS-TE Mib
>
>         At 07:41 PM 7/26/2001 +0530, Apratim Mukherjee wrote:
>         > > Hi ,
>         > >
>         > > Thanks for the clarifications . But a few doubts persist ...
>         > > >2. the object mplsTunnelIngressId is defined to be used as the
>         > > >ExtendedTunnelId .
>         > >
>         > >          Yes.
>         > >
>         > > >But then where will the SenderTemplate object's
>         > > >Sender IP address come from ?
>         > >
>         > >          EgressTunnelId.
>         >First , do you mean EgressLSRId by this ... but this could only be
>         >IngressLSRId if anything .
>         >
>         >But , this is also being used as extended tunnel id , in which case
>it COULD
>         >be 0 ... then isn't there an indexing problem ?
>
>                  Why? 0 is a perfectly valid index.
>
>         >I realise that this question has been asked before but i could not
>find any
>         >satisfactory conclusion to a thread that speaks about this .
>         >One of the promising threads ends on this note from David Charlap (
>from the
>         >archives :
>http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
>         > >Then there is potential for conflict between the TE MIB and
>RSVP-TE
>         > >itself. ...........
>         > >I can only assume that the TE MIB was based upon the features of
> >RSVP-TE
>         >that are commonly in use, and can not fully accomodate all of >its
>features.
>         >If someone build a router that supports multipoint-to-point >LSPs
>using
>         >RSVP-TE, the TE MIB will have to be updated, or that
> >implementation will be
>         >unable to properly represent these kinds of LSPs >using it.
>         >
>         >Is this then an unresolved problem ?
>
>                  I don't think that this is still a problem. The current
>indexing
>         comes right from the RSVP/CR-LDP specifications, so if there is
>         a problem, those protocols will be broken too.
>
>                  --Tom



From owner-mpls@UU.NET  Mon Jul 30 10: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 SMTP id KAA24234
	for ; Mon, 30 Jul 2001 10: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 QQkzxq08528;
	Mon, 30 Jul 2001 14:31:13 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxq12680
	for mpls-outgoing; Mon, 30 Jul 2001 14:30:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzxq12661
	for ; Mon, 30 Jul 2001 14:30:19 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzxp25711
	for ; Mon, 30 Jul 2001 14:28:54 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzxp12935
	for ; Mon, 30 Jul 2001 14:28:54 GMT
Message-ID: <3B656F24.B0B5BA4E@sandburst.com>
Date: Mon, 30 Jul 2001 10:28:52 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Katta Sambasiva Rao 
Cc: "'mpls@uu.net'" 
Subject: Re: route pinning - CR-LDP
References: <13D467F625FAD511AE2A00D0B7B917D750E62B@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Katta,

    It is something of an implementation choice, however, opinions on a
'correct' model can be both variant and enthusiastic.  Therefore, it will
make sense to support either approach, optionally, in implementations.

    If you pre-suppose that B has established the alternate path (B-X-C)
in advance, then it must be clear that B assumes a correct behavior that
involves switching to the alternative path.  If you assume otherwise, then
there must be some time-bound criteria on which an operator would like
to see some modification in switching behavior that minimizes lost traffic
and wasted networking resources associated with forwarding packets to
B so that they can be discarded as a result of no extant forwarding path
downstream from B.

    I believe these are the rough parameters defining the domain in which
the two approaches are an implementation choice.

--
Eric Gray

You wrote:

> Hi,
> I have a doubt in Route pinning of CR-LDP.
>
> Suppose an LSP is pinned to a route. The draft says if there is a new better
> route for the established LSP, it should not be considered for pinned LSP.
>
> But if the route becomes completely un-available (say next-hop) failed and
> an alternate path which meets LSP requirements exist, what action needs to
> be taken. Does the CR-LSP should be teared down as pinning condition cant be
> met or the alternate path which meets the requirements should be considered
> to set-up LSP from failed point considering the view point that pinning was
> for avoiding disruption of services.
>
> problem explained with example:
>
> A,B,C,D is Explicit route specified, with C as loose hop.
> Suppose LSP is set-up with nodes A,B,Z,C,D and pinned.
> Now node Z failed, but there is alternate path B,X,C which meets LSP
> requirements.
> Now what action B should take when it detects it cant reach Z. Should it try
> to change LSP path as A,B,X,C,D or tear down the LSP.
>
> If it is implemetation choice, please give your analysis of pros and cons of
> each approach.
>
> Thanks in advance.
>
> regards,
> Katta



From owner-mpls@UU.NET  Mon Jul 30 11:36: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 SMTP id LAA29067
	for ; Mon, 30 Jul 2001 11:36: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 QQkzxu18109;
	Mon, 30 Jul 2001 15:35:39 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxu09273
	for mpls-outgoing; Mon, 30 Jul 2001 15:35:07 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 QQkzxu09251
	for ; Mon, 30 Jul 2001 15:34:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzxu00195
	for ; Mon, 30 Jul 2001 15:30:31 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 QQkzxu06516
	for ; Mon, 30 Jul 2001 15:30:30 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA11087 for mpls@uu.net; Mon, 30 Jul 2001 11:30:30 -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 QQkzxt08795
	for ; Mon, 30 Jul 2001 15:29:28 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 QQkzxt27360
	for ; Mon, 30 Jul 2001 15:28:53 GMT
Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQkzxt03782
	for ; Mon, 30 Jul 2001 15:28:52 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 f6UFT1310353;
	Mon, 30 Jul 2001 08:29:01 -0700 (PDT)
Received: from cisco.com (ch2-dhcp143-63.cisco.com [161.44.143.63])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ADW01333 (AUTH rraszuk);
	Mon, 30 Jul 2001 08:28:50 -0700 (PDT)
Message-ID: <3B657CB5.10A4268E@cisco.com>
Date: Mon, 30 Jul 2001 08:26:45 -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: Raymond Law 
CC: mpls@UU.NET
Subject: Re: LSP utilization
References: <4.3.0.20010729224019.05780b40@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Raymond,

> bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> the delay to do so) involved in this solution worth what it provides
> (better LSP utilization)?

The order is not exactly as you wrote. The old LSP is not being
destroyed first, but rather a new LSP is being attempted to be created
using shared explicit rsvp reservation style. If the new reservation
fails the old tunnel continue to be active if it succeed we build a new
tunnel (no double bandwith reservation) we switch traffic to a new
tunnel. After this old is no longer refreshed. 

It is automatic with ability to adjust the interface stats collection
timers as well as the resize interval. 

R.

> Raymond Law wrote:
> 
> I agree the problem that I posed may not be MPLS specific; it applies to
> ATM circuits as well.  I think this may be more of a TE problem than a MPLS
> problem.
> 
> Basically I heard two solutions from the list.  The first solution is to
> assign a new LSP with the adjusted (measured from the first initial LSP)
> bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> the delay to do so) involved in this solution worth what it provides
> (better LSP utilization)?
> 
> The second solution is to do load balancing when setting up LSPs.  I agree
> that load balancing can definitely lead to better utilization of the
> LSPs.  However, I am more interested in the situation where, after load
> balancing and setting up LSPs for the FECs, the amount of traffic sent
> through the LSPs change, resulting in over- and under-utilization of some LSPs.
> 
> Ray,



From owner-mpls@UU.NET  Mon Jul 30 12:00: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 SMTP id MAA01112
	for ; Mon, 30 Jul 2001 12:00:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzxw23503;
	Mon, 30 Jul 2001 16:00:09 GMT
Received: by mail-control.mail.uu.net 
	id QQkzxv11594
	for mpls-outgoing; Mon, 30 Jul 2001 15:59:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzxv11584
	for ; Mon, 30 Jul 2001 15:59: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 QQkzxv28307
	for ; Mon, 30 Jul 2001 15:58:52 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 QQkzxv21088
	for ; Mon, 30 Jul 2001 15:58:37 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA13634 for mpls@uu.net; Mon, 30 Jul 2001 11:58:36 -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 QQkzxv11236
	for ; Mon, 30 Jul 2001 15:54: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 QQkzxv08022
	for ; Mon, 30 Jul 2001 15:53:50 GMT
Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQkzxv07667
	for ; Mon, 30 Jul 2001 15:53:50 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f6UFrQG10923;
	Mon, 30 Jul 2001 18:53:26 +0300
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15205.33526.568945.221020@lohi.eng.telia.fi>
Date: Mon, 30 Jul 2001 18:53:26 +0300 (EEST)
To: "Jay Wang" 
Cc: "HANSEN CHAN" , "Fred Baker" ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , 
Subject: RE: QoS in Shared Media
In-Reply-To: 
References: <15091.38161.514887.486740@lohi.eng.telia.fi>
	
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

jay,

i'm reading old emails and found your dpr/rpr/diffserv comment below to
which i have not had time to reply.  unfortunately i have to disagree
with you regarding dpt/rpr supporting diffserv.  the problem is their
node based fairness concept.

lets say that i have a 100 mbps rpr ring of four nodes a-b-c-d-a, there
may be 25 mbps of yellow and red af1 packets from both a to d and b to d
plus 70 mbps of green af1 packets from c to a.  in c, yellow and red
packets from a and b to d should not get 1/2 (50 mbps) of the bandwidth
causing 20 mbps of green af1 packets originating from c to be dropped.

-- juha
------------------------------------------------
Jay Wang writes:
 > 
 > Dunno what is the problem. To support diffserv, the underneath
 > transport (MAC layer and lower), does not have to have a
 > sophisticated traffic management matching diffserv PHBs. The fact
 > that cisco's DPT (or others RPR version for that matter), a MAC
 > layer technology, that supports only two transmit queueing priorities,
 > hence is not a disqualifier for supporting diffserv on the higher level,
 > where you suggested otherwise. In a share-media environment, from
 > diffserv's perspective, what we need from below is a link layer
 > that may ensure a quantifiable and stable guaranteed throughput for the
 > target nodes, regardless of the other sharing nodes. This is what is
 > missing in the original IEEE-802-style LAN. The DPT, on the other hand,
 > assures total_ring-BandWidth/node_num for each node. Given that, the
 > business of diffserv traffic management, e.g., BA classification,
 > policing, color-based RED dropping, PHB scheduling, and so on and so forth,
 > can be conducted as they should have been at the connected nodes.
 > 
 > - jay
 > 
 > 
 > -----Original Message-----
 > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
 > Sent: Friday, May 04, 2001 10:52 PM
 > To: Jay Wang
 > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
 > te-wg@ops.ietf.org
 > Subject: RE: QoS in Shared Media
 > 
 > 
 > Jay Wang writes:
 > 
 >  > Well, RPR gives you bandwidth endurance at the link level, a shared
 >  > media in this case. On higher level, you may conduct your QoS as
 >  > appropriate, Diffserv, Intserv, or else. One does not preclude the other,
 >  > IMO.
 > 
 > how about if someone would like to give different bandwidth assurance to
 > more than one independent traffic class?  also, within a diffserv
 > traffic class, droping of packets is based on the drop presedence of the
 > packet, not based on behind which nodes the packets arrived.
 > 
 > as i said before, node based fairness can only be applied to the highest
 > dp packets within each class.  dpt (and also rpr if it adopts dpt) thus
 > supports diffserv only in a very limited sense.  as far as i remember,
 > it is the only ieee mac standard, where the specification tells how many
 > queues the switch has.
 > 
 > -- juha
 > 
 > 
 > -----Original Message-----
 > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha
 > Heinanen
 > Sent: Friday, May 04, 2001 12:01 PM
 > To: HANSEN CHAN
 > Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 'te-wg@ops.ietf.org'
 > Subject: Re: QoS in Shared Media
 > 
 > HANSEN CHAN writes:
 > 
 >  > How about the work in IEEE 802.17 RPR? I believe it will be a
 > shared-media
 >  > technology. Does that mean they will have a hard time to achieve QoS
 >  > guarantees?
 > 
 > last time that i checked, the rpr proposal (based on cisco dpt) had two
 > classes of service (strict priority and best effort). that is clearly
 > not adequate for diffserv.  node based fairness applied to the best
 > effort class.  in diffserv, node based fairness makes sense only for the
 > highest dp packets in each traffic class.
 > 
 > -- juha
 > 



From owner-mpls@UU.NET  Mon Jul 30 13:28: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 NAA08967
	for ; Mon, 30 Jul 2001 13:28: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 QQkzyb28085;
	Mon, 30 Jul 2001 17:28:54 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyb27246
	for mpls-outgoing; Mon, 30 Jul 2001 17:28:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzyb27241
	for ; Mon, 30 Jul 2001 17:28:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzyb05216
	for ; Mon, 30 Jul 2001 17:27:13 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 QQkzyb20029
	for ; Mon, 30 Jul 2001 17:26:58 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA20598 for mpls@uu.net; Mon, 30 Jul 2001 13:26: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 QQkzyb27169
	for ; Mon, 30 Jul 2001 17:26:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzyb24432
	for ; Mon, 30 Jul 2001 17:25:31 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 QQkzyb18024
	for ; Mon, 30 Jul 2001 17:25:30 GMT
Received: from FRED-W2K2.cisco.com ([171.71.21.236])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6UHPAg17182;
	Mon, 30 Jul 2001 10:25:10 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 30 Jul 2001 10:25:06 +0100
To: Juha Heinanen 
From: Fred Baker 
Subject: RE: QoS in Shared Media
Cc: "Jay Wang" ,
        "HANSEN CHAN" ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , 
In-Reply-To: <15205.33526.568945.221020@lohi.eng.telia.fi>
References: 
 <15091.38161.514887.486740@lohi.eng.telia.fi>
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 04:53 PM 7/30/2001, Juha Heinanen wrote:
>i'm reading old emails and found your dpr/rpr/diffserv comment below to
>which i have not had time to reply.  unfortunately i have to disagree
>with you regarding dpt/rpr supporting diffserv.  the problem is their
>node based fairness concept.

Juha: you and I have discussed this in private mail, and I at least 
partially disagree. Let me lay out the argument, and the assembled masses 
can comment.

It comes down to this: I will grant you that providing something as simple 
as two levels of priority does not provide all of the facilities of the 
diffserv architecture - you cannot control the rate of each data stream in 
the system if you are not given the knobs. This is not so very different 
from Ethernet, which even with 802.1q labelling doesn't give you rate 
controls on traffic streams within the switched part of the network.

However, apart from failure events, the SRP architecture provides a 
nominal-latency and loss-free domain, and allows for access control on 
injection of traffic into that domain. Thus, injection of traffic to the 
ring from any one system does not exceed the rates configured on those 
systems, and there is technology to manage babblers. I will argue that this 
is not significantly different from typical ISP backbones, which rely on 
bandwidth on their internal interfaces and provide QoS services only on 
their ingress/egress links if at all.

Are you telling me that in order to be diffserv compliant, not only must a 
network provide the technology at it's service interfaces, but also on each 
and every internal interface? If so, I don't predict early adoption...

Or are you telling me that to be compliant with the diffserv architecture, 
the device must specifically support the AF PHB on every interface? I don't 
find anything in the diffserv architectural documents that makes this 
stipulation. And even in the AF PHB (http://www.ietf.org/rfc/rfc2597.txt), 
while I see a stipulation that interfaces which might lose data are to drop 
randomly and prefer to drop from traffic marked "excess", I don't see any 
requirement that all interfaces drop.

I believe that you are essentially, in the final paragraph of your reply, 
asking that all switching be done at the IP layer, and that link layer 
networks of any sort be abandoned. I understand the viewpoint, but have to 
say that it is not completely practical; LAN technologies exist because 
they are inexpensive, useful, and widely used, and I don't know of *any* 
that support the diffserv architecture in the sense that you seem to want.

Following is the email I sent you on 5/10/2001, and your reply. For the 
remainder of the folks on the list, please excuse a few discussions of 
specific implementations which came up in this private conversation.

>To: Juha Heinanen 
>From: Fred Baker 
>Subject: [Fwd: QoS in Shared Media]
>Cc: Mike Takefman 
>
>At 10:19 AM 5/9/2001, Juha Heinanen wrote:
>>the idea behind diffserv is that each traffic is allocated a certain
>>amount of aggregate resources (buffer space and bandwidth) at each
>>diffserv (l2 or l3) node.
>
>Mike Takefman, who manages the SRP hardware group, contacted me to be sure 
>he understood your issues and to see if we could sort them out. I think we 
>in fact have the support you need, but some of it is in the interface card 
>as opposed to being in the "Wide Area LAN" itslf. Let me walk through your 
>issues, the architecture they have proposed, and how I see this all 
>working, and then you can tell me where the disconnect is.
>
>If I think about ensuring a combination of voice/video a predictable 
>latency through EF and a set of AF classes for elastic traffic at various 
>rates, I wind up implementing a multi-level scheduler like so:
>
>         voice/video =====>||==================>priority scheduler
>                                             =>
>         AF class 1  =====>||====>\         /
>         AF class 2  =====>||====> \WRR/WFQ/
>         AF class 3  =====>||====> /Scheduler
>         AF class 4  =====>||====>/
>
>In short, I want to assure the voice/video traffic that it will not be 
>delayed by the elastic traffic, but will instead get predictable latency 
>at the interface, and I control rate using policing. For the elastic 
>traffic streams, I want to ensure each one a specific minimum rate, and 
>ensure that when arrival rate for a class exceeds departure rate, I signal 
>to a TCP or similar transport which can materially adjust its rate to 
>compensate using RED or WRED.
>
>What SRP provides is a collection of point to point duplex lines with 
>internal queuing which together comprise a ring. Each interface sees:
>
>                                            +-----+
>      high priority transit traffic in ->||-|     |
>      local high priority in ----------->||-|     |
>                                            |     |--->traffic out
>      low priority transit traffic in -->||-|     |
>      local low priority in ------------>||-|     |
>                                            +-----+
>
>Clearly, the other end of "traffic out" is "traffic in" at the next node, 
>which classifies traffic according to a three bit field copied from the IP 
>Precedence as high or low priority.
>
>The decision function favors high priority over low priority to ensure 
>minimal per-hop additional latency and jitter. The choice between local 
>and transit traffic is a bit more complicated. Each node on the ring is 
>guaranteed a certain lower bound bandwidth (at the moment, 1/N of the 
>ring, but Mike tells me that they are considering making this 
>specifiable), and if it is not using its fair share the decision function 
>will take local low priority traffic over low priority transit traffic, 
>and will take local high priority traffic over high priority transit 
>traffic. If the transit queues are too deep, however, it will take transit 
>traffic to clear the buffer. In the latter case, a longer term rule steps 
>in - the nodes communicate among themselves, and a system which fails to 
>get its share during one period of ten milliseconds will ask its neighbors 
>to back off for the next ten milliseconds. Hence, in any case, the low 
>priority has a predictable lower bound at each node.
>
>The systems which implement SRP also have extra chips which implement some 
>number of classes that use a WFQ/WRR type of scheduler, WRED, metering 
>with policing or marking, etc. The chip also allows a single queue to be 
>given absolute priority, which is appropriate for voice/video. These work 
>with any interface device, whether SRP, ATM, HSSI, POS, or whatever, which 
>is why the SRP guys don't think about them too much. Fundamentally, in 
>SRP's case, they divide the low priority capacity proportionally among a 
>set of traffic classes.
>
>I think you will agree that SRP with the external priority queue limits 
>edge to edge jitter and latency around the ring for the EF traffic. I want 
>to convince you that each AF class also gets a predictable lower bound 
>rate, and that RED drops apply when incoming traffic overruns available 
>capacity.
>
>I submit that if each node in the ring gets a predictable lower bound, and 
>subdivides that among its several AF classes proportionally, then each of 
>those sub-classes also has a predictable lower bound. This is for traffic 
>entering the ring from each node; how it leaves the ring depends on the 
>traffic itself, and in the worst case stays on the ring all the way 
>around. Thus, the proportions on the ring itself may vary, but that is not 
>necessarily an SLA objective - the SLA objective is to give each edge 
>device its due, and that is done.
>
>In discussing this with the SRP team, I proposed a scenario in which I 
>wondered if traffic from one node could be reduced or locked out by the 
>preponderance of traffic from other nodes. That's where the "I'm not 
>getting my share" message comes in; even in that case, the other nodes 
>slowing down should result in the restricted node getting its bandwidth 
>needs met, by forcing competing traffic to back up into the WRR/WFQ queues 
>on the competing nodes. Any place that traffic backs up into a WRR/WFQ 
>queue, RED/WRED can be applied to talk with those TCP senders, so RED 
>happens and it happens to the right set of senders.
>
>It seems to me that we have all the bases covered. They are not covered 
>within the SRP component on the interface card, but they are covered in 
>the queuing components that sit in front of the SRP interface on the line 
>card. In other words, the following happens on the line card:
>
>         voice/video =====>||==================>priority scheduler
>                                             =>
>         AF class 1  =====>||====>\         /
>         AF class 2  =====>||====> \WRR/WFQ/
>         AF class 3  =====>||====> /Scheduler
>         AF class 4  =====>||====>/
>
>and on the SRP ring, a simple priority scheduler preserves the 
>latency/jitter characteristics needed by EF, and each elastic traffic 
>class (from each node and from the aggregate of the nodes) is guaranteed a 
>predictable lower rate bound.
>
>Am I missing something?

>From: Juha Heinanen 
>To: Fred Baker 
>Cc: Mike Takefman , jh@rautu.eng.telia.fi
>Subject: [Fwd: QoS in Shared Media]
>Date: Thu, 10 May 2001 15:46:30 +0300
>
>fred,
>
>thanks for your thorough explanation.  my comments follow.
>
>queuing at two levels (layer 3 and 2) is always problematic.  we have
>learned this from atm, where l3 diffserv queueing and scheduling is
>messed up when the properly scheduled packets enter the atm layer's per
>vc queues. i'm afraid that a similar problems exist with rpr if rpr
>doesn't do same kind of queueing/scheduling using the user priority
>field as is done at l3 using the precedence field.
>
>based on your description i understand that in rpr the low priority
>capacity is allocated fairly to each node, i.e., each node has a lower
>bound on the amount of low priority traffic and can then distribute it
>to the elastic traffic classes according to its policy.  this doesn't,
>however, mean that a given traffic class would IN THE RING ITSELF get a
>given proportion of bandwidth, because one node could, for example, send
>only best effort packets and they would get as much ring bandwidth as
>business class packets from another node.
>
>in other words, it seems to me that diffserv and node based fairness and
>separation of local and transit traffic simply do not match. if we
>forget node based fairness and local/transit traffic it could be
>possible to end up with a proper diffserv implementation where l2
>packets entering the ring (first time or transit) would be all
>queued/scheduled/dropped by the rpr interface based solely on the
>traffic class and drop precedence coded in the user priority field.
>additional complications may result from the ring wraps, but i don't
>remember the details.
>
>-- juha



From owner-mpls@UU.NET  Mon Jul 30 13:39: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 SMTP id NAA09888
	for ; Mon, 30 Jul 2001 13:39: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 QQkzyc07496;
	Mon, 30 Jul 2001 17:39:26 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyc27873
	for mpls-outgoing; Mon, 30 Jul 2001 17:38: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 QQkzyc27863
	for ; Mon, 30 Jul 2001 17:38: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 QQkzyc01934
	for ; Mon, 30 Jul 2001 17:36:39 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 QQkzyc03472
	for ; Mon, 30 Jul 2001 17:36:38 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA21450 for mpls@uu.net; Mon, 30 Jul 2001 13:36:38 -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 QQkzyc27764
	for ; Mon, 30 Jul 2001 17:36: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 QQkzyc18314
	for ; Mon, 30 Jul 2001 17:33:24 GMT
Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQkzyc11790
	for ; Mon, 30 Jul 2001 17:33:24 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f6UHX9m11185;
	Mon, 30 Jul 2001 20:33:09 +0300
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15205.39508.911082.655894@lohi.eng.telia.fi>
Date: Mon, 30 Jul 2001 20:33:08 +0300 (EEST)
To: Fred Baker 
Cc: "Jay Wang" ,
        "HANSEN CHAN" ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , 
Subject: RE: QoS in Shared Media
In-Reply-To: <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
References: 
	<15091.38161.514887.486740@lohi.eng.telia.fi>
	<5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

fred,

i have no problems whatsoever with diffserv support in regular 801.1q
ethernet switches that allow me to map the user priority field to wfq
queues.  rpr doesn't offer this capability. 

phb stands for "per HOP behavior".  of course it is possible to support
diffserv only at the edge, but that doesn't lead to the most efficient
use of the bandwidth.  it is the same as using cbr vc to connect routers
together over atm backbone.

-- juha



From owner-mpls@UU.NET  Mon Jul 30 13:59: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 NAA11233
	for ; Mon, 30 Jul 2001 13:59: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 QQkzyd16566;
	Mon, 30 Jul 2001 17:59:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyd29464
	for mpls-outgoing; Mon, 30 Jul 2001 17:59:15 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 QQkzyd29448
	for ; Mon, 30 Jul 2001 17:58: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 QQkzyd10233
	for ; Mon, 30 Jul 2001 17:57:27 GMT
Received: from ns1.arch.bellsouth.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2])
	id QQkzyd23322
	for ; Mon, 30 Jul 2001 17:57:22 GMT
Received: (from ck@localhost)
	by ns1.arch.bellsouth.net (goaway/goaway) id f6UHtlN29390;
	Mon, 30 Jul 2001 13:55:47 -0400 (EDT)
Date: Mon, 30 Jul 2001 13:55:47 -0400
From: Christian Kuhtz 
To: Juha Heinanen 
Cc: Fred Baker , Jay Wang ,
        HANSEN CHAN ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , te-wg@ops.ietf.org
Subject: Re: QoS in Shared Media
Message-ID: <20010730135547.Q27172@ns1.arch.bellsouth.net>
References:  <15091.38161.514887.486740@lohi.eng.telia.fi> <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com> <15205.39508.911082.655894@lohi.eng.telia.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <15205.39508.911082.655894@lohi.eng.telia.fi>; from Juha Heinanen on Mon, Jul 30, 2001 at 08:33:08PM +0300
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Jul 30, 2001 at 08:33:08PM +0300, Juha Heinanen wrote:
> fred,
> 
> i have no problems whatsoever with diffserv support in regular 801.1q
> ethernet switches that allow me to map the user priority field to wfq
> queues.  rpr doesn't offer this capability. 
> 
> phb stands for "per HOP behavior".  of course it is possible to support
> diffserv only at the edge, but that doesn't lead to the most efficient
> use of the bandwidth.  it is the same as using cbr vc to connect routers
> together over atm backbone.

Err, lets set the perfect world aside for a moment.  

If your core has a specific capacity, and you meter, classify, policy at the
edge, don't you have guarantees which enable differentiated services?  Sure,
diffserv everywhere would be cool.. but, also $$$ and how real is this real?

You can drive diffserv as far as you want, and theoretically anything's
possible, but at some point you reach the point of diminishing returns.. 

Budgetary realities do exist.

Flame away.

Cheers,
Chris

-- 
Christian Kuhtz  -wk,  -hm
Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
"I speak for myself only.""


From owner-mpls@UU.NET  Mon Jul 30 14:05: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 OAA11611
	for ; Mon, 30 Jul 2001 14:05: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 QQkzye21697;
	Mon, 30 Jul 2001 18:05:33 GMT
Received: by mail-control.mail.uu.net 
	id QQkzye14713
	for mpls-outgoing; Mon, 30 Jul 2001 18:05: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 QQkzye12961
	for ; Mon, 30 Jul 2001 18:04: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 QQkzye27831
	for ; Mon, 30 Jul 2001 18:03:44 GMT
Received: from longsys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dmz.longsys.com [63.111.150.5])
	id QQkzye22959
	for ; Mon, 30 Jul 2001 18:03:43 GMT
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id f6UI3I429836;
	Mon, 30 Jul 2001 18:03:18 GMT
Message-Id: <4.2.2.20010730135915.00cd47c0@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 30 Jul 2001 14:02:45 -0400
To: Juha Heinanen , Fred Baker 
From: "Joel M. Halpern" 
Subject: RE: QoS in Shared Media
Cc: "'mpls@uu.net'" , 
In-Reply-To: <15205.39508.911082.655894@lohi.eng.telia.fi>
References: <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
 
 <15091.38161.514887.486740@lohi.eng.telia.fi>
 <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

[Given that I did not start this, I am reluctant to change the target wg, 
but it sure looks like a diffserv discussion, not an MPLS or TE discussion.]

Juha, given that your earlier note said specifically that the technology 
under discussion does support two levels of priority queueing,  it seems 
that you do not have any grounds to complain that it does not support 
diffserv.  It does not support the particular PHB the way you want it 
supported.  One could have a discussion about whether it supports a given 
PHB at all under a specific configuration or under all possible 
configurations.  But that does not mean that the technology does not 
support or is not compliant with diffserv.

Yours,
Joel M. Halpern

At 08:33 PM 7/30/01 +0300, Juha Heinanen wrote:
>fred,
>
>i have no problems whatsoever with diffserv support in regular 801.1q
>ethernet switches that allow me to map the user priority field to wfq
>queues.  rpr doesn't offer this capability.
>
>phb stands for "per HOP behavior".  of course it is possible to support
>diffserv only at the edge, but that doesn't lead to the most efficient
>use of the bandwidth.  it is the same as using cbr vc to connect routers
>together over atm backbone.
>
>-- juha



From owner-mpls@UU.NET  Mon Jul 30 14:14:43 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 OAA12592
	for ; Mon, 30 Jul 2001 14:14: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 QQkzye05848;
	Mon, 30 Jul 2001 18:14:54 GMT
Received: by mail-control.mail.uu.net 
	id QQkzye20374
	for mpls-outgoing; Mon, 30 Jul 2001 18:14: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 QQkzye20361
	for ; Mon, 30 Jul 2001 18:14:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkzye21549
	for ; Mon, 30 Jul 2001 18:14:15 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkzye29786
	for ; Mon, 30 Jul 2001 18:14:14 GMT
Message-ID: <3B65A3F3.99B5E8BE@sandburst.com>
Date: Mon, 30 Jul 2001 14:14:11 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Christian Kuhtz 
Cc: Juha Heinanen , Fred Baker ,
        Jay Wang ,
        HANSEN CHAN ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , te-wg@ops.ietf.org
Subject: Re: QoS in Shared Media
References:  <15091.38161.514887.486740@lohi.eng.telia.fi> <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com> <15205.39508.911082.655894@lohi.eng.telia.fi> <20010730135547.Q27172@ns1.arch.bellsouth.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Chris,

    Unless the drain rate at each of your egress points exceeds the
capacity of your core, you don't achieve any particularly good
guarantees if all you do is police at the edge.  In fact, what you
might see is worst case behavior where a lot of traffic makes it close
to an egress point and is dropped as a result of local congestion AFTER
having already consumed core resources in getting that far.

--
Eric Gray

You wrote:

> On Mon, Jul 30, 2001 at 08:33:08PM +0300, Juha Heinanen wrote:
> > fred,
> >
> > i have no problems whatsoever with diffserv support in regular 801.1q
> > ethernet switches that allow me to map the user priority field to wfq
> > queues.  rpr doesn't offer this capability.
> >
> > phb stands for "per HOP behavior".  of course it is possible to support
> > diffserv only at the edge, but that doesn't lead to the most efficient
> > use of the bandwidth.  it is the same as using cbr vc to connect routers
> > together over atm backbone.
>
> Err, lets set the perfect world aside for a moment.
>
> If your core has a specific capacity, and you meter, classify, policy at the
> edge, don't you have guarantees which enable differentiated services?  Sure,
> diffserv everywhere would be cool.. but, also $$$ and how real is this real?
>
> You can drive diffserv as far as you want, and theoretically anything's
> possible, but at some point you reach the point of diminishing returns..
>
> Budgetary realities do exist.
>
> Flame away.
>
> Cheers,
> Chris
>
> --
> Christian Kuhtz  -wk,  -hm
> Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
> "I speak for myself only.""



From owner-mpls@UU.NET  Mon Jul 30 14:17: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 OAA12865
	for ; Mon, 30 Jul 2001 14:17:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzyf11915;
	Mon, 30 Jul 2001 18:18:36 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyf20989
	for mpls-outgoing; Mon, 30 Jul 2001 18:18: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 QQkzyf20978
	for ; Mon, 30 Jul 2001 18:18: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 QQkzyf14059
	for ; Mon, 30 Jul 2001 18:16:57 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 QQkzyf11181
	for ; Mon, 30 Jul 2001 18:16:56 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA25960 for mpls@uu.net; Mon, 30 Jul 2001 14:16:55 -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 QQkzye20356
	for ; Mon, 30 Jul 2001 18:14: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 QQkzye09774
	for ; Mon, 30 Jul 2001 18:14:11 GMT
Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQkzye04720
	for ; Mon, 30 Jul 2001 18:14:10 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f6UIDu711493;
	Mon, 30 Jul 2001 21:13:56 +0300
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15205.41956.480486.112112@lohi.eng.telia.fi>
Date: Mon, 30 Jul 2001 21:13:56 +0300 (EEST)
To: Christian Kuhtz 
Cc: Fred Baker , Jay Wang ,
        HANSEN CHAN ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , te-wg@ops.ietf.org
Subject: Re: QoS in Shared Media
In-Reply-To: <20010730135547.Q27172@ns1.arch.bellsouth.net>
References: 
	<15091.38161.514887.486740@lohi.eng.telia.fi>
	<5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
	<15205.39508.911082.655894@lohi.eng.telia.fi>
	<20010730135547.Q27172@ns1.arch.bellsouth.net>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian Kuhtz writes:

 > Budgetary realities do exist.

i don't get this point.  any cisco or juniper core router supports
diffserv equally well or badly over pos, serial and ethernet interfaces.
also all decent ethernet switched mapping of user priority to wfq
queues.  this is not thus not a money issue, but rpr issue.

-- juha



From owner-mpls@UU.NET  Mon Jul 30 14:21: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 OAA13162
	for ; Mon, 30 Jul 2001 14:21:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzyf17255;
	Mon, 30 Jul 2001 18:21:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyf21245
	for mpls-outgoing; Mon, 30 Jul 2001 18:21: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 QQkzyf21164
	for ; Mon, 30 Jul 2001 18:20:55 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 QQkzyf18552
	for ; Mon, 30 Jul 2001 18:19:38 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 QQkzyf14847
	for ; Mon, 30 Jul 2001 18:19:37 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA26381 for mpls@uu.net; Mon, 30 Jul 2001 14:19: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 QQkzyf20999
	for ; Mon, 30 Jul 2001 18:18:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzyf15577
	for ; Mon, 30 Jul 2001 18:17:58 GMT
Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQkzyf10866
	for ; Mon, 30 Jul 2001 18:17:57 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f6UIHqE11507;
	Mon, 30 Jul 2001 21:17:52 +0300
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15205.42192.416592.427543@lohi.eng.telia.fi>
Date: Mon, 30 Jul 2001 21:17:52 +0300 (EEST)
To: "Joel M. Halpern" 
Cc: Fred Baker , "'mpls@uu.net'" ,
        
Subject: RE: QoS in Shared Media
In-Reply-To: <4.2.2.20010730135915.00cd47c0@localhost>
References: <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
	
	<15091.38161.514887.486740@lohi.eng.telia.fi>
	<4.2.2.20010730135915.00cd47c0@localhost>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

joel,

there is no such thing as "diffserv compliance".  to me a device is
diffserv capable if i can map a layer 3 or layer 2 "tos" code point to
a wfq and red drop precedence.  as my example showed, dpt/rpr doesn't
have this capability.

-- juha



From owner-mpls@UU.NET  Mon Jul 30 14:30: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 OAA14225
	for ; Mon, 30 Jul 2001 14: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 QQkzyg07564;
	Mon, 30 Jul 2001 18:31:15 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyg21833
	for mpls-outgoing; Mon, 30 Jul 2001 18:30: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 QQkzyg21827
	for ; Mon, 30 Jul 2001 18:30: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 QQkzyf05193
	for ; Mon, 30 Jul 2001 18:29:47 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 QQkzyf27543
	for ; Mon, 30 Jul 2001 18:29:47 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA27883 for mpls@uu.net; Mon, 30 Jul 2001 14:29: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 QQkzyf21723
	for ; Mon, 30 Jul 2001 18:29: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 QQkzyf03791
	for ; Mon, 30 Jul 2001 18:28:41 GMT
Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkzyf25752
	for ; Mon, 30 Jul 2001 18:28:40 GMT
Received: from FRED-W2K2.cisco.com ([171.71.21.236])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6UISVg13523;
	Mon, 30 Jul 2001 11:28:31 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010730105008.044889b0@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 30 Jul 2001 10:50:23 +0100
To: Juha Heinanen 
From: Fred Baker 
Subject: RE: QoS in Shared Media
Cc: "Jay Wang" ,
        "HANSEN CHAN" ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , 
In-Reply-To: <15205.39508.911082.655894@lohi.eng.telia.fi>
References: <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
 
 <15091.38161.514887.486740@lohi.eng.telia.fi>
 <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:33 PM 7/30/2001, Juha Heinanen wrote:
>phb stands for "per HOP behavior".

yes, and it is supported at every IP hop.



From owner-mpls@UU.NET  Mon Jul 30 14:44:22 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 OAA15076
	for ; Mon, 30 Jul 2001 14:44: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 QQkzyh03327;
	Mon, 30 Jul 2001 18:45:01 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyg22619
	for mpls-outgoing; Mon, 30 Jul 2001 18:44:29 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 QQkzyg22604
	for ; Mon, 30 Jul 2001 18:44: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 QQkzyg21660
	for ; Mon, 30 Jul 2001 18:43:14 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 QQkzyg21795
	for ; Mon, 30 Jul 2001 18:43:13 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA29335 for mpls@uu.net; Mon, 30 Jul 2001 14:43:13 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkzyg22522
	for ; Mon, 30 Jul 2001 18:42:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkzyg22793
	for ; Mon, 30 Jul 2001 18:42:12 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f283.law10.hotmail.com [64.4.14.158])
	id QQkzyg11221
	for ; Mon, 30 Jul 2001 18:42:11 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 30 Jul 2001 11:42:11 -0700
Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP;	Mon, 30 Jul 2001 18:42:11 GMT
X-Originating-IP: [38.204.3.195]
From: "manoj juneja" 
To: mpls@UU.NET
Subject: Forwarding Adjacency Doubt
Date: Mon, 30 Jul 2001 11:42:11 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 30 Jul 2001 18:42:11.0318 (UTC) FILETIME=[57F50960:01C11927]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
        Is the concept of Forwarding Adjacency (FA) applicable to 
traditional MPLS or just GMPLS ?

If it is applicable to classical MPLS, then what are its applications ?

Regards,
manoj.

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



From owner-mpls@UU.NET  Mon Jul 30 14:47: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 OAA15202
	for ; Mon, 30 Jul 2001 14:47: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 QQkzyh28726;
	Mon, 30 Jul 2001 18:47:06 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyh23091
	for mpls-outgoing; Mon, 30 Jul 2001 18:46:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzyh23061
	for ; Mon, 30 Jul 2001 18:46:20 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 QQkzyg11000
	for ; Mon, 30 Jul 2001 18:44: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 QQkzyg24098
	for ; Mon, 30 Jul 2001 18:44:34 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA29462 for mpls@uu.net; Mon, 30 Jul 2001 14:44:34 -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 QQkzyg22579
	for ; Mon, 30 Jul 2001 18:44: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 QQkzyg28142
	for ; Mon, 30 Jul 2001 18:43:39 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 QQkzyg12832
	for ; Mon, 30 Jul 2001 18:43:38 GMT
Received: from FRED-W2K2.cisco.com ([171.71.21.236])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6UIhLg25676;
	Mon, 30 Jul 2001 11:43:21 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010730113316.04228008@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 30 Jul 2001 11:36:44 +0100
To: Eric Gray 
From: Fred Baker 
Subject: Re: QoS in Shared Media
Cc: Christian Kuhtz ,
        Juha Heinanen ,
        Jay Wang ,
        HANSEN CHAN ,
        "Naidu, Venkata" ,
        "'mpls@uu.net'" , te-wg@ops.ietf.org
In-Reply-To: <3B65A3F3.99B5E8BE@sandburst.com>
References: 
 <15091.38161.514887.486740@lohi.eng.telia.fi>
 <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
 <15205.39508.911082.655894@lohi.eng.telia.fi>
 <20010730135547.Q27172@ns1.arch.bellsouth.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:14 PM 7/30/2001, Eric Gray wrote:
>Unless the drain rate at each of your egress points exceeds the
>capacity of your core, you don't achieve any particularly good
>guarantees if all you do is police at the edge.

the drain rate of an RPR ring is presumably the same is its internal rate - 
if all the traffic is directed to a particular system, it will drain all 
the traffic from the ring. What it does on the next interface is 
interesting from a larger perspective, but not from the perspective of the 
RPR ring.

The point here is that diffserv may be used to control the rates at which 
various RPR systems put various kinds of traffic onto the RPR ring, and RPR 
will carry it. Like diffserv in any network, if supply exceeds demand 
sometime later, we can only hope that the users' TCPs will notice that and 
slow down.



From owner-mpls@UU.NET  Mon Jul 30 14:50:39 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 OAA15332
	for ; Mon, 30 Jul 2001 14:50: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 QQkzyh21601;
	Mon, 30 Jul 2001 18:51:08 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyh23519
	for mpls-outgoing; Mon, 30 Jul 2001 18:50:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkzyh23459
	for ; Mon, 30 Jul 2001 18:50: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 QQkzyh20635
	for ; Mon, 30 Jul 2001 18:49:48 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 QQkzyh03962
	for ; Mon, 30 Jul 2001 18:49:48 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA00571 for mpls@uu.net; Mon, 30 Jul 2001 14:49:48 -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 QQkzyh22966
	for ; Mon, 30 Jul 2001 18:46:00 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 QQkzyg26916
	for ; Mon, 30 Jul 2001 18:44:01 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 QQkzyg13222
	for ; Mon, 30 Jul 2001 18:44:00 GMT
Received: from FRED-W2K2.cisco.com ([171.71.21.236])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6UIhNg25686;
	Mon, 30 Jul 2001 11:43:23 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010730113754.041da4f8@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 30 Jul 2001 11:41:30 +0100
To: Juha Heinanen 
From: Fred Baker 
Subject: RE: QoS in Shared Media
Cc: "Joel M. Halpern" , "'mpls@uu.net'" ,
        
In-Reply-To: <15205.42192.416592.427543@lohi.eng.telia.fi>
References: <4.2.2.20010730135915.00cd47c0@localhost>
 <5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
 
 <15091.38161.514887.486740@lohi.eng.telia.fi>
 <4.2.2.20010730135915.00cd47c0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:17 PM 7/30/2001, Juha Heinanen wrote:
>to me a device is diffserv capable if i can map a layer 3 or layer 2 "tos" 
>code point to
>a wfq and red drop precedence.  as my example showed, dpt/rpr doesn't have 
>this capability.

There is no requirement that a diffserv device implement WFQ. Hence, this 
is not fundamental.

In a system which drops no traffic, what does "drop preference" mean?

Yes, RPR does not internally implement WFQ or RED. It does offer the 
ability to differentiate among streams of traffic based on an attribute 
carried in the packet without having to perform obnoxious ACLs. Those are 
the only requirements I find in RFCs 2474/2475.



From owner-mpls@UU.NET  Mon Jul 30 14:58: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 OAA15699
	for ; Mon, 30 Jul 2001 14:58:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzyh29717;
	Mon, 30 Jul 2001 18:58:42 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyh24196
	for mpls-outgoing; Mon, 30 Jul 2001 18:58: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 QQkzyh24186
	for ; Mon, 30 Jul 2001 18:58: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 QQkzyh11128
	for ; Mon, 30 Jul 2001 18:57: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 QQkzyh14282
	for ; Mon, 30 Jul 2001 18:57:12 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA01807 for mpls@uu.net; Mon, 30 Jul 2001 14:57: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 QQkzyh24135
	for ; Mon, 30 Jul 2001 18:56:44 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 QQkzyh24011
	for ; Mon, 30 Jul 2001 18:56:37 GMT
Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQkzyh25788
	for ; Mon, 30 Jul 2001 18:56:37 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f6UIuTp11596;
	Mon, 30 Jul 2001 21:56:29 +0300
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15205.44509.235409.141765@lohi.eng.telia.fi>
Date: Mon, 30 Jul 2001 21:56:29 +0300 (EEST)
To: Fred Baker 
Cc: "Joel M. Halpern" , "'mpls@uu.net'" ,
        
Subject: RE: QoS in Shared Media
In-Reply-To: <5.1.0.14.2.20010730113754.041da4f8@mira-sjcm-2.cisco.com>
References: <4.2.2.20010730135915.00cd47c0@localhost>
	<5.1.0.14.2.20010730095114.0421d530@mira-sjcm-2.cisco.com>
	
	<15091.38161.514887.486740@lohi.eng.telia.fi>
	<5.1.0.14.2.20010730113754.041da4f8@mira-sjcm-2.cisco.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fred Baker writes:

 > There is no requirement that a diffserv device implement WFQ. Hence, this 
 > is not fundamental.

it is pretty hard to implement af without wfq and red or something that
closely resembles them.

 > In a system which drops no traffic, what does "drop preference" mean?

nothing, but bandwidth (especially international) so far has not been
free.

i can't quite figure out why this outburst to my email, where i gave a
simple example on how rpr doesn't support af.  i very well understand
that not everyone needs that capability and is happy with rpr rings.

-- juha



From owner-mpls@UU.NET  Mon Jul 30 15: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 PAA16800
	for ; Mon, 30 Jul 2001 15: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 QQkzyj05215;
	Mon, 30 Jul 2001 19:17:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyj15651
	for mpls-outgoing; Mon, 30 Jul 2001 19:16: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 QQkzyj15633
	for ; Mon, 30 Jul 2001 19:16: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 QQkzyi04020
	for ; Mon, 30 Jul 2001 19:14:11 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 QQkzyi05201
	for ; Mon, 30 Jul 2001 19:14:11 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 PAA07377;
	Mon, 30 Jul 2001 15:14:09 -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 PAA04805;
	Mon, 30 Jul 2001 15:14:09 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 30 Jul 2001 15:14:09 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C64A@VIE-MSGUSR-01>
From: "Naidu, Venkata" 
To: "'manoj juneja'" , mpls@UU.NET
Subject: RE: Forwarding Adjacency Doubt
Date: Mon, 30 Jul 2001 15:14:03 -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

Manoj,
  
-> Hi All,
->         Is the concept of Forwarding Adjacency (FA) applicable to 
-> traditional MPLS or just GMPLS ?

   FA or FA-LSPs are initially defined in "classical" MPLS.
   Don't make MPLS "traditional" ;-)
    
-> If it is applicable to classical MPLS, then what are its 
-> applications ?

   Traffic Engineering. 
   Refer to draft-ietf-mpls-lsp-hierarchy-02.txt
 
--Venkata Naidu


From owner-mpls@UU.NET  Mon Jul 30 15:24: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 PAA17374
	for ; Mon, 30 Jul 2001 15:24: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 QQkzyj24274;
	Mon, 30 Jul 2001 19:24:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyj16232
	for mpls-outgoing; Mon, 30 Jul 2001 19:24: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 QQkzyj16219
	for ; Mon, 30 Jul 2001 19:23: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 QQkzyj15038
	for ; Mon, 30 Jul 2001 19:23:11 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQkzyj00207
	for ; Mon, 30 Jul 2001 19:23:11 GMT
Received: from BLIULAPTOP ([172.16.8.181]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 30 Jul 2001 15:23:07 -0400
Message-ID: <01cd01c1192c$a0fb1730$27de883e@movaz.com>
From: "Adrian Farrel" 
To: "Thomas D. Nadeau" 
Cc: , "'mpls@uu.net'" 
References: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com>
Subject: Re: Doubts about MPLS-TE Mib
Date: Mon, 30 Jul 2001 14:38:02 -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: 30 Jul 2001 19:23:09.0842 (UTC) FILETIME=[115A0720:01C1192D]
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom, am I being dense?

In the protocol (RSVP) we have
- source address in Sender Template
- extended tunnel id in Session.

Extended tunnel id may be set to the source address to reduce the scope for
resource sharing between LSPs that might (intentionally or accidentally) have
the same other Session fields.  Set to zero (or some other NetAdmin controlled
value) extended tunnel id allows sharing between LSPs provided their Session id
is the same.

So...
At the ingress we need to allow control of the extended tunnel id so that
NetAdmin can decide what level of resource sharing is allowed.  In some
implementations this will not be an option (extended tunnel id will always be
set to source address), but other implementations will allow this control.
At the ingress one could argue that the source address should not under NetAdmin
control since you shouldn't be able to attempt impersonation, but in the case
where a node has multiple addresses, it would be reasonable to allow the value
to be controlled.

At transit and egress nodes, since there two fields in the protocol, the MIB
should display both.

So the requirement is for two distinct fields.

How does this map to the current MIB?

mplsTunnelIngressLSRId is, rightly, an index into the mplsTunnelTable since it
defines the source which is part of the identifier of the LSP.  Despite the
comments in the MIB, I think this field maps to the source address in the Sender
Template.

We need another field for extended tunnel id that should (possibly) be an index
as well.

Adrian

PS

--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com

----- Original Message -----
From: "Thomas D. Nadeau" 
To: "Apratim Mukherjee" 
Cc: 
Sent: Monday, July 30, 2001 10:18 AM
Subject: RE: Doubts about MPLS-TE Mib


> At 07:18 PM 7/30/2001 +0530, Apratim Mukherjee wrote:
> >Hi Tom ,
> >
> >Thanks for the clarification .
> >         >>But , this is also being used as extended tunnel id , in which
> >case it COULD
> >         >>be 0 ... then isn't there an indexing problem ?
> >         >        Why? 0 is a perfectly valid index.
> >What i meant here is that if extended tunnel id is 0 , then IngressLSRId is
> >0 (If Extended Tunnel Id is ALWAYS same as IngressLSRId). If IngressLSRId is
> >0 , then Sender Template ip address is 0.0.0.0  , if this is same as Ingress
> >LSR Id  . This is wrong since information about the sender Ip address is
> >absolutely essential . I  think there shoud be a separate field for Extended
> >Tunnel Id as this has no necessary relation with IngressLSRId . ( They only
> >MIGHT be same ) .
>
>          This is an artifact of how the protocol works,
> and the MIB models the protocols. I personally think
> that the protocol should have made the Ingress
> LSR Id mandatory for the reason you stated, but it
> didn't. Fortunately, all of the implementations I know
> of to insert the loopback address in this field, so
> operationally there should not be any problem
> (and have not been from what I have heard/seen).
>






From owner-mpls@UU.NET  Mon Jul 30 16:19: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 QAA21754
	for ; Mon, 30 Jul 2001 16:18: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 QQkzyn04707;
	Mon, 30 Jul 2001 20:19:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyn10044
	for mpls-outgoing; Mon, 30 Jul 2001 20:18: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 QQkzyn10039
	for ; Mon, 30 Jul 2001 20:18: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 QQkzyn28448
	for ; Mon, 30 Jul 2001 20:18: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 QQkzyn18134
	for ; Mon, 30 Jul 2001 20:18:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08741 for mpls@uu.net; Mon, 30 Jul 2001 16:18: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 QQkzym09500
	for ; Mon, 30 Jul 2001 20:13: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 QQkzym21843
	for ; Mon, 30 Jul 2001 20:13:22 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 QQkzym26076
	for ; Mon, 30 Jul 2001 20:13:22 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 QAA08816; Mon, 30 Jul 2001 16:13:20 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AEZ02980;
	Mon, 30 Jul 2001 16:13:17 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010730160338.028e69b0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 30 Jul 2001 16:18:51 -0400
To: "Adrian Farrel" 
From: "Thomas D. Nadeau" 
Subject: Re: Doubts about MPLS-TE Mib
Cc: , "'mpls@uu.net'" 
In-Reply-To: <01cd01c1192c$a0fb1730$27de883e@movaz.com>
References: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>Tom, am I being dense?
>In the protocol (RSVP) we have
>- source address in Sender Template
>- extended tunnel id in Session.
>
>Extended tunnel id may be set to the source address to reduce the scope for
>resource sharing between LSPs that might (intentionally or accidentally) have
>the same other Session fields.

         That is the first that I have ever heard of resource sharing
being accomplished that way. This seems haphazard and vendor-specific
at best. If you want to share tunnel resources, do so explicitly by
having the same tunnel resource entries shared by multiple tunnel
entries.

>Set to zero (or some other NetAdmin controlled
>value) extended tunnel id allows sharing between LSPs provided their 
>Session id
>is the same.

         That is not a MIB issue. If the admin does what you describe,
then RSVP will not work, period. You will have mis-configured
your network because you will have non-unique sessions, and thus
sessions will not be signaled. This is not a MIB issue.
I think that the BCP here is to do what the RSVP-TE specification
suggests (and should have made mandatory, IMHO). That is, to set the
ingress LSR id as the extended id.

>So...
>At the ingress we need to allow control of the extended tunnel id so that
>NetAdmin can decide what level of resource sharing is allowed.  In some
>implementations this will not be an option (extended tunnel id will always be
>set to source address), but other implementations will allow this control.
>At the ingress one could argue that the source address should not under 
>NetAdmin
>control since you shouldn't be able to attempt impersonation, but in the case
>where a node has multiple addresses, it would be reasonable to allow the value
>to be controlled.
>
>At transit and egress nodes, since there two fields in the protocol, the MIB
>should display both.

         You can see both fields at transit nodes: look at the tunnel
entry and the RSVP MIB for that session.

>So the requirement is for two distinct fields.

         I don't see it as a requirement to see both fields
distinctively. RSVP TE uses them synonymously to function
correctly.

>How does this map to the current MIB?

         The LSR ID is mapped into the extended tunnel ID field.
If you want a different value in that field, change
the router's LSR ID so that all tunnels will utilize that as
their LSR ID. Using something that is non-unique (i.e.: not
the router's LSR id) is just asking for trouble.

         --Tom




From owner-mpls@UU.NET  Mon Jul 30 17:04:47 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 RAA24713
	for ; Mon, 30 Jul 2001 17:04: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 QQkzyq10571;
	Mon, 30 Jul 2001 21:05:22 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyq27520
	for mpls-outgoing; Mon, 30 Jul 2001 21:04: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 QQkzyq26600
	for ; Mon, 30 Jul 2001 21:04: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 QQkzyq18125
	for ; Mon, 30 Jul 2001 21:04:16 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 QQkzyq08563
	for ; Mon, 30 Jul 2001 21:04:16 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 RAA21042
	for ; Mon, 30 Jul 2001 17:04:13 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02094
	for ; Mon, 30 Jul 2001 17:04:15 -0400 (EDT)
Message-ID: <3B65CBCA.9DE3CD71@marconi.com>
Date: Mon, 30 Jul 2001 17:04:10 -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: Doubts about MPLS-TE Mib
References: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com> <4.3.2.7.2.20010730160338.028e69b0@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Thomas D. Nadeau" wrote:
>> 
>> Set to zero (or some other NetAdmin controlled
>> value) extended tunnel id allows sharing between LSPs provided their
>> Session id is the same.
> 
> That is not a MIB issue. If the admin does what you describe,
> then RSVP will not work, period. You will have mis-configured
> your network because you will have non-unique sessions, and thus
> sessions will not be signaled.

No.  This is not at all true.  There is _NOTHING_ in RSVP that requires
every LSP to be in a separate session.  Multiple LSPs sharing a single
session is the mechanism by which resources are shared.  It is this
precise mechanism that allows make-before-break to work.

Setting the extended tunnel ID to zero is perfectly legal.  It is the
mechanism by which multiple LSPs may share resources if they originate
from different routers.

> This is not a MIB issue.  I think that the BCP here is to do what
> the RSVP-TE specification suggests (and should have made mandatory,
> IMHO). That is, to set the ingress LSR id as the extended id.

I would strongly disagree with you here.  RSVP-TE has this mechanism,
which makes it relatively simple to support many-to-one LSPs.  Would you
rather someone creates a new, and incompatible mechansim for this
instead?

It is well known that the MIB does not support all of the features of
RSVP-TE.  This discussion has gone around this group several times.  It
is clear that the authors of the MIB are not interested in being able to
represent every kind of setup that RSVP can legally get into.  That's
their choice, of course, but it doesn't mean that RSVP's specification
should now be changed in order to accomodate it.

That's like wanting to redesign a car for a top speed of 85, because the
speedometer doesn't go any higher.

-- David


From owner-mpls@UU.NET  Mon Jul 30 19:20: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 TAA02423
	for ; Mon, 30 Jul 2001 19:20: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 QQkzyz06128;
	Mon, 30 Jul 2001 23:20:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyz23190
	for mpls-outgoing; Mon, 30 Jul 2001 23:20: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 QQkzyz23181
	for ; Mon, 30 Jul 2001 23:20: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 QQkzyz07434
	for ; Mon, 30 Jul 2001 23:19: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 QQkzyz04265
	for ; Mon, 30 Jul 2001 23:19: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 TAA00430
	for ; Mon, 30 Jul 2001 19:19:40 -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 TAA20561
	for ; Mon, 30 Jul 2001 19:19:42 -0400 (EDT)
Message-ID: <3B65EB8A.16856B39@marconi.com>
Date: Mon, 30 Jul 2001 19:19:38 -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: Doubts about MPLS-TE Mib
References: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com> <4.3.2.7.2.20010730160338.028e69b0@bucket.cisco.com> <020901c1193c$63f8b3a0$27de883e@movaz.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> You can see both fields at transit nodes: look at the tunnel
>> entry and the RSVP MIB for that session.
> 
> Aha.  That is certainly an answer.

Unfortunately, there is no RSVP-TE MIB, even in draft form.

True, you can take the MIB from RFC 2209 and tweak it for the new fields
used by RSVP-TE, but you necessarily end up with a private MIB, not a
standard.

A while back, I asked about an RSVP-TE MIB and was told that it is
unnecessary because the MPLS TE-MIB presents all the same information. 
Unfortunately, this turned out not to be true.

-- David


From owner-mpls@UU.NET  Mon Jul 30 19:32:17 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 TAA02717
	for ; Mon, 30 Jul 2001 19:32:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzza28071;
	Mon, 30 Jul 2001 23:32:51 GMT
Received: by mail-control.mail.uu.net 
	id QQkzza24073
	for mpls-outgoing; Mon, 30 Jul 2001 23:32: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 QQkzza24065
	for ; Mon, 30 Jul 2001 23:32:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzza06589
	for ; Mon, 30 Jul 2001 23:31:48 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQkzza26966
	for ; Mon, 30 Jul 2001 23:31:48 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6UNVkH35896;
	Mon, 30 Jul 2001 16:31:46 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id QAA24713; Mon, 30 Jul 2001 16:31:46 -0700 (PDT)
Date: Mon, 30 Jul 2001 16:31:46 -0700 (PDT)
From: Kireeti Kompella 
Message-Id: <200107302331.QAA24713@kummer.juniper.net>
To: manojkumarjuneja@hotmail.com, mpls@UU.NET, Venkata.Naidu@Marconi.com
Subject: RE: Forwarding Adjacency Doubt
In-Reply-To: <39469E08BD83D411A3D900204840EC5554C64A@VIE-MSGUSR-01>
Sender: owner-mpls@UU.NET
Precedence: bulk

> traditional MPLS or just GMPLS ?

BTW, a correction in perception: GMPLS *includes* traditional/classical
MPLS.  GMPLS is *not* restricted to non-packet LSPs!

Kireeti.


From owner-mpls@UU.NET  Mon Jul 30 20: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 UAA03426
	for ; Mon, 30 Jul 2001 20:07: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 QQkzyr19545;
	Mon, 30 Jul 2001 21:19:53 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyr04317
	for mpls-outgoing; Mon, 30 Jul 2001 21:19:22 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 QQkzyr04309
	for ; Mon, 30 Jul 2001 21:19: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 QQkzyr15246
	for ; Mon, 30 Jul 2001 21:16:05 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQkzyr28876
	for ; Mon, 30 Jul 2001 21:16:03 GMT
Received: from BLIULAPTOP ([172.16.8.181]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 30 Jul 2001 17:15:57 -0400
Message-ID: <020901c1193c$63f8b3a0$27de883e@movaz.com>
From: "Adrian Farrel" 
To: "Thomas D. Nadeau" 
Cc: , "'mpls@uu.net'" 
References: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com> <4.3.2.7.2.20010730160338.028e69b0@bucket.cisco.com>
Subject: Re: Doubts about MPLS-TE Mib
Date: Mon, 30 Jul 2001 17:11:50 -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: 30 Jul 2001 21:15:59.0959 (UTC) FILETIME=[D4A7E670:01C1193C]
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom,

> >In the protocol (RSVP) we have
> >- source address in Sender Template
> >- extended tunnel id in Session.
> >
> >Extended tunnel id may be set to the source address to reduce the scope for
> >resource sharing between LSPs that might (intentionally or accidentally) have
> >the same other Session fields.
>
>          That is the first that I have ever heard of resource sharing
> being accomplished that way. This seems haphazard and vendor-specific
> at best. If you want to share tunnel resources, do so explicitly by
> having the same tunnel resource entries shared by multiple tunnel
> entries.

This is a protocol issue that I am exposing.  I'm trying to show (unsuccessfully
:-) that the two quantities 'source address' and 'extended tunnel id' are
distinct within the protocol.  From this will follow the need for two separate
fields in the MIB.

Resources may be shared within the network by LSPs that belong to the same
session (where the Style is Shared Explicit etc., etc.).  "Ingress nodes that
wish to narrow the scope of a SESSION to the ingress-egress  pair  may  place
their  IPv4 address here [Extended Tunnel Id] as a globally unique identifier."
[draft-ietf-mpls-rsvp-lsp-tunnel-08, 4.6.1.1]

> >Set to zero (or some other NetAdmin controlled
> >value) extended tunnel id allows sharing between LSPs provided their
> >Session id is the same.
>
>          That is not a MIB issue. If the admin does what you describe,
> then RSVP will not work, period. You will have mis-configured
> your network because you will have non-unique sessions, and thus
> sessions will not be signaled. This is not a MIB issue.

Well, talking of vendor-specific issues... :-)
RSVP _should_ work.

The source address is not part of the session id.  It is in the Sender Template.
It is completely legal to have identical session ids from distinct ingress
points - this is how (the mythical?) LSP merge works.  It is completely legal to
have two LSPs with identical session ids from the same ingress point - this is
how make-before-break works.

> I think that the BCP here is to do what the RSVP-TE specification
> suggests (and should have made mandatory, IMHO). That is, to set the
> ingress LSR id as the extended id.

But it doesn't suggest it, per se.  It suggests it _if_ you don't want to allow
LSP merge.  Why would you want to prevent LSP merge using this technique
(although there are other ways of achieving it)?

Seen another way, if the extended tunnel id was intended to be always the same
value as the source address, why introduce the field in RSVP-TE (it did not
exist in RSVP)?  If it has no value let's drop it from the protocol; but it does
have value.

> >So...
> >At the ingress we need to allow control of the extended tunnel id so that
> >NetAdmin can decide what level of resource sharing is allowed.  In some
> >implementations this will not be an option (extended tunnel id will always be
> >set to source address), but other implementations will allow this control.
> >At the ingress one could argue that the source address should not under
> >NetAdmin
> >control since you shouldn't be able to attempt impersonation, but in the case
> >where a node has multiple addresses, it would be reasonable to allow the
value
> >to be controlled.
> >
> >At transit and egress nodes, since there two fields in the protocol, the MIB
> >should display both.
>
>You can see both fields at transit nodes: look at the tunnel
>entry and the RSVP MIB for that session.

Aha.  That is certainly an answer.

But what about the other fields that overlap between RSVP and RSVP-TE?  We don't
want to move them out of the TE-MIB.

> >So the requirement is for two distinct fields.
>
>          I don't see it as a requirement to see both fields
> distinctively. RSVP TE uses them synonymously to function
> correctly.

As above, it doesn't.

Adrian






From owner-mpls@UU.NET  Mon Jul 30 21:30: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 VAA06253
	for ; Mon, 30 Jul 2001 21:30:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkzzi00886;
	Tue, 31 Jul 2001 01:30:52 GMT
Received: by mail-control.mail.uu.net 
	id QQkzzi12208
	for mpls-outgoing; Tue, 31 Jul 2001 01:30: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 QQkzzi12178
	for ; Tue, 31 Jul 2001 01:30: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 QQkzzh08601
	for ; Tue, 31 Jul 2001 01:29: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 QQkzzh29554
	for ; Tue, 31 Jul 2001 01:29:45 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA26850 for mpls@uu.net; Mon, 30 Jul 2001 21:29: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 QQkzzh12084
	for ; Tue, 31 Jul 2001 01:29:06 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 QQkzzh01461
	for ; Tue, 31 Jul 2001 01:28:58 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f247.law10.hotmail.com [64.4.15.247])
	id QQkzzh09099
	for ; Tue, 31 Jul 2001 01:28:58 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 30 Jul 2001 18:28:57 -0700
Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP;	Tue, 31 Jul 2001 01:28:57 GMT
X-Originating-IP: [38.204.3.195]
From: "manoj juneja" 
To: mpls@UU.NET
Subject: Usage of object LSP_TUNNEL_INTERFACE_ID
Date: Mon, 30 Jul 2001 18:28:57 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 31 Jul 2001 01:28:57.0918 (UTC) FILETIME=[2B6CA5E0:01C11960]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
          Can someone please explain me where and how the 
LSP_TUNNEL_INTERFACE_ID object is used in RSVP-TE ?

Regards,
manoj.

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



From owner-mpls@UU.NET  Mon Jul 30 22:28: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 SMTP id WAA10882
	for ; Mon, 30 Jul 2001 22:28: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 QQkzyz22982;
	Mon, 30 Jul 2001 23:28:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkzyz23685
	for mpls-outgoing; Mon, 30 Jul 2001 23:28:01 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 QQkzyz23674
	for ; Mon, 30 Jul 2001 23:27:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkzyz03907
	for ; Mon, 30 Jul 2001 23:26:09 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQkzyz20294
	for ; Mon, 30 Jul 2001 23:26:08 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6UNQ8H35476;
	Mon, 30 Jul 2001 16:26:08 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id QAA24687; Mon, 30 Jul 2001 16:26:08 -0700 (PDT)
Date: Mon, 30 Jul 2001 16:26:08 -0700 (PDT)
From: Kireeti Kompella 
Message-Id: <200107302326.QAA24687@kummer.juniper.net>
To: manojkumarjuneja@hotmail.com, mpls@UU.NET
Subject: Re: Forwarding Adjacency Doubt
In-Reply-To: 
Sender: owner-mpls@UU.NET
Precedence: bulk

Manoj,

>         Is the concept of Forwarding Adjacency (FA) applicable to 
> traditional MPLS or just GMPLS ?

Both.

> If it is applicable to classical MPLS, then what are its applications ?

"Classical MPLS" -- that's funny!

Example application: edge-to-edge LSPs tunneled over a MPLS-TE core.

Kireeti.


From owner-mpls@UU.NET  Tue Jul 31 00:57:00 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 AAA18042
	for ; Tue, 31 Jul 2001 00:56: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 QQkzzv20155;
	Tue, 31 Jul 2001 04:57:33 GMT
Received: by mail-control.mail.uu.net 
	id QQkzzv26917
	for mpls-outgoing; Tue, 31 Jul 2001 04:57: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 QQkzzv26911
	for ; Tue, 31 Jul 2001 04:56:54 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 QQkzzv15435
	for ; Tue, 31 Jul 2001 04:55:55 GMT
Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.236.1.20])
	id QQkzzv01857
	for ; Tue, 31 Jul 2001 04:55:53 GMT
Received: from mrchang (localhost [127.0.0.1])
	by sktelecom.com (8.10.1/8.10.1) with SMTP id f6V51Ba16611
	for ; Tue, 31 Jul 2001 14:01:12 +0900 (KST)
Message-ID: <001301c1197c$aba5e660$86131796@sktelecom.com>
From: "Ray M. Chang" 
To: 
Subject: Journals on MPLS tests
Date: Tue, 31 Jul 2001 13:52:58 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C119C8.1B213800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk


This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C119C8.1B213800
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGVsbG8sIE1QTFMgZ3V5cyENCg0KRG9lcyBhbm9uZSBrbm93IGFueSBqb3VybmFscyBvciBwYXBl
cnMgb24gTVBMUyB0ZXN0cyBvciBzaW11bGF0aW9ucz8NCkl0IHdvdWxkIGJlIGdvb2QgaWYgaXQg
d2VyZSBub3QganVzdCBmb3IgTVBMUyBidXQgZm9yIGdlbmVyYWwgbmV0d29yayBwZXJmb3JtYW5j
ZSB0ZXN0cy4NCldlJ3JlIHRlc3RpbmcgTVBMUyBvbiBvdXIgb3duIHRlc3QtYmVkIGFuZCBzZWVr
IGEgam91cm5hbCB0byBwdWJsaXNoIHRoZSByZXN1bHRzLg0KVGhhbmtzIGZvciB5b3VyIGhlbHAg
aW4gYWR2YW5jZS4NCg0KUmVnYXJkcywNCg0KUmF5Lg0KDQoNCg==

------=_NextPart_000_0010_01C119C8.1B213800
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLCBN
UExTIGd1eXMhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv
RElWPg0KPERJVj48Rk9OVCBzaXplPTI+RG9lcyBhbm9uZSBrbm93IGFueSBqb3VybmFscyBvciBw
YXBlcnMgb24gTVBMUyB0ZXN0cyBvciANCnNpbXVsYXRpb25zPzwvRk9OVD48L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPkl0IHdvdWxkIGJlIGdvb2QgaWYgaXQgd2VyZSBub3QganVzdCBmb3IgTVBM
UyBidXQgZm9yIGdlbmVyYWwgDQpuZXR3b3JrIHBlcmZvcm1hbmNlIHRlc3RzLjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPldlJ3JlJm5ic3A7dGVzdGluZyBNUExTIG9uIG91ciZuYnNw
O293biANCnRlc3QtYmVkJm5ic3A7YW5kJm5ic3A7c2VlayBhIGpvdXJuYWwgdG8gcHVibGlzaCZu
YnNwO3RoZSByZXN1bHRzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rcyBm
b3IgeW91ciBoZWxwIGluIGFkdmFuY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+
PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj5SYXkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv
RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+
DQo=

------=_NextPart_000_0010_01C119C8.1B213800--



From owner-mpls@UU.NET  Tue Jul 31 01:37: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 SMTP id BAA22525
	for ; Tue, 31 Jul 2001 01:37: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 QQkzzy02841;
	Tue, 31 Jul 2001 05:37:47 GMT
Received: by mail-control.mail.uu.net 
	id QQkzzy19430
	for mpls-outgoing; Tue, 31 Jul 2001 05:37: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 QQkzzy19418
	for ; Tue, 31 Jul 2001 05:36:55 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 QQkzzy07722
	for ; Tue, 31 Jul 2001 05:36:14 GMT
Received: from lennier.cc.vt.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lennier.cc.vt.edu [198.82.162.213])
	id QQkzzy00345
	for ; Tue, 31 Jul 2001 05:36:14 GMT
Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id f6V5aCR253997;
	Tue, 31 Jul 2001 01:36:12 -0400 (EDT)
Received: from flaw.vt.edu ([198.82.82.148])
 by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10)
 with ESMTP id <0GHB00KDXOWBBK@gkar.cc.vt.edu>; Tue,
 31 Jul 2001 01:36:11 -0400 (EDT)
Date: Tue, 31 Jul 2001 01:37:49 -0400
From: Raymond Law 
Subject: Re: LSP utilization
In-reply-to: <3B657CB5.10A4268E@cisco.com>
X-Sender: flaw/mail.vt.edu@127.0.0.1
To: raszuk@cisco.com
Cc: mpls@UU.NET
Message-id: <4.3.0.20010731013047.04204100@127.0.0.1>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Content-type: text/plain; format=flowed; charset=us-ascii
References: <4.3.0.20010729224019.05780b40@127.0.0.1>
Sender: owner-mpls@UU.NET
Precedence: bulk

Robert:

If I understand correctly, the new LSP is reserved with the same ingress 
and egress LSR but with different amount of reserved resources such that 
both LSPs combine to match the new bw requirement of the traffic flows.

I can see how the above works if the old LSP needs more bw, then it just 
sets up a new LSP with some more bw to accommodate the traffic (no double 
bw).  What if the old LSP is actually allocated more than enough bw and you 
want to take away some bw from it to give it to other LSPs?  How would you 
set up the new LSP with less bw than the old one?

Is the new LSP set up like a regular LSP or is it set up using the existing 
knowledge of the old LSP so as to lower the overhead associated with 
setting up a whole new LSP.

Can you point me to some more info on this please?

Thanks.
Ray,

At 08:26 AM 7/30/01 -0700, you wrote:

>Raymond,
>
> > bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> > the delay to do so) involved in this solution worth what it provides
> > (better LSP utilization)?
>
>The order is not exactly as you wrote. The old LSP is not being
>destroyed first, but rather a new LSP is being attempted to be created
>using shared explicit rsvp reservation style. If the new reservation
>fails the old tunnel continue to be active if it succeed we build a new
>tunnel (no double bandwith reservation) we switch traffic to a new
>tunnel. After this old is no longer refreshed.
>
>It is automatic with ability to adjust the interface stats collection
>timers as well as the resize interval.
>
>R.
>
> > Raymond Law wrote:
> >
> > I agree the problem that I posed may not be MPLS specific; it applies to
> > ATM circuits as well.  I think this may be more of a TE problem than a MPLS
> > problem.
> >
> > Basically I heard two solutions from the list.  The first solution is to
> > assign a new LSP with the adjusted (measured from the first initial LSP)
> > bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> > the delay to do so) involved in this solution worth what it provides
> > (better LSP utilization)?
> >
> > The second solution is to do load balancing when setting up LSPs.  I agree
> > that load balancing can definitely lead to better utilization of the
> > LSPs.  However, I am more interested in the situation where, after load
> > balancing and setting up LSPs for the FECs, the amount of traffic sent
> > through the LSPs change, resulting in over- and under-utilization of 
> some LSPs.
> >
> > Ray,



From owner-mpls@UU.NET  Tue Jul 31 04:31: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 EAA09802
	for ; Tue, 31 Jul 2001 04:31: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 QQlaak06524;
	Tue, 31 Jul 2001 08:32:08 GMT
Received: by mail-control.mail.uu.net 
	id QQlaak01568
	for mpls-outgoing; Tue, 31 Jul 2001 08:31: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 QQlaak01560
	for ; Tue, 31 Jul 2001 08:31:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlaak04346
	for ; Tue, 31 Jul 2001 08:31:06 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlaak21905
	for ; Tue, 31 Jul 2001 08:31:03 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 13:58:41 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BABF@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'mpls@uu.net'" 
Subject: Re: Usage of object LSP_TUNNEL_INTERFACE_ID
Date: Tue, 31 Jul 2001 13:58:33 +0530
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 Manoj,
> 
> draft-ietf-mpls-rsvp-unnum-01.html
> says
> "
> The LSP_TUNNEL_INTERFACE_ID object has a class number of type 11bbbbbb (to
> be assigned by IANA), C-Type of 1 and length of 12. The format is given
> below. 
>    Figure 1: LSP_TUNNEL_INTERFACE_ID Object
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        LSR's Router ID                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Interface ID (32 bits)                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> This object can optionally appear in either a Path message or a Resv
> message. In the former case, we call it the "Forward Interface ID" for
> that LSP; in the latter case, we call it the "Reverse Interface ID" for
> the LSP"
> 
> However , the class number is yet to be assigned as seen above . Also ,
> this is an extension to support TE lsps on unnumbered links and is an
> extension of rsvp . There is no requirement as of now to mandatorily
> support this object .
> 
> Hope this helps 
> Apratim
> 
> 
> ----------
> From: 	manoj juneja[SMTP:manojkumarjuneja@hotmail.com]
> Sent: 	Tuesday, July 31, 2001 6:58 AM
> To: 	mpls@UU.NET
> Subject: 	Usage of object LSP_TUNNEL_INTERFACE_ID
> 
> Hi All,
>           Can someone please explain me where and how the 
> LSP_TUNNEL_INTERFACE_ID object is used in RSVP-TE ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 


From owner-mpls@UU.NET  Tue Jul 31 04:50: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 EAA10031
	for ; Tue, 31 Jul 2001 04:50: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 QQlaal24543;
	Tue, 31 Jul 2001 08:51:04 GMT
Received: by mail-control.mail.uu.net 
	id QQlaal02946
	for mpls-outgoing; Tue, 31 Jul 2001 08:50: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 QQlaal02938
	for ; Tue, 31 Jul 2001 08:50:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlaal10548
	for ; Tue, 31 Jul 2001 08:46:56 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlaal17466
	for ; Tue, 31 Jul 2001 08:46:53 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 14:14:32 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BAC0@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'mpls@uu.net'" ,
        "'David Charlap'"
	 
Subject: RE: Doubts about MPLS-TE Mib
Date: Tue, 31 Jul 2001 14:14:27 +0530
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 ,

If TunnelId is to distinguish between two sessions having the same egress ,
then TunnelId should have a globally significant value in a MPLS domain ,
i.e. TunnelId cannot be same as TunnelIndex since TunnelIndex has a locally
assigned value (equal to TunnelIndexNextFree when a new tunnel is being
formed ). 
1 ) Doubt here : Where does the TunnelId come from then ? 

2) If TunnelId HAS a globally significant value , then why do we need an
Extended Tunnel Id ?
[ If the administrator wants to tie a tunnel to an Ingress , all he has to
do is to make sure that no other tunnel in the domain has the same
TunnelId.]

If TunnelId is locally assigned at a node , then Extended Tunnel Id MUST be
set to the ingress IP address to be able to distinguish it from some tunnel
being made at another ingress with same tunnel id . ( possible since tunnel
id is being locally decided ) .
 However this means that one tunnel CANNOT have two lsps belonging to the
same tunnel originating at two ingresses and exiting from the same egress . 
3)  Is this an implicit assumption for traffic engineered tunnels in a MPLS
domain ?

Thanks ,
Apratim 



> ----------
> From: 	David Charlap[SMTP:david.charlap@marconi.com]
> Sent: 	Tuesday, July 31, 2001 4:49 AM
> To: 	'mpls@uu.net'
> Subject: 	Re: Doubts about MPLS-TE Mib
> 
> >> You can see both fields at transit nodes: look at the tunnel
> >> entry and the RSVP MIB for that session.
> > 
> > Aha.  That is certainly an answer.
> 
> Unfortunately, there is no RSVP-TE MIB, even in draft form.
> 
> True, you can take the MIB from RFC 2209 and tweak it for the new fields
> used by RSVP-TE, but you necessarily end up with a private MIB, not a
> standard.
> 
> A while back, I asked about an RSVP-TE MIB and was told that it is
> unnecessary because the MPLS TE-MIB presents all the same information. 
> Unfortunately, this turned out not to be true.
> 
> -- David
> 


From owner-mpls@UU.NET  Tue Jul 31 08:26: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 IAA13886
	for ; Tue, 31 Jul 2001 08:26: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 QQlaaz03970;
	Tue, 31 Jul 2001 12:27:19 GMT
Received: by mail-control.mail.uu.net 
	id QQlaaz07801
	for mpls-outgoing; Tue, 31 Jul 2001 12:26: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 QQlaaz07793
	for ; Tue, 31 Jul 2001 12:26: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 QQlaaz27050
	for ; Tue, 31 Jul 2001 12:25:12 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 QQlaaz16246
	for ; Tue, 31 Jul 2001 12:25:12 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA24060 for mpls@uu.net; Tue, 31 Jul 2001 08:25: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 QQlaaz07611
	for ; Tue, 31 Jul 2001 12:24: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 QQlaaz25254
	for ; Tue, 31 Jul 2001 12:24:28 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 QQlaaz28412
	for ; Tue, 31 Jul 2001 12:24:27 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 IAA07348; Tue, 31 Jul 2001 08:24:27 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AFB02397;
	Tue, 31 Jul 2001 08:24:26 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010731082254.020730b0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 31 Jul 2001 08:30:17 -0400
To: "Adrian Farrel" 
From: "Thomas D. Nadeau" 
Subject: Re: Doubts about MPLS-TE Mib
Cc: Cheenu Srinivasan ,
        Arun Viswanathan ,
        "'mpls@uu.net'" 
In-Reply-To: <020901c1193c$63f8b3a0$27de883e@movaz.com>
References: <4.3.2.7.2.20010730101143.026da948@bucket.cisco.com>
 <4.3.2.7.2.20010730160338.028e69b0@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 05:11 PM 7/30/2001 -0400, Adrian Farrel wrote:
>Tom,
>
> > >In the protocol (RSVP) we have
> > >- source address in Sender Template
> > >- extended tunnel id in Session.
> > >
> > >Extended tunnel id may be set to the source address to reduce the 
> scope for
> > >resource sharing between LSPs that might (intentionally or 
> accidentally) have
> > >the same other Session fields.
> >
> >          That is the first that I have ever heard of resource sharing
> > being accomplished that way. This seems haphazard and vendor-specific
> > at best. If you want to share tunnel resources, do so explicitly by
> > having the same tunnel resource entries shared by multiple tunnel
> > entries.
>
>This is a protocol issue that I am exposing.  I'm trying to show 
>(unsuccessfully
>:-) that the two quantities 'source address' and 'extended tunnel id' are
>distinct within the protocol.  From this will follow the need for two separate
>fields in the MIB.
>
>Resources may be shared within the network by LSPs that belong to the same
>session (where the Style is Shared Explicit etc., etc.).  "Ingress nodes that
>wish to narrow the scope of a SESSION to the ingress-egress  pair  may  place
>their  IPv4 address here [Extended Tunnel Id] as a globally unique 
>identifier."
>[draft-ietf-mpls-rsvp-lsp-tunnel-08, 4.6.1.1]

  I stand corrected. After some though and research, I think that
  you are right. I don't believe that anyone that I know of has
  implement this, including the 20 or so implementations of the
  MPLS-TE-MIB that are out there, which is why it never came up.
  Anyway, would you agree that it would suffice to just add another
  object to the tunnel table for the session source address?
  We can specify in the description that the LSR/Operator can then
  pick this field or the LSR ID for the extendedTunnelID according to
  the rules of RSVP. I believe that after either the source addr/extended
  tunnel id are chosen, that a unique RSVP session can be identified
  using the existing indexing, since in the end, sessions will be
  signaled with the four indexes (plus the protocol ID field). Thus,
  the existing indexing of the table does not need to change.

         --Tom






From owner-mpls@UU.NET  Tue Jul 31 08:41: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 IAA14152
	for ; Tue, 31 Jul 2001 08:41:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaba22356;
	Tue, 31 Jul 2001 12:41:37 GMT
Received: by mail-control.mail.uu.net 
	id QQlaba08821
	for mpls-outgoing; Tue, 31 Jul 2001 12:41: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 QQlaba08773
	for ; Tue, 31 Jul 2001 12:40: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 QQlaba02878
	for ; Tue, 31 Jul 2001 12:40: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 QQlaba09141
	for ; Tue, 31 Jul 2001 12:40:29 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA25279 for mpls@uu.net; Tue, 31 Jul 2001 08:40: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 QQlaba08688
	for ; Tue, 31 Jul 2001 12:39:48 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 QQlaba22270
	for ; Tue, 31 Jul 2001 12:38:45 GMT
Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQlaba26859
	for ; Tue, 31 Jul 2001 12:38:44 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VCcr311357;
	Tue, 31 Jul 2001 05:38:53 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f6VCcdr25849;
	Tue, 31 Jul 2001 05:38:39 -0700 (PDT)
Message-ID: <3B66A652.5A8B9FB6@cisco.com>
Date: Tue, 31 Jul 2001 05:36:34 -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: Raymond Law 
CC: mpls@UU.NET
Subject: Re: LSP utilization
References: <4.3.0.20010729224019.05780b40@127.0.0.1> <4.3.0.20010731013047.04204100@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Raymond,

> both LSPs combine to match the new bw requirement of the traffic flows.

No. The new LSP's BW = (old bw +/- delta bw). (Note delta can be
negative :). So when the new LSP is build we as I already indicated stop
refreshing the old one. 

Also notice that at any time there is no double reservation of resourcse
(shared explicit rsvp reservation style is used).

R.

PS. I will send you offline some vendor specific doc ;).

> Raymond Law wrote:
> 
> Robert:
> 
> If I understand correctly, the new LSP is reserved with the same ingress
> and egress LSR but with different amount of reserved resources such that
> both LSPs combine to match the new bw requirement of the traffic flows.
> 
> I can see how the above works if the old LSP needs more bw, then it just
> sets up a new LSP with some more bw to accommodate the traffic (no double
> bw).  What if the old LSP is actually allocated more than enough bw and you
> want to take away some bw from it to give it to other LSPs?  How would you
> set up the new LSP with less bw than the old one?
> 
> Is the new LSP set up like a regular LSP or is it set up using the existing
> knowledge of the old LSP so as to lower the overhead associated with
> setting up a whole new LSP.
> 
> Can you point me to some more info on this please?
> 
> Thanks.
> Ray,
> 
> At 08:26 AM 7/30/01 -0700, you wrote:
> 
> >Raymond,
> >
> > > bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> > > the delay to do so) involved in this solution worth what it provides
> > > (better LSP utilization)?
> >
> >The order is not exactly as you wrote. The old LSP is not being
> >destroyed first, but rather a new LSP is being attempted to be created
> >using shared explicit rsvp reservation style. If the new reservation
> >fails the old tunnel continue to be active if it succeed we build a new
> >tunnel (no double bandwith reservation) we switch traffic to a new
> >tunnel. After this old is no longer refreshed.
> >
> >It is automatic with ability to adjust the interface stats collection
> >timers as well as the resize interval.
> >
> >R.
> >
> > > Raymond Law wrote:
> > >
> > > I agree the problem that I posed may not be MPLS specific; it applies to
> > > ATM circuits as well.  I think this may be more of a TE problem than a MPLS
> > > problem.
> > >
> > > Basically I heard two solutions from the list.  The first solution is to
> > > assign a new LSP with the adjusted (measured from the first initial LSP)
> > > bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> > > the delay to do so) involved in this solution worth what it provides
> > > (better LSP utilization)?
> > >
> > > The second solution is to do load balancing when setting up LSPs.  I agree
> > > that load balancing can definitely lead to better utilization of the
> > > LSPs.  However, I am more interested in the situation where, after load
> > > balancing and setting up LSPs for the FECs, the amount of traffic sent
> > > through the LSPs change, resulting in over- and under-utilization of
> > some LSPs.
> > >
> > > Ray,



From owner-mpls@UU.NET  Tue Jul 31 09:16: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 JAA15239
	for ; Tue, 31 Jul 2001 09:16:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlabd05755;
	Tue, 31 Jul 2001 13:17:20 GMT
Received: by mail-control.mail.uu.net 
	id QQlabd01319
	for mpls-outgoing; Tue, 31 Jul 2001 13:15: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 QQlabd01236
	for ; Tue, 31 Jul 2001 13:15: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 QQlabc00043
	for ; Tue, 31 Jul 2001 13:13:47 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlabc00546
	for ; Tue, 31 Jul 2001 13:13:46 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Tue, 31 Jul 2001 10:13:43 -0300
Message-ID: <3D9C91EAD5D1D411851300508BCF243F02BE20CC@MSTELEFONICA3>
From: Fabris Sergio 
To: mpls@UU.NET
Subject: L-LSP
Date: Tue, 31 Jul 2001 10:13:39 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

What are the extensions needed for RSVP to support L-LSP???
Does L-LSP support 64 classes of services?



From owner-mpls@UU.NET  Tue Jul 31 09:47: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 JAA15815
	for ; Tue, 31 Jul 2001 09:47: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 QQlabf20994;
	Tue, 31 Jul 2001 13:47:14 GMT
Received: by mail-control.mail.uu.net 
	id QQlabf03866
	for mpls-outgoing; Tue, 31 Jul 2001 13:46:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlabf03858
	for ; Tue, 31 Jul 2001 13:46:35 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 QQlabf06655
	for ; Tue, 31 Jul 2001 13:46:28 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQlabf29523
	for ; Tue, 31 Jul 2001 13:46:28 GMT
Message-ID: <3B66B6B2.B0857F02@sandburst.com>
Date: Tue, 31 Jul 2001 09:46:26 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Kireeti Kompella 
Cc: manojkumarjuneja@hotmail.com, mpls@UU.NET, Venkata.Naidu@Marconi.com
Subject: Re: Forwarding Adjacency Doubt
References: <200107302331.QAA24713@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kireeti,

    Yes, GMPLS seems certain to be a super-set of MPLS.  However it may be
unlikely that anyone will ever implement this super-set for PPP, Ethernet,
FR or ATM given that it seems that MPLS is sufficient for these - at least
at present.

    Also, my understanding of the intent of GMPLS is that it is focused
somewhat on signaling for transport of IP packets, so I am not too sure
what you mean by 'non-packet LSPs'.

--
Eric Gray

You wrote:

> > traditional MPLS or just GMPLS ?
>
> BTW, a correction in perception: GMPLS *includes* traditional/classical
> MPLS.  GMPLS is *not* restricted to non-packet LSPs!
>
> Kireeti.



From owner-mpls@UU.NET  Tue Jul 31 10:01:16 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 KAA16226
	for ; Tue, 31 Jul 2001 10:01:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlabg10102;
	Tue, 31 Jul 2001 14:01:48 GMT
Received: by mail-control.mail.uu.net 
	id QQlabg09551
	for mpls-outgoing; Tue, 31 Jul 2001 14:01: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 QQlabg09160
	for ; Tue, 31 Jul 2001 14:01:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlabg09723
	for ; Tue, 31 Jul 2001 14:00:37 GMT
Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host2.tbg.com [63.99.125.2] (may be forged))
	id QQlabg10927
	for ; Tue, 31 Jul 2001 14:00:37 GMT
Received: by host2.tbg.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 31 Jul 2001 07:58:20 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE7025A5961@host2.tbg.com>
From: Irwin Lazar 
To: "'Ray M. Chang'" 
Cc: "'mpls@uu.net'" 
Subject: RE: Journals on MPLS tests
Date: Tue, 31 Jul 2001 07:58:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C119C8.DA9673B2"
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_01C119C8.DA9673B2
Content-Type: text/plain;
	charset="KS_C_5601-1987"

We've posted a few on the "articles & papers" page of the MPLS Resource
Center - www.mplsrc.com  
 
Irwin

-----Original Message-----
From: Ray M. Chang [mailto:cmr@sktelecom.com]
Sent: Tuesday, July 31, 2001 12:53 AM
To: mpls@UU.NET
Subject: Journals on MPLS tests


Hello, MPLS guys!
 
Does anone know any journals or papers on MPLS tests or simulations?
It would be good if it were not just for MPLS but for general network
performance tests.
We're testing MPLS on our own test-bed and seek a journal to publish the
results.
Thanks for your help in advance.
 
Regards,
 
Ray.
 
 


------_=_NextPart_001_01C119C8.DA9673B2
Content-Type: text/html;
	charset="KS_C_5601-1987"











We've 
posted a few on the "articles & papers" page of the MPLS Resource Center - 
www.mplsrc.com


 


Irwin



  
-----Original Message-----
From: Ray M. Chang 
  [mailto:cmr@sktelecom.com]
Sent: Tuesday, July 31, 2001 12:53 
  AM
To: mpls@UU.NET
Subject: Journals on MPLS 
  tests


  
Hello, MPLS guys!

  
 

  
Does anone know any journals or papers on MPLS tests or 
  simulations?

  
It would be good if it were not just for MPLS but for 
  general network performance tests.

  
We're testing MPLS on our own 
  test-bed and seek a journal to publish the 
results.

  
Thanks for your help in advance.

  
 

  
Regards,

  
 

  
Ray.

  
 

  
 


------_=_NextPart_001_01C119C8.DA9673B2--


From owner-mpls@UU.NET  Tue Jul 31 10: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 KAA17344
	for ; Tue, 31 Jul 2001 10:20: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 QQlabh10651;
	Tue, 31 Jul 2001 14:21:14 GMT
Received: by mail-control.mail.uu.net 
	id QQlabh26376
	for mpls-outgoing; Tue, 31 Jul 2001 14: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 QQlabh26357
	for ; Tue, 31 Jul 2001 14:20:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlabh02522
	for ; Tue, 31 Jul 2001 14:16:59 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlabh14254
	for ; Tue, 31 Jul 2001 14:16:59 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 KAA12278
	for ; Tue, 31 Jul 2001 10:16: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 KAA19609
	for ; Tue, 31 Jul 2001 10:16:59 -0400 (EDT)
Message-ID: <3B66BDD9.A284DDBF@marconi.com>
Date: Tue, 31 Jul 2001 10:16:57 -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: Doubts about MPLS-TE Mib
References: <13D467F625FAD511AE2A00D0B7B917D706BAC0@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Apratim Mukherjee wrote:
> 
> If TunnelId is to distinguish between two sessions having the same
> egress, then TunnelId should have a globally significant value in a
> MPLS domain

And how do you propose to do this?  Require a global server that can
dish out unique tunnel IDs, perhaps?  Requiring that tunnel ID be
globally unique is not possible without adding so much overhead that
nobody will use it.

In RSVP-TE, _ALL_ of the values in a session object (Address, tunnel ID
and extended tunnel ID) are required to uniquely specify a session. 
Extended tunnel ID is required because there is no reasonable way to
ensure uniqueness of the tunnel ID field.

The only reason CR-LDP doesn't also have this problem is because CR-LDP
incorporates the sender address as part of the LSP ID.

> 1 ) Doubt here : Where does the TunnelId come from then ?

Tunnel ID is only locally unique to the ingress node.

> 2) If TunnelId HAS a globally significant value , then why do we
> need an Extended Tunnel Id ?

Your assumption is wrong.  It is not globally significant.  The extended
tunnel ID is required to make the entire session object globally unique.

You can't just blindly assume that extended tunnel ID will match the
sender address, because a zero value (meaning "don't care", needed for
sharing resources between two LSPs from different senders) is legal.

> [ If the administrator wants to tie a tunnel to an Ingress , all he
> has to do is to make sure that no other tunnel in the domain has
> the same TunnelId.]

Easier said than done.  The only way an administrator can guarantee this
is if every single LSP in the network is manually configured.  This is
not always going to be true.

> If TunnelId is locally assigned at a node , then Extended Tunnel Id
> MUST be set to the ingress IP address to be able to distinguish it
> from some tunnel being made at another ingress with same tunnel id.

Unless it is intended that this LSP will share resources with another
LSP terminating on the same node.

> ( possible since tunnel id is being locally decided ).
> However this means that one tunnel CANNOT have two lsps belonging
> to the same tunnel originating at two ingresses and exiting from
> the same egress.

There is no reason why you can not have this.  That is specifically what
the zero value for extended tunnel ID is meant for.

-- David


From owner-mpls@UU.NET  Tue Jul 31 10:28: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 SMTP id KAA17742
	for ; Tue, 31 Jul 2001 10:28: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 QQlabh17731;
	Tue, 31 Jul 2001 14:28:19 GMT
Received: by mail-control.mail.uu.net 
	id QQlabh26903
	for mpls-outgoing; Tue, 31 Jul 2001 14:27: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 QQlabh26893
	for ; Tue, 31 Jul 2001 14:27: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 QQlabh02430
	for ; Tue, 31 Jul 2001 14:25:13 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 QQlabh17013
	for ; Tue, 31 Jul 2001 14:25:13 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13522
	for ; Tue, 31 Jul 2001 10:25:11 -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 KAA22341
	for ; Tue, 31 Jul 2001 10:25:12 -0400 (EDT)
Message-ID: <3B66BFC7.14EB5371@marconi.com>
Date: Tue, 31 Jul 2001 10:25:11 -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: LSP utilization
References: <4.3.0.20010729224019.05780b40@127.0.0.1> <4.3.0.20010731013047.04204100@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Raymond Law wrote:
> 
> If I understand correctly, the new LSP is reserved with the same
> ingress and egress LSR but with different amount of reserved
> resources such that both LSPs combine to match the new bw
> requirement of the traffic flows.

That's not the way SE-style reservations work.

With SE style reservation, all senders (ie all LSPs) in a single session
always have identical resource reservations.  When the egress sends out
a Resv for the second LSP with different resources, the routers will
change the reservation for the first LSP as well.  If the two LSPs have
divergent paths, Resv messages will be sent along both paths, in order
to keep the two LSPs in sync.

> I can see how the above works if the old LSP needs more bw, then
> it just sets up a new LSP with some more bw to accommodate the
> traffic (no double bw).  What if the old LSP is actually allocated
> more than enough bw and you want to take away some bw from it to
> give it to other LSPs?  How would you set up the new LSP with less
> bw than the old one?

Same as before.  Use make-before-break.  Create a new LSP in the same
session.  The egress sends back an SE-style Resv message for both LSPs
with the new amount of resources.  All the transit routers update their
reservations.  When the Resv hits the ingress, it can shunt traffic onto
the new LSP, and signal a teardown for the old one.

> Is the new LSP set up like a regular LSP or is it set up using the
> existing knowledge of the old LSP so as to lower the overhead
> associated with setting up a whole new LSP.

There is no real difference here.  If the new and old ones have features
in common, the ingress can choose to reuse what it knows.  Or it can
choose not to.  This is an implementation issue.  Either way, the Path
message leaving the router will be the same.

-- David


From owner-mpls@UU.NET  Tue Jul 31 11:35: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 LAA21769
	for ; Tue, 31 Jul 2001 11:35: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 QQlabm11050;
	Tue, 31 Jul 2001 15:34:45 GMT
Received: by mail-control.mail.uu.net 
	id QQlabm21728
	for mpls-outgoing; Tue, 31 Jul 2001 15:34: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 QQlabm21718
	for ; Tue, 31 Jul 2001 15:34:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlabm02926
	for ; Tue, 31 Jul 2001 15:32:55 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlabm05453
	for ; Tue, 31 Jul 2001 15:32:48 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 21:00:21 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BAC2@mailserver.netbrahma.com>
From: Apratim Mukherjee 
To: "'mpls@uu.net'" ,
        "'David Charlap'"
	 
Subject: RE: Doubts about MPLS-TE Mib
Date: Tue, 31 Jul 2001 21:00:19 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi David,

So its now clear that TunnelId has a local significance only . Also Extended
Tunnel Id can be 0 if the intention is to have multiple ingresses to a
tunnel.

I1 -----------|
              I
 	  |-----------LSR--------------------------------- E
	  |
I2 -----------|

Say that a tunnel is created from I1 to E with Extended Tunnel Id 0.
Also , a DIFFERENT tunnel has to be created between I2 to E with Extended
Tunnel Id . (i.e. both the tunnels have other ingress points besides I1 and
I2).
Also assume that that the SE desired flag is on.

Now at the LSR , the session object for the path messages MAY be same since
Tunnel Ids are locally assigned . That is 
(EgressIP in Path Message from I1 =EgressIp in Path Message from I2 = E ,
TunnelId in Path Message from I1 =TunnelId in Path Message from I2 = x ,
ExtendedTunnelId in Path Message from I1 =ExtendedTunnelId in Path Message
from I2 = 0) 
Hence , the two SESSIONs will get MERGED at the LSR , i.e , the path states
corresponding to the two path messages will be in the SAME session .
This results in unwanted behaviour e.g. if styles are different , then
second path message will be dropped or reservations can get merged for the
two different styles is style is SE for both .
 How can this be prevented if TunnelId has a local significance and the same
tunnelId could be generated at two ingresses for different tunnels ?

I feel that if TunnelId has a local significance , then it must be mandatory
for ExtendedTunnelId to contain the Ip address and multipoint to point
tunnels should not be allowed . Or am i missing something here ?

Thanks
Apratim


> ----------
> From: 	David Charlap[SMTP:david.charlap@marconi.com]
> Sent: 	Tuesday, July 31, 2001 7:46 PM
> To: 	'mpls@uu.net'
> Subject: 	Re: Doubts about MPLS-TE Mib
> 
> Apratim Mukherjee wrote:
> > 
> > If TunnelId is to distinguish between two sessions having the same
> > egress, then TunnelId should have a globally significant value in a
> > MPLS domain
> 
> And how do you propose to do this?  Require a global server that can
> dish out unique tunnel IDs, perhaps?  Requiring that tunnel ID be
> globally unique is not possible without adding so much overhead that
> nobody will use it.
> 
> In RSVP-TE, _ALL_ of the values in a session object (Address, tunnel ID
> and extended tunnel ID) are required to uniquely specify a session. 
> Extended tunnel ID is required because there is no reasonable way to
> ensure uniqueness of the tunnel ID field.
> 
> The only reason CR-LDP doesn't also have this problem is because CR-LDP
> incorporates the sender address as part of the LSP ID.
> 
> > 1 ) Doubt here : Where does the TunnelId come from then ?
> 
> Tunnel ID is only locally unique to the ingress node.
> 
> > 2) If TunnelId HAS a globally significant value , then why do we
> > need an Extended Tunnel Id ?
> 
> Your assumption is wrong.  It is not globally significant.  The extended
> tunnel ID is required to make the entire session object globally unique.
> 
> You can't just blindly assume that extended tunnel ID will match the
> sender address, because a zero value (meaning "don't care", needed for
> sharing resources between two LSPs from different senders) is legal.
> 
> > [ If the administrator wants to tie a tunnel to an Ingress , all he
> > has to do is to make sure that no other tunnel in the domain has
> > the same TunnelId.]
> 
> Easier said than done.  The only way an administrator can guarantee this
> is if every single LSP in the network is manually configured.  This is
> not always going to be true.
> 
> > If TunnelId is locally assigned at a node , then Extended Tunnel Id
> > MUST be set to the ingress IP address to be able to distinguish it
> > from some tunnel being made at another ingress with same tunnel id.
> 
> Unless it is intended that this LSP will share resources with another
> LSP terminating on the same node.
> 
> > ( possible since tunnel id is being locally decided ).
> > However this means that one tunnel CANNOT have two lsps belonging
> > to the same tunnel originating at two ingresses and exiting from
> > the same egress.
> 
> There is no reason why you can not have this.  That is specifically what
> the zero value for extended tunnel ID is meant for.
> 
> -- David
> 


From owner-mpls@UU.NET  Tue Jul 31 12: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 MAA23291
	for ; Tue, 31 Jul 2001 12:04: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 QQlabo08902;
	Tue, 31 Jul 2001 16:03:32 GMT
Received: by mail-control.mail.uu.net 
	id QQlabo02276
	for mpls-outgoing; Tue, 31 Jul 2001 16:03: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 QQlabo01819
	for ; Tue, 31 Jul 2001 16:02: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 QQlabo08119
	for ; Tue, 31 Jul 2001 16:01:31 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 QQlabo26600
	for ; Tue, 31 Jul 2001 16:01: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 MAA28787
	for ; Tue, 31 Jul 2001 12:01:29 -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 MAA22397
	for ; Tue, 31 Jul 2001 12:01:31 -0400 (EDT)
Message-ID: <3B66D659.FF4A665F@marconi.com>
Date: Tue, 31 Jul 2001 12:01: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@uu.net'" 
Subject: Re: Doubts about MPLS-TE Mib
References: <13D467F625FAD511AE2A00D0B7B917D706BAC2@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Apratim Mukherjee wrote:
> 
> So its now clear that TunnelId has a local significance only . Also
> Extended Tunnel Id can be 0 if the intention is to have multiple
> ingresses to a tunnel.

Correct.  Keeping in mind that "tunnel" in this context is using the
RSVP definition of multiple LSPs that share a common session.  Which is
not the definition used by other MPLS documents.

> I1 -----------|
>               I
>               |-----------LSR--------------------------------- E
>               |
> I2 -----------|
> 
> Say that a tunnel is created from I1 to E with Extended Tunnel Id
> 0.  Also , a DIFFERENT tunnel has to be created between I2 to E
> with Extended Tunnel Id . (i.e. both the tunnels have other ingress
> points besides I1 and I2).  Also assume that that the SE desired
> flag is on.

Are both using extended tunnel ID of 0?  Your text isn't clear on that. 
If one uses 0, and the other uses its IP address, then the two LSPs are
in different sessions and are independant from one another.

The rest of your text reads as if you meant to say that both use
extended tunnel ID of 0, which is what I'll assume from here on.

> Now at the LSR , the session object for the path messages MAY be
> same since Tunnel Ids are locally assigned . That is (EgressIP in
> Path Message from I1 =EgressIp in Path Message from I2 = E,
> TunnelId in Path Message from I1 =TunnelId in Path Message from
> I2 = x , ExtendedTunnelId in Path Message from I1 =ExtendedTunnelId
> in Path Message from I2 = 0)
> Hence , the two SESSIONs will get MERGED at the LSR , i.e , the
> path states corresponding to the two path messages will be in the
> SAME session.  This results in unwanted behaviour e.g. if styles
> are different , then second path message will be dropped or
> reservations can get merged for the two different styles is style
> is SE for both .

If both I1 and I2 independantly choose their tunnel ID, then this can
definitely happen.  The two will end up sharing resources.  If this is
unacceptible, then they shouldn't use zero for extended tunnel ID.

Style conflict is not an issue.  It is the egress (E) which chooses the
style.  If it chooses SE for one LSP, it will have to use SE for all
other LSPs in the session.  If it chooses FF, then it will have to do so
for all LSPs in the session.

Note that the "SE requested" flag is advisory.  The egress router is
free to ignore it.  If one LSP is requesting SE style and one is not,
there is no inherent conflict.  The egress router will simply ignore one
or the other.

> How can this be prevented if TunnelId has a local significance and
> the same tunnelId could be generated at two ingresses for different
> tunnels ?

Presumably, the decision to use zero for an extended tunnel ID would be
deliberate, for the explicit purpose of sharing resources between LSPs. 
It would be bordering on madness to make the zero value a router's
default (or only) behavior!

Since no operator would want LSPs randomly sharing resources with each
other, he would obviously want to take steps to ensure that two LSPs
will only use the same tunnel ID when they are intended to share
resources with each other, and at no other time.  This may be via manual
configuration of the ingress routers or through some out of band
management tool.

The operator would also have enough common sense to use a non-zero
extended tunnel ID for all LSPs that should not be sharing their
resources with anyone else.

> I feel that if TunnelId has a local significance , then it must be
> mandatory for ExtendedTunnelId to contain the Ip address and
> multipoint to point tunnels should not be allowed . Or am i missing
> something here ?

Your claim of "mandatory" implies that you also want to forbid resource
sharing between LSPs from different ingress routers.  I am saying that
this sharing can be a desirable feature, if properly managed.

Note that "local significance" for tunnel ID does not imply "randomly
generated".  And it does not preclude the use of some mechanism beyond
the scope of the signaling protocol for keeping them organizzed.  The
use of an extended tunnel ID of zero does not mandate random haphazard
sharing of all resources in the network!

-- David


From owner-mpls@UU.NET  Tue Jul 31 12:35: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 MAA25345
	for ; Tue, 31 Jul 2001 12:35: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 QQlabq14464;
	Tue, 31 Jul 2001 16:35:40 GMT
Received: by mail-control.mail.uu.net 
	id QQlabq16569
	for mpls-outgoing; Tue, 31 Jul 2001 16:35: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 QQlabq16548
	for ; Tue, 31 Jul 2001 16:34:50 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 QQlabq20966
	for ; Tue, 31 Jul 2001 16:34:31 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 QQlabq00930
	for ; Tue, 31 Jul 2001 16:34:31 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA07283 for ; Tue, 31 Jul 2001 12:34:30 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA14223 for mpls@uu.net; Tue, 31 Jul 2001 12:34: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 QQlabp15183
	for ; Tue, 31 Jul 2001 16:15: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 QQlabp08549
	for ; Tue, 31 Jul 2001 16:15:35 GMT
Received: from stephens.ittc.ku.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: stephens.ittc.ku.edu [129.237.125.220])
	id QQlabp20513
	for ; Tue, 31 Jul 2001 16:15:35 GMT
Received: from astro.ittc.ku.edu (astro.ittc.ku.edu [129.237.126.119])
	by stephens.ittc.ku.edu (8.11.2/8.11.2/ITTC-NOSPAM-NOVIRUS-2.2) with ESMTP id f6VGFYV26574;
	Tue, 31 Jul 2001 11:15:34 -0500
Received: from localhost by astro.ittc.ku.edu (8.9.3/KU-4.0-client)
	id LAA04414; Tue, 31 Jul 2001 11:15:32 -0500
Date: Tue, 31 Jul 2001 11:15:32 -0500 (CDT)
From: Rameshbabu Prabagaran 
To: fabriss@TELEFONICA.COM.AR
cc: mpls@UU.NET
Subject: Re: L-LSP
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Fabris,

> What are the extensions needed for RSVP to support
> L-LSP???
> Does L-LSP support 64 classes of services?


Most of the information that you'll need is under
section 5 of draft-ietf-mpls-diff-ext-09.txt

http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.txt

Thanks
Ramesh.



From owner-mpls@UU.NET  Tue Jul 31 14:37: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 OAA07139
	for ; Tue, 31 Jul 2001 14:37:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaby25154;
	Tue, 31 Jul 2001 18:38:15 GMT
Received: by mail-control.mail.uu.net 
	id QQlaby06215
	for mpls-outgoing; Tue, 31 Jul 2001 18:37: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 QQlaby06207
	for ; Tue, 31 Jul 2001 18:37: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 QQlabx15744
	for ; Tue, 31 Jul 2001 18:29:17 GMT
Received: from ganymede.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns01.or.intel.com [134.134.248.3])
	id QQlabx29365
	for ; Tue, 31 Jul 2001 18:29:17 GMT
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA11033
	for ; Tue, 31 Jul 2001 18:29:16 GMT
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 31 Jul 2001 18:29:16 0000 (GMT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 11:29:14 -0700
Message-ID: 
From: "Feng, Mark" 
To: "'mpls@uu.net'" 
Subject: RE: Doubts about MPLS-TE Mib
Date: Tue, 31 Jul 2001 11:28:13 -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

I am not sure I understand the message here. 

IMO, tunnel Id has "global" significance, within some particular MPLS
domain, synonym to well-known ports in classical RSVP. I think that it is
unlikely the operator will assign a LSP some tunnel Id without knowing what
other potential ingress routers might share the resources. Also, the fact
that the egress router is the one who decides what style to use implies that
some out-of-band mechanism is used to ensure the proper operation between
the ingress routers and the egress routers.

The only reason I can think of to have the tunnel Id and extended tunnel Id
is to tailor different needs. For example, there might be some
pre-determined mechanism to assign the tunnel Id at each ingress router. If
one router decides not to join the sharing, though it is assinged a
particular tunnel Id, it can add its own IP in the extended tunnel Id, to
exclude itself in the sharing.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 31, 2001 9:01 AM
> To: 'mpls@uu.net'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> Apratim Mukherjee wrote:
> > 
> > So its now clear that TunnelId has a local significance only . Also
> > Extended Tunnel Id can be 0 if the intention is to have multiple
> > ingresses to a tunnel.
> 
> Correct.  Keeping in mind that "tunnel" in this context is using the
> RSVP definition of multiple LSPs that share a common session. 
>  Which is
> not the definition used by other MPLS documents.
> 
> > I1 -----------|
> >               I
> >               |-----------LSR--------------------------------- E
> >               |
> > I2 -----------|
> > 
> > Say that a tunnel is created from I1 to E with Extended Tunnel Id
> > 0.  Also , a DIFFERENT tunnel has to be created between I2 to E
> > with Extended Tunnel Id . (i.e. both the tunnels have other ingress
> > points besides I1 and I2).  Also assume that that the SE desired
> > flag is on.
> 
> Are both using extended tunnel ID of 0?  Your text isn't 
> clear on that. 
> If one uses 0, and the other uses its IP address, then the 
> two LSPs are
> in different sessions and are independant from one another.
> 
> The rest of your text reads as if you meant to say that both use
> extended tunnel ID of 0, which is what I'll assume from here on.
> 
> > Now at the LSR , the session object for the path messages MAY be
> > same since Tunnel Ids are locally assigned . That is (EgressIP in
> > Path Message from I1 =EgressIp in Path Message from I2 = E,
> > TunnelId in Path Message from I1 =TunnelId in Path Message from
> > I2 = x , ExtendedTunnelId in Path Message from I1 =ExtendedTunnelId
> > in Path Message from I2 = 0)
> > Hence , the two SESSIONs will get MERGED at the LSR , i.e , the
> > path states corresponding to the two path messages will be in the
> > SAME session.  This results in unwanted behaviour e.g. if styles
> > are different , then second path message will be dropped or
> > reservations can get merged for the two different styles is style
> > is SE for both .
> 
> If both I1 and I2 independantly choose their tunnel ID, then this can
> definitely happen.  The two will end up sharing resources.  If this is
> unacceptible, then they shouldn't use zero for extended tunnel ID.
> 
> Style conflict is not an issue.  It is the egress (E) which 
> chooses the
> style.  If it chooses SE for one LSP, it will have to use SE for all
> other LSPs in the session.  If it chooses FF, then it will 
> have to do so
> for all LSPs in the session.
> 
> Note that the "SE requested" flag is advisory.  The egress router is
> free to ignore it.  If one LSP is requesting SE style and one is not,
> there is no inherent conflict.  The egress router will simply 
> ignore one
> or the other.
> 
> > How can this be prevented if TunnelId has a local significance and
> > the same tunnelId could be generated at two ingresses for different
> > tunnels ?
> 
> Presumably, the decision to use zero for an extended tunnel 
> ID would be
> deliberate, for the explicit purpose of sharing resources 
> between LSPs. 
> It would be bordering on madness to make the zero value a router's
> default (or only) behavior!
> 
> Since no operator would want LSPs randomly sharing resources with each
> other, he would obviously want to take steps to ensure that two LSPs
> will only use the same tunnel ID when they are intended to share
> resources with each other, and at no other time.  This may be 
> via manual
> configuration of the ingress routers or through some out of band
> management tool.
> 
> The operator would also have enough common sense to use a non-zero
> extended tunnel ID for all LSPs that should not be sharing their
> resources with anyone else.
> 
> > I feel that if TunnelId has a local significance , then it must be
> > mandatory for ExtendedTunnelId to contain the Ip address and
> > multipoint to point tunnels should not be allowed . Or am i missing
> > something here ?
> 
> Your claim of "mandatory" implies that you also want to 
> forbid resource
> sharing between LSPs from different ingress routers.  I am saying that
> this sharing can be a desirable feature, if properly managed.
> 
> Note that "local significance" for tunnel ID does not imply "randomly
> generated".  And it does not preclude the use of some mechanism beyond
> the scope of the signaling protocol for keeping them organizzed.  The
> use of an extended tunnel ID of zero does not mandate random haphazard
> sharing of all resources in the network!
> 
> -- David
> 



From owner-mpls@UU.NET  Tue Jul 31 14:47: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 OAA08388
	for ; Tue, 31 Jul 2001 14:47: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 QQlabz18006;
	Tue, 31 Jul 2001 18:47:16 GMT
Received: by mail-control.mail.uu.net 
	id QQlabz07016
	for mpls-outgoing; Tue, 31 Jul 2001 18:46: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 QQlabz06977
	for ; Tue, 31 Jul 2001 18: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 QQlaby11737
	for ; Tue, 31 Jul 2001 18:41:38 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlaby01366
	for ; Tue, 31 Jul 2001 18:41:37 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Tue, 31 Jul 2001 15:39:13 -0300
Message-ID: <3D9C91EAD5D1D411851300508BCF243F02BE2410@MSTELEFONICA3>
From: Fabris Sergio 
To: mpls@UU.NET
Subject: classification
Date: Tue, 31 Jul 2001 15:39:08 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Traffic Engineering:

..........A standard IP packet arrives at Interface 1 of LSR 1. After
performing a longest-match
lookup in its IP routing table, LSR 1 discovers that the best match is with
Prefix X and that
all traffic matching Prefix X should to be forwarded on Interface 2 with a
Label = 10.............

How LSR1 discover that the best match is whit that Prefix X?? 
Does It made same classification based on source address??

Thanks.

Sergio


From owner-mpls@UU.NET  Tue Jul 31 15:22: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 PAA12897
	for ; Tue, 31 Jul 2001 15:22: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 QQlacb10597;
	Tue, 31 Jul 2001 19:23:23 GMT
Received: by mail-control.mail.uu.net 
	id QQlacb29778
	for mpls-outgoing; Tue, 31 Jul 2001 19:23: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 QQlacb29496
	for ; Tue, 31 Jul 2001 19:20:58 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlaca25321
	for ; Tue, 31 Jul 2001 19:04: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 QQlaca09682
	for ; Tue, 31 Jul 2001 19:04:07 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA26718 for mpls@uu.net; Tue, 31 Jul 2001 15:04: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 QQlaca18810
	for ; Tue, 31 Jul 2001 19:03: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 QQlabz21632
	for ; Tue, 31 Jul 2001 18:55:30 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 QQlabz24619
	for ; Tue, 31 Jul 2001 18:55:29 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 OAA27842; Tue, 31 Jul 2001 14:55:29 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AFB08677;
	Tue, 31 Jul 2001 14:55:28 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010731144213.022d2880@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 31 Jul 2001 15:01:25 -0400
To: manasa@gettos.com, mpls@UU.NET
From: "Thomas D. Nadeau" 
Subject: Re: TE-MIB
In-Reply-To: <20010731175844.6283F36F9@sitemail.everyone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>The mplsTunnelARHopTable of TE-MIB does give you
>the actual hops traversed by the tunnel in one
>direction.  But, if the LSP is a bi-directional one
>how would we get/record the actual hops traversed in
>the other direction?

         Boy, it is good to see all of this interest
in the MPLS-TE-MIB these days. Gives me the
impression that a lot of folks are implementing
it. 8)

         Bi-directional tunnels are not supported
in the MIB as they were not standardized in MPLS.
They are in GMPLS however, and will be covered
in the GMPLS-TE-MIB.

         --Tom





From owner-mpls@UU.NET  Tue Jul 31 15:43: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 PAA15217
	for ; Tue, 31 Jul 2001 15:43:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlacb02812;
	Tue, 31 Jul 2001 19:18:46 GMT
Received: by mail-control.mail.uu.net 
	id QQlacb29157
	for mpls-outgoing; Tue, 31 Jul 2001 19: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 QQlacb29144
	for ; Tue, 31 Jul 2001 19:17:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlabz05932
	for ; Tue, 31 Jul 2001 18:59:41 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlabz02150
	for ; Tue, 31 Jul 2001 18:59:41 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Tue, 31 Jul 2001 15:59:36 -0300
Message-ID: <49BB9783DE7FD411A29D00508B6F0AD804D44328@MSTELEFONICA1>
From: Zappacosta Rolando Jorge 
To: "'Mooney Sherman'" ,
        "'Christian Kuhtz'"
	 ,
        Fabris Sergio 
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Tue, 31 Jul 2001 15:59:32 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I totally agree. Even the test equipment manufacturers are working on that,
and in fact they have something available on the market.
But as implied before, it just an "agreement" between the customer and the
providers, or in a more general way, between two parties, and of course is
something not standardized.
Regards,
Rolando.

> -----Mensaje original-----
> De:	Mooney Sherman [SMTP:Mooney.Sherman@gov.ab.ca]
> Enviado el:	Viernes 27 de Julio de 2001 18:00
> Para:	'Christian Kuhtz'; Fabris Sergio
> CC:	mpls@UU.NET
> Asunto:	RE: SLA
> 
> I agree with some of your comments . It can be a marketing tool (gimmick?)
> but normally a client has certain expectations or need - such as a certain
> level of bandwidth requirement for the acceptable performance by an
> application - say video streaming. So the Telco guarantees a certain
> bandwidth that is acceptable or perhaps a maximum downtime in the form of
> SLA. SLA is simply an agreement that a vendor or supplier can and will
> deliver to a client. It can also be used in the context of an application
> i.e. an application can process/ redirect at least Xnumber of tags for
> instance in MPLS. Then this would be the SLA for it.
> 
> -----Original Message-----
> From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
> Sent: Friday, July 27, 2001 2:45 PM
> To: Fabris Sergio
> Cc: mpls@UU.NET
> Subject: Re: SLA
> 
> 
> 
> On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> > Is SLA (Service Level Agreement) a term for DiffServ networks only?
> > Can it be used in an MPLS network?
> 
> Sergio,
> 
> You can define an SLA for literally anything, including the performance of
> your dry cleaner.  
> 
> And an MPLS network can be a 'DiffServ network'; I presume you intend to 
> describe a network in which differentiated services of some kind are 
> offered...
> 
> SLA per se has nothing to do with differentiated services, other than that
> 
> differentiated services with methods and tools as proposed by IETF
> DiffServ 
> can be used to provide a service as described by an SLA.  Note also that
> many 
> SLAs actually have little to do with a direct link to the technology
> underneath; it is possible that the service you purchase w/ SLA is
> identical
> 
> to the service you purchase w/out SLA, or the service w/ SLA may be very 
> different than the one w/out SLA.  An SLA can be a marketing gimmick,  a 
> financial tool, a technology constraint, or any combination of the above.
> 
> The term SLA is a very much abused term, often driven more by marketecture
> and
> marketeering than technology.  And then there's the set of issues around
> SLA's 
> with teeth..
> 
> But, I'm rambling..  What specifically are you looking for?
> 
> Cheers,
> Chris
> 
> -- 
> Christian Kuhtz  -wk,  -hm
> Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA,
> U.S.
> "I speak for myself only.""


From owner-mpls@UU.NET  Tue Jul 31 15:53: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 PAA16122
	for ; Tue, 31 Jul 2001 15:53: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 QQlabz26315;
	Tue, 31 Jul 2001 18:52:30 GMT
Received: by mail-control.mail.uu.net 
	id QQlabz07340
	for mpls-outgoing; Tue, 31 Jul 2001 18:51: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 QQlabz07325
	for ; Tue, 31 Jul 2001 18:51:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlaby13184
	for ; Tue, 31 Jul 2001 18:41:33 GMT
Received: from gatekeeper.cam.virata.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gatekeeper.virata.com [194.129.40.2])
	id QQlaby12281
	for ; Tue, 31 Jul 2001 18:41:33 GMT
Received: from boletus.cam.virata.com (boletus.cam.virata.com [10.7.5.11])
	by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id TAA00609;
	Tue, 31 Jul 2001 19:41:25 +0100
Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.65.0.254])
	by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA19696;
	Tue, 31 Jul 2001 19:41:23 +0100
Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 31 Jul 2001 20:39:41 +0200
Message-ID: 
From: "Lipovetsky, Sergey" 
To: "'David Charlap'" 
Cc: "'mpls@uu.net'" 
Subject: RE: Doubts about MPLS-TE Mib
Date: Tue, 31 Jul 2001 20:39:35 +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 David,

Thank you for your clarification of RSVP details. It always helps a lot.

Here are comments on this thread.
RFC2205 states "RSVP defines a "session" to be a data flow with a particular
destination and transport-layer protocol." My understanding is that it is
not different for RSVP-TE and a session object relates to the destination.
TunnelId is a part of the session object and probably also relates to the
destination. If this is true TunnelId should be locally unique to the egress
node and a pair [egress address, TunnelId] should uniquely identify an RSVP
session.

However, there is a problem with TunnelId allocation on the ingress node in
this case.

The requirements to set Extended tunnel ID to a non-zero value to guarantee
session uniqueness, when TunnelId is allocated by the ingress node prevents
from merging LSPs having the same egress node but different ingress nodes.
What is wrong here?

Thanks,
Sergey

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 31, 2001 4:17 PM
> To: 'mpls@uu.net'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> Apratim Mukherjee wrote:
> > 
> > If TunnelId is to distinguish between two sessions having the same
> > egress, then TunnelId should have a globally significant value in a
> > MPLS domain
> 
> And how do you propose to do this?  Require a global server that can
> dish out unique tunnel IDs, perhaps?  Requiring that tunnel ID be
> globally unique is not possible without adding so much overhead that
> nobody will use it.
> 
> In RSVP-TE, _ALL_ of the values in a session object (Address, 
> tunnel ID
> and extended tunnel ID) are required to uniquely specify a session. 
> Extended tunnel ID is required because there is no reasonable way to
> ensure uniqueness of the tunnel ID field.
> 
> The only reason CR-LDP doesn't also have this problem is 
> because CR-LDP
> incorporates the sender address as part of the LSP ID.
> 
> > 1 ) Doubt here : Where does the TunnelId come from then ?
> 
> Tunnel ID is only locally unique to the ingress node.
> 
> > 2) If TunnelId HAS a globally significant value , then why do we
> > need an Extended Tunnel Id ?
> 
> Your assumption is wrong.  It is not globally significant.  
> The extended
> tunnel ID is required to make the entire session object 
> globally unique.
> 
> You can't just blindly assume that extended tunnel ID will match the
> sender address, because a zero value (meaning "don't care", needed for
> sharing resources between two LSPs from different senders) is legal.
> 
> > [ If the administrator wants to tie a tunnel to an Ingress , all he
> > has to do is to make sure that no other tunnel in the domain has
> > the same TunnelId.]
> 
> Easier said than done.  The only way an administrator can 
> guarantee this
> is if every single LSP in the network is manually configured.  This is
> not always going to be true.
> 
> > If TunnelId is locally assigned at a node , then Extended Tunnel Id
> > MUST be set to the ingress IP address to be able to distinguish it
> > from some tunnel being made at another ingress with same tunnel id.
> 
> Unless it is intended that this LSP will share resources with another
> LSP terminating on the same node.
> 
> > ( possible since tunnel id is being locally decided ).
> > However this means that one tunnel CANNOT have two lsps belonging
> > to the same tunnel originating at two ingresses and exiting from
> > the same egress.
> 
> There is no reason why you can not have this.  That is 
> specifically what
> the zero value for extended tunnel ID is meant for.
> 
> -- David
> 


From owner-mpls@UU.NET  Tue Jul 31 16:08: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 QAA17478
	for ; Tue, 31 Jul 2001 16:08: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 QQlace22866;
	Tue, 31 Jul 2001 20:09:09 GMT
Received: by mail-control.mail.uu.net 
	id QQlace20091
	for mpls-outgoing; Tue, 31 Jul 2001 20: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 QQlace19447
	for ; Tue, 31 Jul 2001 20:08: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 QQlacd00387
	for ; Tue, 31 Jul 2001 19:59:58 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQlacd11869
	for ; Tue, 31 Jul 2001 19:59:58 GMT
Received: from BLIULAPTOP ([172.16.8.181]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 31 Jul 2001 15:59:53 -0400
Message-ID: <034101c119fa$ee1e5c10$27de883e@movaz.com>
From: "Adrian Farrel" 
To: 
Cc: , "Thomas D. Nadeau" 
References: <4.3.2.7.2.20010731144213.022d2880@bucket.cisco.com>
Subject: Re: TE-MIB
Date: Tue, 31 Jul 2001 15:56:43 -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: 31 Jul 2001 19:59:54.0640 (UTC) FILETIME=[5DED4100:01C119FB]
Sender: owner-mpls@UU.NET
Precedence: bulk

Incidentally,
In GMPLS, bi-directional tunnels use the same route (in opposite directions) so
the ARHopTable will apply perfectly well.
As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about it) will
support the GMPLS extensions.  For bi-directional LSPs the interesting point (in
this respect) will be additional features of the RRO such as label recording for
both directions.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com
----- Original Message -----
From: "Thomas D. Nadeau" 
To: ; 
Sent: Tuesday, July 31, 2001 3:01 PM
Subject: Re: TE-MIB


>
> >The mplsTunnelARHopTable of TE-MIB does give you
> >the actual hops traversed by the tunnel in one
> >direction.  But, if the LSP is a bi-directional one
> >how would we get/record the actual hops traversed in
> >the other direction?
>
>          Boy, it is good to see all of this interest
> in the MPLS-TE-MIB these days. Gives me the
> impression that a lot of folks are implementing
> it. 8)
>
>          Bi-directional tunnels are not supported
> in the MIB as they were not standardized in MPLS.
> They are in GMPLS however, and will be covered
> in the GMPLS-TE-MIB.
>
>          --Tom
>
>
>




From owner-mpls@UU.NET  Tue Jul 31 16:16:00 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 QAA18116
	for ; Tue, 31 Jul 2001 16:16:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlacf20799;
	Tue, 31 Jul 2001 20:15:45 GMT
Received: by mail-control.mail.uu.net 
	id QQlacf24487
	for mpls-outgoing; Tue, 31 Jul 2001 20:15: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 QQlacf24468
	for ; Tue, 31 Jul 2001 20:15:09 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 QQlacb27767
	for ; Tue, 31 Jul 2001 19:20:32 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlacb22027
	for ; Tue, 31 Jul 2001 19:20:31 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA24751
	for ; Tue, 31 Jul 2001 15:20:30 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA15438 for mpls@uu.net; Tue, 31 Jul 2001 15:20:16 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlacb29129
	for ; Tue, 31 Jul 2001 19:17:30 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 QQlabz06219
	for ; Tue, 31 Jul 2001 18:59:53 GMT
From: Satinder101@aol.com
Received: from imo-m10.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-m10.mx.aol.com [64.12.136.165])
	id QQlabz06557
	for ; Tue, 31 Jul 2001 18:59:53 GMT
Received: from Satinder101@aol.com
	by imo-m10.mx.aol.com (mail_out_v31.9.) id c.d4.9f7fb4b (15875);
	Tue, 31 Jul 2001 14:57:49 -0400 (EDT)
Received: from  web36.aolmail.aol.com (web36.aolmail.aol.com [205.188.222.12]) by air-id07.mail.aol.com (v79.27) with ESMTP id MAILINID72-0731145749; Tue, 31 Jul 2001 14:57:49 -0400
Date: Tue, 31 Jul 2001 14:57:49 EDT
Subject: question on draft-ietf-mpls-diff-09.txt
To: , 
Cc: 
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailer: Unknown (No Version)
Message-ID: 
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois et-all,

I have a couple of questions on 
draft-ietf-mpls-diff-09.txt and would appreciate
if you can clarify for me.

1. The DIFFSERV Object (say in RSVP) has EXP-PHB
   mappings. So I can see that populating the
   'Encaps-->PHB mapping' for E-LSP in Sec 3.2
   is straightforward. But I am not sure how  to
   create the 'Set of PHB-->Encaps mapping' in
   the Diffserv Context (sec 3.4.1) from the signalled
   EXP-PHB map. Is this just a simple reverse mapping ?

2. According to Sec 5.3, each intermediate LSR just
   records the DIFFSERV Object. So for a given E-LSP,
   the incomming and outgoung mappingd are the same ?
   If that is so, how can the outgoing EXP on a given 
   LSR be different from the incomming EXP on the 
   same LSR.  Is this because we may have changed
   the drop precedence,  so the PHB used
   to compute the outgoing EXP is is different from
   the PHB we got when we mapped the incomming EXP
   to PHB.

3. It looks to me that in case of RSVP, the EXP-PHB
   mapping is selected by the box initiating the 
   PATH message (which will be the upstream node
   w.r.t data flow). Whereas in case of LDP 
   (downstream unsolicited) this mapping is selected
   by the downstream node. Is my understanding corect ?


thank you very much

- satinder



From owner-mpls@UU.NET  Tue Jul 31 16:29: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 SMTP id QAA19167
	for ; Tue, 31 Jul 2001 16:29: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 QQlacg06672;
	Tue, 31 Jul 2001 20:30:00 GMT
Received: by mail-control.mail.uu.net 
	id QQlacf25393
	for mpls-outgoing; Tue, 31 Jul 2001 20:29: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 QQlacf25368
	for ; Tue, 31 Jul 2001 20:29:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlacf20271
	for ; Tue, 31 Jul 2001 20:28:54 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 QQlacf26239
	for ; Tue, 31 Jul 2001 20:28:53 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA04297 for mpls@uu.net; Tue, 31 Jul 2001 16:28: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 QQlacf25322
	for ; Tue, 31 Jul 2001 20:28: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 QQlacf04644
	for ; Tue, 31 Jul 2001 20:27:18 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 QQlacf03627
	for ; Tue, 31 Jul 2001 20:27:17 GMT
Received: (qmail 14512 invoked by uid 104); 31 Jul 2001 20:27:17 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 4.734772 secs); 31/07/2001 13:27:12
Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227)
  by mother.pmc-sierra.bc.ca with SMTP; 31 Jul 2001 20:27:08 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6VKR9P24130;
	Tue, 31 Jul 2001 13:27:09 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 13:31:13 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6DCE@BBY1EXM01>
From: Shahram Davari 
To: "'Satinder101@aol.com'" , flefauch@cisco.com,
        davari@ieee.org
Cc: mpls@UU.NET
Subject: RE: question on draft-ietf-mpls-diff-09.txt
Date: Tue, 31 Jul 2001 13:31:13 -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,

> -----Original Message-----
> From: Satinder101@aol.com [mailto:Satinder101@aol.com]
> Sent: Tuesday, July 31, 2001 2:58 PM
> To: flefauch@cisco.com; davari@ieee.org
> Cc: mpls@UU.NET
> Subject: question on draft-ietf-mpls-diff-09.txt
> 
> 
> Francois et-all,
> 
> I have a couple of questions on 
> draft-ietf-mpls-diff-09.txt and would appreciate
> if you can clarify for me.
> 
> 1. The DIFFSERV Object (say in RSVP) has EXP-PHB
>    mappings. So I can see that populating the
>    'Encaps-->PHB mapping' for E-LSP in Sec 3.2
>    is straightforward. But I am not sure how  to
>    create the 'Set of PHB-->Encaps mapping' in
>    the Diffserv Context (sec 3.4.1) from the signalled
>    EXP-PHB map. Is this just a simple reverse mapping ?

Yes.

> 
> 2. According to Sec 5.3, each intermediate LSR just
>    records the DIFFSERV Object. So for a given E-LSP,
>    the incomming and outgoung mappingd are the same ?

Yes.

>    If that is so, how can the outgoing EXP on a given 
>    LSR be different from the incomming EXP on the 
>    same LSR.  Is this because we may have changed
>    the drop precedence,  so the PHB used
>    to compute the outgoing EXP is is different from
>    the PHB we got when we mapped the incomming EXP
>    to PHB.

Yes. This is the case for example when you do policing.

> 
> 3. It looks to me that in case of RSVP, the EXP-PHB
>    mapping is selected by the box initiating the 
>    PATH message (which will be the upstream node
>    w.r.t data flow). Whereas in case of LDP 
>    (downstream unsolicited) this mapping is selected
>    by the downstream node. Is my understanding corect ?

Yes.

-Shahram

> 
> 
> thank you very much
> 
> - satinder
> 



From owner-mpls@UU.NET  Tue Jul 31 16:59: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 QAA21348
	for ; Tue, 31 Jul 2001 16:59: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 QQlach03782;
	Tue, 31 Jul 2001 20:56:54 GMT
Received: by mail-control.mail.uu.net 
	id QQlach28037
	for mpls-outgoing; Tue, 31 Jul 2001 20:56: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 QQlach28013
	for ; Tue, 31 Jul 2001 20:56:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlach26472
	for ; Tue, 31 Jul 2001 20:55:47 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 QQlach00695
	for ; Tue, 31 Jul 2001 20:55:47 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA07231 for mpls@uu.net; Tue, 31 Jul 2001 16:55:47 -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 QQlach27959
	for ; Tue, 31 Jul 2001 20:55:20 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlach28386
	for ; Tue, 31 Jul 2001 20:54:33 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlach13810
	for ; Tue, 31 Jul 2001 20:54:32 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 QAA13958; Tue, 31 Jul 2001 16:54:28 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AFB10713;
	Tue, 31 Jul 2001 16:54:27 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010731165738.022281e8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 31 Jul 2001 17:00:23 -0400
To: , afarrel@movaz.com, manasa@gettos.com
From: "Thomas D. Nadeau" 
Subject: RE: TE-MIB
Cc: mpls@UU.NET
In-Reply-To: <36EF020032CFD411B7B400508B55E590A21B55@milan.turinnetworks
 .com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_23154814==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_23154814==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi Bhaskara,

>It would be more informative if Label value is also added in the 
>ArHopTable of GMPLS-TE-MIB.
>And in the bi-directional case, eventhough it may follow the same reverse 
>route,
>but, one can not gaurantee the same label values...so, thought should be 
>given
>in this respect before finalyzing the extensions.

         Yes, that is a good point. We have been
going around with the various options related to
the GMPLS-TE-MIB and how to best support GMPLS-TE
while remaining backwards compatible with MPLS
"classic" for several months now. We will present
our options during the meeting next week and to the
list shortly. If you have further thoughts on this,
please send them to us and/or come to the meeting
next week to  discuss them there during the
GMPLS-TE-MIB time slot in CCAMP.

         --Tom



>regards
>bhaskara
>
>-----Original Message-----
>From: Adrian Farrel [mailto:afarrel@movaz.com]
>Sent: Tuesday, July 31, 2001 12:57 PM
>To: manasa@gettos.com
>Cc: mpls@UU.NET; Thomas D. Nadeau
>Subject: Re: TE-MIB
>
>Incidentally,
>In GMPLS, bi-directional tunnels use the same route (in opposite 
>directions) so
>the ARHopTable will apply perfectly well.
>As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about 
>it) will
>support the GMPLS extensions.  For bi-directional LSPs the interesting 
>point (in
>this respect) will be additional features of the RRO such as label 
>recording for
>both directions.
>
>Adrian
>--
>Adrian Farrel
>Movaz Networks Inc.
>afarrel@movaz.com
>----- Original Message -----
>From: "Thomas D. Nadeau" 
>To: ; 
>Sent: Tuesday, July 31, 2001 3:01 PM
>Subject: Re: TE-MIB
>
> >
> > >The mplsTunnelARHopTable of TE-MIB does give you
> > >the actual hops traversed by the tunnel in one
> > >direction.  But, if the LSP is a bi-directional one
> > >how would we get/record the actual hops traversed in
> > >the other direction?
> >
> >          Boy, it is good to see all of this interest
> > in the MPLS-TE-MIB these days. Gives me the
> > impression that a lot of folks are implementing
> > it. 8)
> >
> >          Bi-directional tunnels are not supported
> > in the MIB as they were not standardized in MPLS.
> > They are in GMPLS however, and will be covered
> > in the GMPLS-TE-MIB.
> >
> >          --Tom
> >
> >
> >

--=====================_23154814==_.ALT
Content-Type: text/html; charset="us-ascii"




        Hi
Bhaskara,




It would be more informative if
Label value is also added in the ArHopTable of GMPLS-TE-MIB. 


And in the bi-directional case, eventhough it may follow the
same reverse route, 

but, one can not gaurantee the same label values...so,
thought should be given 

in this respect before finalyzing the extensions.



        Yes, that is a good point. We have been 

going around with the various options related to 

the GMPLS-TE-MIB and how to best support GMPLS-TE 

while remaining backwards compatible with MPLS 

"classic" for several months now. We will present

our options during the meeting next week and to the

list shortly. If you have further thoughts on this, 

please send them to us and/or come to the meeting 

next week to  discuss them there during the 

GMPLS-TE-MIB time slot in CCAMP.



        --Tom








regards 

bhaskara 



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

From: Adrian Farrel [mailto:afarrel@movaz.com] 

Sent: Tuesday, July 31, 2001 12:57 PM 

To: manasa@gettos.com 

Cc: mpls@UU.NET; Thomas D. Nadeau 

Subject: Re: TE-MIB 



Incidentally, 

In GMPLS, bi-directional tunnels use the same route (in opposite directions) so 

the ARHopTable will apply perfectly well. 

As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about it) will 

support the GMPLS extensions.  For bi-directional LSPs the interesting point (in 

this respect) will be additional features of the RRO such as label recording for 

both directions. 



Adrian 

-- 

Adrian Farrel 

Movaz Networks Inc. 

afarrel@movaz.com 

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

From: "Thomas D. Nadeau" <tnadeau@cisco.com> 

To: <manasa@gettos.com>; <mpls@UU.NET> 

Sent: Tuesday, July 31, 2001 3:01 PM 

Subject: Re: TE-MIB 



> 

> >The mplsTunnelARHopTable of TE-MIB does give you 

> >the actual hops traversed by the tunnel in one 

> >direction.  But, if the LSP is a bi-directional one 

> >how would we get/record the actual hops traversed in 

> >the other direction? 

> 

>          Boy, it is good to see all of this interest 

> in the MPLS-TE-MIB these days. Gives me the 

> impression that a lot of folks are implementing 

> it. 8) 

> 

>          Bi-directional tunnels are not supported 

> in the MIB as they were not standardized in MPLS. 

> They are in GMPLS however, and will be covered 

> in the GMPLS-TE-MIB. 

> 

>          --Tom 

> 

> 

> 


--=====================_23154814==_.ALT--



From owner-mpls@UU.NET  Tue Jul 31 17:02:41 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 RAA21569
	for ; Tue, 31 Jul 2001 17:02: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 QQlaci27121;
	Tue, 31 Jul 2001 21:03:04 GMT
Received: by mail-control.mail.uu.net 
	id QQlaci03962
	for mpls-outgoing; Tue, 31 Jul 2001 21:02: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 QQlaci03520
	for ; Tue, 31 Jul 2001 21:02: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 QQlaci03602
	for ; Tue, 31 Jul 2001 21:02:02 GMT
Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQlaci08848
	for ; Tue, 31 Jul 2001 21:02:02 GMT
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6VL21O21778
	for ; Tue, 31 Jul 2001 17:02:01 -0400 (EDT)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 31 Jul 2001 17:02:01 -0400
Message-ID: <4490F7068AC0D111A7120008C72878EC0ADFF373@nj7460exch003u.ho.lucent.com>
From: "Kyriakopoulos, Aris (Aris)" 
To: "'Fabris Sergio'" , mpls@UU.NET
Subject: RE: classification
Date: Tue, 31 Jul 2001 17:01:57 -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

Sergio,

The statement below says that the best (longest) match is determined by the
IP routing table to be with prefix X.  Absent any other information, that is
the FEC and resulting label the incoming IP packet maps to.  So your LSP
follows the same path determined by an IP routing protocol.  This isn't a
traffic engineering issue.  

There is no requirement that an FEC should consist of both a source and
destination IP address, although it is certainly allowed.  In this case, you
would use an explicitly-routed or constraint-routed LSP.  If you do this,
you are free to use a path that does not follow the standard
destination-based route.  *That* is an example of TE!

Regards,
Aris

-----Original Message-----
From: Fabris Sergio [mailto:fabriss@TELEFONICA.COM.AR]
Sent: Tuesday, July 31, 2001 2:39 PM
To: mpls@UU.NET
Subject: classification

Traffic Engineering:

..........A standard IP packet arrives at Interface 1 of LSR 1. After
performing a longest-match
lookup in its IP routing table, LSR 1 discovers that the best match is with
Prefix X and that
all traffic matching Prefix X should to be forwarded on Interface 2 with a
Label = 10.............

How LSR1 discover that the best match is whit that Prefix X??
Does It made same classification based on source address??

Thanks.

Sergio


From owner-mpls@UU.NET  Tue Jul 31 17:19: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 RAA22790
	for ; Tue, 31 Jul 2001 17:19: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 QQlacg10002;
	Tue, 31 Jul 2001 20:39:24 GMT
Received: by mail-control.mail.uu.net 
	id QQlacg26196
	for mpls-outgoing; Tue, 31 Jul 2001 20:38:52 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 QQlacg26188
	for ; Tue, 31 Jul 2001 20:38: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 QQlacg01240
	for ; Tue, 31 Jul 2001 20:36:30 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 QQlacg06262
	for ; Tue, 31 Jul 2001 20:36:29 GMT
Received: by milan.turinnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 13:36:29 -0700
Message-ID: <36EF020032CFD411B7B400508B55E590A21B55@milan.turinnetworks.com>
To: afarrel@movaz.com, manasa@gettos.com
Cc: mpls@UU.NET, tnadeau@cisco.com
Subject: RE: TE-MIB
Date: Tue, 31 Jul 2001 13:36:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C11A00.792D7930"
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_01C11A00.792D7930
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Adrian,

It would be more informative if Label value is also added in the ArHopTable
of GMPLS-TE-MIB.
And in the bi-directional case, eventhough it may follow the same reverse
route,
but, one can not gaurantee the same label values...so, thought should be
given
in this respect before finalyzing the extensions.

regards
bhaskara

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: Tuesday, July 31, 2001 12:57 PM
To: manasa@gettos.com
Cc: mpls@UU.NET; Thomas D. Nadeau
Subject: Re: TE-MIB


Incidentally,
In GMPLS, bi-directional tunnels use the same route (in opposite directions)
so
the ARHopTable will apply perfectly well.
As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about it)
will
support the GMPLS extensions.  For bi-directional LSPs the interesting point
(in
this respect) will be additional features of the RRO such as label recording
for
both directions.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com
----- Original Message -----
From: "Thomas D. Nadeau" 
To: ; 
Sent: Tuesday, July 31, 2001 3:01 PM
Subject: Re: TE-MIB


>
> >The mplsTunnelARHopTable of TE-MIB does give you
> >the actual hops traversed by the tunnel in one
> >direction.  But, if the LSP is a bi-directional one
> >how would we get/record the actual hops traversed in
> >the other direction?
>
>          Boy, it is good to see all of this interest
> in the MPLS-TE-MIB these days. Gives me the
> impression that a lot of folks are implementing
> it. 8)
>
>          Bi-directional tunnels are not supported
> in the MIB as they were not standardized in MPLS.
> They are in GMPLS however, and will be covered
> in the GMPLS-TE-MIB.
>
>          --Tom
>
>
>


------_=_NextPart_001_01C11A00.792D7930
Content-Type: text/html;
	charset="iso-8859-1"






RE: TE-MIB




Hi Adrian,




It would be more informative if Label value is also added in the ArHopTable of GMPLS-TE-MIB.

And in the bi-directional case, eventhough it may follow the same reverse route,

but, one can not gaurantee the same label values...so, thought should be given

in this respect before finalyzing the extensions.




regards

bhaskara




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

From: Adrian Farrel [mailto:afarrel@movaz.com]

Sent: Tuesday, July 31, 2001 12:57 PM

To: manasa@gettos.com

Cc: mpls@UU.NET; Thomas D. Nadeau

Subject: Re: TE-MIB






Incidentally,

In GMPLS, bi-directional tunnels use the same route (in opposite directions) so

the ARHopTable will apply perfectly well.

As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about it) will

support the GMPLS extensions.  For bi-directional LSPs the interesting point (in

this respect) will be additional features of the RRO such as label recording for

both directions.




Adrian

--

Adrian Farrel

Movaz Networks Inc.

afarrel@movaz.com

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

From: "Thomas D. Nadeau" <tnadeau@cisco.com>

To: <manasa@gettos.com>; <mpls@UU.NET>

Sent: Tuesday, July 31, 2001 3:01 PM

Subject: Re: TE-MIB






>

> >The mplsTunnelARHopTable of TE-MIB does give you

> >the actual hops traversed by the tunnel in one

> >direction.  But, if the LSP is a bi-directional one

> >how would we get/record the actual hops traversed in

> >the other direction?

>

>          Boy, it is good to see all of this interest

> in the MPLS-TE-MIB these days. Gives me the

> impression that a lot of folks are implementing

> it. 8)

>

>          Bi-directional tunnels are not supported

> in the MIB as they were not standardized in MPLS.

> They are in GMPLS however, and will be covered

> in the GMPLS-TE-MIB.

>

>          --Tom

>

>

>





------_=_NextPart_001_01C11A00.792D7930--


From owner-mpls@UU.NET  Tue Jul 31 17:37: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 SMTP id RAA24066
	for ; Tue, 31 Jul 2001 17:37: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 QQlack17180;
	Tue, 31 Jul 2001 21:38:05 GMT
Received: by mail-control.mail.uu.net 
	id QQlack21922
	for mpls-outgoing; Tue, 31 Jul 2001 21:37: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 QQlack21910
	for ; Tue, 31 Jul 2001 21:37:25 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlack09276
	for ; Tue, 31 Jul 2001 21:36:19 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 QQlack14945
	for ; Tue, 31 Jul 2001 21:36:19 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA10024 for mpls@uu.net; Tue, 31 Jul 2001 17:36: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 QQlack21712
	for ; Tue, 31 Jul 2001 21:35:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlack06121
	for ; Tue, 31 Jul 2001 21:35:10 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 QQlack28445
	for ; Tue, 31 Jul 2001 21:35:10 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 RAA18813; Tue, 31 Jul 2001 17:35:09 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA20625; Tue, 31 Jul 2001 17:35:09 -0400 (EDT)
Message-Id: <200107312135.RAA20625@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: agenda@ietf.org, mpls@UU.NET
Subject: MPLS Agenda
Date: Tue, 31 Jul 2001 17:35:09 -0400
From: George Swallow 
Sender: owner-mpls@UU.NET
Precedence: bulk



MPLS Agenda                      London               August 6, 2001
====================================================================

Agenda Bashing                              Chairs                 5

draft-iwata-mpls-shared-fastreroute-00      Atsushi Iwata         15

draft-atlas-local-protect-interop-00        Alia Atlas            15

draft-gan-fast-reroute-00                   Ping Pan              15

draft-tempest-mpls-ccamp-rsvp-resync-00     Osama Aboul-Magd      15

draft-pan-rsvp-te-restart-01                Ping Pan              15

draft-tsenevir-mpls-lauth-01                Tissa Senevirathne    15

draft-ganti-mpls-diffserv-elsp-00           Sudhakar Ganti        15

draft-dubuc-mpls-bundle-mib-02              Tom Nadeau            10

Workgroup status                                                  15





====================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824





From owner-mpls@UU.NET  Tue Jul 31 18:21: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 SAA27671
	for ; Tue, 31 Jul 2001 18:21: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 QQlacn10062;
	Tue, 31 Jul 2001 22:22:29 GMT
Received: by mail-control.mail.uu.net 
	id QQlacn15797
	for mpls-outgoing; Tue, 31 Jul 2001 22:21: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 QQlacn15759
	for ; Tue, 31 Jul 2001 22:21: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 QQlacn07648
	for ; Tue, 31 Jul 2001 22:21:10 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQlacn07931
	for ; Tue, 31 Jul 2001 22:21:10 GMT
Received: from BLIULAPTOP ([172.16.8.181]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 31 Jul 2001 18:21:06 -0400
Message-ID: <039301c11a0e$a8236200$27de883e@movaz.com>
From: "Adrian Farrel" 
To: "George Swallow" 
Cc: 
References: <200107312135.RAA20625@telescope.cisco.com>
Subject: Re: MPLS Agenda
Date: Tue, 31 Jul 2001 18:17:55 -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: 31 Jul 2001 22:21:06.0748 (UTC) FILETIME=[17B257C0:01C11A0F]
Sender: owner-mpls@UU.NET
Precedence: bulk

> MPLS Agenda                      London               August 6, 2001

> draft-atlas-local-protect-interop-00        Alia Atlas            15

Presume that is draft-atlas-rsvp-local-protect-interop-01 ?

Adrian





From owner-mpls@UU.NET  Tue Jul 31 18:54: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 SMTP id SAA00192
	for ; Tue, 31 Jul 2001 18:54: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 QQlacp16097;
	Tue, 31 Jul 2001 22:54:33 GMT
Received: by mail-control.mail.uu.net 
	id QQlacp18201
	for mpls-outgoing; Tue, 31 Jul 2001 22:54: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 QQlacp18190
	for ; Tue, 31 Jul 2001 22:53: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 QQlacp14873
	for ; Tue, 31 Jul 2001 22:53:29 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 QQlacp21364
	for ; Tue, 31 Jul 2001 22:53:29 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 SAA12601
	for ; Tue, 31 Jul 2001 18:53:26 -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 SAA20560
	for ; Tue, 31 Jul 2001 18:53:29 -0400 (EDT)
Message-ID: <3B6736E8.A1BCF926@marconi.com>
Date: Tue, 31 Jul 2001 18:53:28 -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: Doubts about MPLS-TE Mib
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Lipovetsky, Sergey" wrote:
> 
> Here are comments on this thread.
> RFC2205 states "RSVP defines a "session" to be a data flow with a
> particular destination and transport-layer protocol." My
> understanding is that it is not different for RSVP-TE and a session
> object relates to the destination.

The SESSION object is not the same for RSVP and RSVP-TE.

In RSVP, the SESSION object consists of a 3-tuple consisting of
destination address, destination L4-protocol, and destination port
number.  In RSVP-TE, the SESSION object is a 3-tuple consisting of
egress address, tunnel ID and extended tunnel ID.

In either case, the data in the SESSION object is what uniquely
identifies the session, and nothing else does.

> TunnelId is a part of the session object and probably also relates
> to the destination. If this is true TunnelId should be locally
> unique to the egress node and a pair [egress address, TunnelId]
> should uniquely identify an RSVP session.

You're exchanging cause and effect here.  The data in the SESSION object
is what defines a session.  If two different LSPs are signaled with Path
messages containing identical SESSION objects, then they are in the same
session.  Period.  It doesn't matter what the user may or may not have
wanted.

Because tunnel ID can not be globally synchronized without using means
beyond the scope of RSVP-TE, the extended tunnel ID was created.  It can
either be zero, in the case where resource sharing among different
senders is desired, or it can be set to a globally unique value
(preferrably the sender's IP address) in the case where such resource
sharing is not desired.

> However, there is a problem with TunnelId allocation on the ingress
> node in this case.
> 
> The requirements to set Extended tunnel ID to a non-zero value to
> guarantee session uniqueness, when TunnelId is allocated by the
> ingress node prevents from merging LSPs having the same egress node
> but different ingress nodes.
> What is wrong here?

You are assuming that guaranteeing session uniqueness is something that
everybody always wants.  This is an invalid assumption.  There are
situations where it is desirable and there are situations where it is
not.

There are situations where an operator may explicitly want two different
LSPs from different senders to share resources.  The only way to signal
this is by using a zero value for extended tunnel ID.

-- David


From owner-mpls@UU.NET  Tue Jul 31 18:59: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 SAA00624
	for ; Tue, 31 Jul 2001 18:59: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 QQlacq02211;
	Tue, 31 Jul 2001 23:00:13 GMT
Received: by mail-control.mail.uu.net 
	id QQlacp18560
	for mpls-outgoing; Tue, 31 Jul 2001 22:59: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 QQlacp18547
	for ; Tue, 31 Jul 2001 22:59:31 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 QQlacp23032
	for ; Tue, 31 Jul 2001 22:58:49 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 QQlacp29695
	for ; Tue, 31 Jul 2001 22:58: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 SAA12797;
	Tue, 31 Jul 2001 18:58:45 -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 SAA21006;
	Tue, 31 Jul 2001 18:58:48 -0400 (EDT)
Message-ID: <3B673828.BBA272D2@marconi.com>
Date: Tue, 31 Jul 2001 18:58:48 -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: "Feng, Mark" 
CC: "'mpls@uu.net'" 
Subject: Re: Doubts about MPLS-TE Mib
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Feng, Mark" wrote:
> 
> IMO, tunnel Id has "global" significance, within some particular
> MPLS domain, synonym to well-known ports in classical RSVP. I think
> that it is unlikely the operator will assign a LSP some tunnel Id
> without knowing what other potential ingress routers might share
> the resources.

If an operator is going to hand-assign tunnel IDs, yes.  And in this
situation, the operator can choose whether multiple LSPs sharing the
tunnel ID should share resources or not by directing the switch to use a
zero or non-zero value for extended tunnel ID

It is also possible for an ingress router to automatically create LSPs
based on topology information of some kind.  In which case, the tunnel
IDs would be automatically generated.  Of course, in this situation,
resource sharing would be a bad thing, and so a non-zero value would be
used for extended tunnel ID.

> Also, the fact that the egress router is the one who decides what
> style to use implies that some out-of-band mechanism is used to
> ensure the proper operation between the ingress routers and the
> egress routers.

No.  RSVP has always been egress driven.  The egress router is free to
try and reserve with any style it wants, and using any amount of
resources it wants.  This is all perfectly legal and part of the design
of RSVP.

Of course, a router that completely ignores the information requested in
the Path message is one that nobody will be interested in buying.  But
it does mean that two Paths in the same session, requesting different
reservation styles and different amounts of resources will not result in
any kind of self-contradictory state.

> The only reason I can think of to have the tunnel Id and extended
> tunnel Id is to tailor different needs. For example, there might be
> some pre-determined mechanism to assign the tunnel Id at each
> ingress router. If one router decides not to join the sharing,
> though it is assinged a particular tunnel Id, it can add its own IP
> in the extended tunnel Id, to exclude itself in the sharing.

This is one possible scenario.  There are others as well.

-- David


From owner-mpls@UU.NET  Tue Jul 31 19:03: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 SMTP id TAA00942
	for ; Tue, 31 Jul 2001 19:03: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 QQlacq27013;
	Tue, 31 Jul 2001 23:04:22 GMT
Received: by mail-control.mail.uu.net 
	id QQlacq29518
	for mpls-outgoing; Tue, 31 Jul 2001 23:03: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 QQlacq29491
	for ; Tue, 31 Jul 2001 23:03: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 QQlacq29191
	for ; Tue, 31 Jul 2001 23:02:21 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlacq24843
	for ; Tue, 31 Jul 2001 23:02:21 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA12966
	for ; Tue, 31 Jul 2001 19:02:18 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA21283
	for ; Tue, 31 Jul 2001 19:02:21 -0400 (EDT)
Message-ID: <3B6738FC.C2DEC826@marconi.com>
Date: Tue, 31 Jul 2001 19:02:20 -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: classification
References: <3D9C91EAD5D1D411851300508BCF243F02BE2410@MSTELEFONICA3>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fabris Sergio wrote:
> 
> Traffic Engineering:
> 
> ..........A standard IP packet arrives at Interface 1 of LSR 1. After
> performing a longest-match
> lookup in its IP routing table, LSR 1 discovers that the best match is with
> Prefix X and that
> all traffic matching Prefix X should to be forwarded on Interface 2 with a
> Label = 10.............
> 
> How LSR1 discover that the best match is whit that Prefix X??
> Does It made same classification based on source address??

The same way a non-MPLS router would determine the next-hop router.

Through any means it is configured for.  Maybe by destination address
alone.  Maybe also counting source address.  Or perhaps L4 protocol,
port number, stateful packet inspection, load-balancing formulae, or
anything else you can think of.

Traffic engineering is just a fancy name for routing based on
information other than the destination address.  There is no fundamental
difference between a traditional router choosing a next-hop and an LER
choosing an LSP.

-- David


From owner-mpls@UU.NET  Tue Jul 31 19:27: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 TAA02901
	for ; Tue, 31 Jul 2001 19:27: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 QQlacr12231;
	Tue, 31 Jul 2001 23:28:08 GMT
Received: by mail-control.mail.uu.net 
	id QQlacr10462
	for mpls-outgoing; Tue, 31 Jul 2001 23:27: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 QQlacr10449
	for ; Tue, 31 Jul 2001 23:27: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 QQlacr10453
	for ; Tue, 31 Jul 2001 23:26:19 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlacr20737
	for ; Tue, 31 Jul 2001 23:26:18 GMT
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA15876;
	Tue, 31 Jul 2001 23:26:07 GMT
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 31 Jul 2001 23:26:06 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 31 Jul 2001 16:26:05 -0700
Message-ID: 
From: "Feng, Mark" 
To: "'David Charlap'" 
Cc: "'mpls@uu.net'" 
Subject: RE: Doubts about MPLS-TE Mib
Date: Tue, 31 Jul 2001 16:26:04 -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

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 31, 2001 3:59 PM
> To: Feng, Mark
> Cc: 'mpls@uu.net'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> "Feng, Mark" wrote:
> > 
> > IMO, tunnel Id has "global" significance, within some particular
> > MPLS domain, synonym to well-known ports in classical RSVP. I think
> > that it is unlikely the operator will assign a LSP some tunnel Id
> > without knowing what other potential ingress routers might share
> > the resources.
> 
> If an operator is going to hand-assign tunnel IDs, yes.  And in this
> situation, the operator can choose whether multiple LSPs sharing the
> tunnel ID should share resources or not by directing the 
> switch to use a
> zero or non-zero value for extended tunnel ID
> 
> It is also possible for an ingress router to automatically create LSPs
> based on topology information of some kind.  In which case, the tunnel
> IDs would be automatically generated.  Of course, in this situation,
> resource sharing would be a bad thing, and so a non-zero 
> value would be
> used for extended tunnel ID.
>

I agree fully. What I was trying to say is, if "sharing" is desired, the
operator really needs to have some "global" knowledge of the tunnel IDs;
otherwise, he/she might get a nasty surprise.
 
> > Also, the fact that the egress router is the one who decides what
> > style to use implies that some out-of-band mechanism is used to
> > ensure the proper operation between the ingress routers and the
> > egress routers.
> 
> No.  RSVP has always been egress driven.  The egress router is free to
> try and reserve with any style it wants, and using any amount of
> resources it wants.  This is all perfectly legal and part of 
> the design
> of RSVP.
> 
> Of course, a router that completely ignores the information 
> requested in
> the Path message is one that nobody will be interested in buying.  But
> it does mean that two Paths in the same session, requesting different
> reservation styles and different amounts of resources will 
> not result in
> any kind of self-contradictory state.
> 

I agree with this as well:-). My point was, the egress router needs to base
on some kind of criteria to decide the style. That is outside the scope of
RSVP. Like you said, if the egress router completely ignore the information
in the Path messages, the product might not be that appealing.
 
> > The only reason I can think of to have the tunnel Id and extended
> > tunnel Id is to tailor different needs. For example, there might be
> > some pre-determined mechanism to assign the tunnel Id at each
> > ingress router. If one router decides not to join the sharing,
> > though it is assinged a particular tunnel Id, it can add its own IP
> > in the extended tunnel Id, to exclude itself in the sharing.
> 
> This is one possible scenario.  There are others as well.
> 

I agree again. It is meant for an example.

> -- David
> 



From owner-mpls@UU.NET  Tue Jul 31 22:14: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 WAA16106
	for ; Tue, 31 Jul 2001 22:14: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 QQlabx26721;
	Tue, 31 Jul 2001 18:19:43 GMT
Received: by mail-control.mail.uu.net 
	id QQlabx04876
	for mpls-outgoing; Tue, 31 Jul 2001 18:19: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 QQlabx04867
	for ; Tue, 31 Jul 2001 18:18: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 QQlabw03175
	for ; Tue, 31 Jul 2001 18:14:12 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlabw08352
	for ; Tue, 31 Jul 2001 18:14:11 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA22025 for ; Tue, 31 Jul 2001 14:14:10 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA14713 for mpls@uu.net; Tue, 31 Jul 2001 14:13:56 -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 QQlabw03085
	for ; Tue, 31 Jul 2001 18:05:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlabv00614
	for ; Tue, 31 Jul 2001 17:58:45 GMT
Received: from omta03.mta.everyone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sitemail.everyone.net [216.200.145.35])
	id QQlabv15238
	for ; Tue, 31 Jul 2001 17:58:44 GMT
Received: from sitemail.everyone.net (reports [216.200.145.62])
	by omta03.mta.everyone.net (Postfix) with ESMTP id 6C1814A539
	for ; Tue, 31 Jul 2001 10:58:44 -0700 (PDT)
Received: by sitemail.everyone.net (Postfix, from userid 99)
	id 6283F36F9; Tue, 31 Jul 2001 10:58:44 -0700 (PDT)
Content-Type: text/plain
Content-Disposition: inline
Mime-Version: 1.0
X-Mailer: MIME-tools 4.104 (Entity 4.117)
Date: Tue, 31 Jul 2001 10:58:44 -0700 (PDT)
From: manasa p 
To: mpls@UU.NET
Subject: TE-MIB
Reply-To: manasa@gettos.com
X-Originating-Ip: [63.197.247.13]
Message-Id: <20010731175844.6283F36F9@sitemail.everyone.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

The mplsTunnelARHopTable of TE-MIB does give you
the actual hops traversed by the tunnel in one 
direction.  But, if the LSP is a bi-directional one
how would we get/record the actual hops traversed in
the other direction?

regards
manasa

_____________________________________________________________
Get your own Free Email account for a lifetime at http://www.gettos.com