The MPLS WG Archive

[Manas Kamal Bhattacharya <manasb@allegronetworks.com>]

Suresh,
Please read my comments inline.

>-----Original Message-----
>From: Suresh Katukam 
>Sent: Thursday, February 14, 2002 5:06 PM
>To: Manas Kamal Bhattacharya
>Cc: Khuzema Pithewan; Sandeep B; mpls@UU.NET; Manoj Agiwal; 'Ping Pan'
>Subject: RE: Doubt about Refresh reduction
>
>
>
>Manas,
>
>At
>  02:11 PM 2/14/2002 -0800, Manas Kamal Bhattacharya wrote:
>>The MesgId & Srefresh extensions are useful for reducing the refresh
>>overhead for rsvp states. The use of Mesg Id in Path and Resv gives
>>significant improvement in reducing protocol processing load. 
>If a trigger
>>Path/Resv message arrives you got to do full protocol 
>processing for the
>>packet, but all subsequent refreshes for this state will come 
>with the new
>>Mesg Id. In Path and Resv messages use of Mesg Id will also help in
>>detecting out of order messages. The implementer has the 
>option of using
>>mesg Id along with Ack to provide reliability.
>
>This is correct.
>
>>Coming to mesg id in the Tears and Errors. The only reason why an
>>implementer MAY choose to use include Mesg Id in outgoing 
>Tears and errors
>>is to provide some reliability using the ack mechanism. One 
>cannot use Mesg
>>Id in the Tear/Error messages to reduce protocol processing 
>load or even to
>>detect ooo packets, if some implementation does this there 
>may be interop
>>issues.  This becomes apparent from Section 4.5 in RFC2961.
>
>I agree that is what the RFC says. But I am not sure whether 
>this is correct.

[Manas] This section of the RFC is unclear on the usage of 
Mesg Id on Tear and Error message. The implementer has the 
choice of including the mesg id in the Tears and Errors. 
However if once decides to use Mesg id in outgoing Tears and
Errors, it should be used ONLY to provide reliability. No 
performance gain can be achieved and if we use it to detect
ooo packet, the results cannot be guaranteed to be consistent.



>
>
>>[Manas] Suresh, you cannot assume that the packet is ooo, if 
>a matching
>>state block is not found and the new mesg id is less then the mesg id
>>previously received from the neighbor. There is also another 
>possibility
>>that the mesg id has wrapped around. Also what about this case:
>>You have one  LSP, L1 and you want to setup a new LSP L2. So 
>you send a Path
>>For L2(with mesg id 100), now for some reason you are tearing 
>L1, so you
>>send PTear for L1(with Mesg Id101). The PTear for L1(mesg id 
>101) somehow
>>arrives before the Path for L2(mesg id 100). So 101 is the 
>last received
>>mesg id from the neighbor. Now when the Path(L2,mesgid 100) 
>arrives, we do
>>not have a matching PSB( as this is the first Path for the 
>LSP L2) and the
>>last received message id is 101.  You cannot drop this Path 
>for L2 message.
>
>Here is another scenario: source wants to send a Full PATH message as
>a refresh, and then send a PATH TEAR . But at the other end, PATH TEAR
>was received. So PATH STATE and everything is removed. Now, the refresh
>PATH message is received. So the other end considers that this 
>is for a new
>LSP and tries to create one. This takes up resources 
>everywhere along the path.
>This is wrong to since Source is not going to send a PATH 
>again for this. 
>The worst
>thing is that, if Source wants to send another PATH with different 
>parameters (but
>same session/sender template), then the other end sends a PATH error.


[Manas] If sender wants to setup a new LSP but sends a new Path
with same (session/sender tmpl) then it looks more like an 
implementation issue. Coming to the receiver even if some of 
the parameters are changed in the new Path message, it is not 
necessary that the receiver will always send a Path Err. 


>
>This would cause more problems than dropping a PATH message for L2 in
>your example. In your example, if I drop PATH, Source will 
>atleast retry. 
>In the
>case I described, you will waste resources and will not be 
>able to set up 
>new circuits.


[Manas] I agree that resources will unnecessarily be held up till 
the lone PSB times out. If we look at the from another side. If the
Path is dropped and a refresh comes it will also have the same mesg
id as the previous Path we just dropped. So the LSP will not come up
until the mesg id in incremented after a cleanup timeout. 

I am sure we can come up with many such scenerios. But the fact is
that Mesg Id with Tears and Errors will not give a consistent result 
in many cases.




>
>Best bet is to separate Message ID from Call Reference (Call 
>ID) and use 
>two ids
>for two different purposes.


[Manas] In RSVP-TE with MPLS we do not use Call Refrence to identify
any message or state block. 

Thanks,
Manas

>
>Thanks,
>suresh
>
>
>>I agree with Ping that is may not be a good idea to use mesg 
>id in Tear and
>>error message. However if we receive a Tear or Error with 
>Mesg Id( with ack
>>desired) we should be able to send an Ack message. Mesg Id in 
>Path/Resv and
>>also Srefresh are pretty good optimizations to reduce 
>protocol processing
>>load.
>>
>>Thanks,
>>Manas
>>
>> >
>> >Thanks,
>> >Suresh
>> >
>> >
>> >>Khuzema.
>> >>
>> >>
>> >> > ----------
>> >> > From:         Suresh Katukam[SMTP:skatukam@cisco.com]
>> >> > Sent:         Thursday, February 14, 2002 7:40 AM
>> >> > To:   Sandeep B
>> >> > Cc:   mpls@UU.NET
>> >> > Subject:      Re: Doubt about Refresh reduction
>> >> >
>> >> >
>> >> > I think it is useful to have Message IDs for all 
>messages. Even for
>> >> > optical/SONET links too.
>> >> > If you have OF/OB, or IF/IB control channels, it is quite
>> >possible that
>> >> > you
>> >> > wanted to send
>> >> > a refresh PATH message and then send a PATH TEAR. If 
>you do not use
>> >> > message
>> >> > ids,
>> >> > it is quite possible that PATH TEAR may come first and
>> >then the PATH
>> >> > message at the
>> >> > other end. This would tear down and create the circuit at
>> >the other end of
>> >> >
>> >> > the link.
>> >> >
>> >> > In effect, to find out of order messages.
>> >> >
>> >> > -- Suresh
>> >> >
>> >> > At 03:48 PM 2/13/2002 -0800, Ping Pan wrote:
>> >> > >If I recall correctly, at one point, we were worried
>> >about the noisy
>> >> > >links, where without some sort of ack, RSVP messages may
>> >get dropped. In
>> >> > >this case, having msgids for teardown and error would be
>> >nice. Depending
>> >> > >on where you want to apply refresh reduction, you have
>> >the option where
>> >> > to
>> >> > >apply msgid's. On SONET/optial links, I am not sure it's
>> >useful to use
>> >> > >msgid for error and teardown messages.
>> >> > >
>> >> > >2 cents,
>> >> > >
>> >> > >- Ping
>> >> > >
>> >> > >
>> >> > >Sandeep B wrote:
>> >> > >
>> >> > >>I have a more basic question.
>> >> > >>Ping -
>> >> > >>Why do we need to send PATHTEAR, RESVTEAR, PATHERR,
>> >RESVERR with Msgids.
>> >> >
>> >> > >>These are all triggered messages and what purpose do
>> >they solve when we
>> >> > >>send these packets with msgid.
>> >> > >>-Sandeep
>> >> > >>
>> >> > 
>>>_________________________________________________________________
>> >> > >>Send and receive Hotmail on your mobile device:
>>http://mobile.msn.com
>> > > >
>> > > >
>> > >
>