The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Arumugamr wrote:
> 
> 1. RFC 2961 states two methods of refresh overhead reductions namely the
> Bundle and SRefresh mechanism. If an implementation supports RR, then it has
> to support the both extensions.  SRefresh has an advantage over Bundling in
> terms conserving bandwidth and processing overhead.  Is there any specific
> scenario, wherein the Bundle message is advantageous over SRefresh message.

The two message types serve different purposes.

Bundle messages reduce IP packet processing overhead in the stack.  On 
some platforms, the act of looking in the IP header to determine whether 
it is to be processed locally or not (by comparing destination address 
and looking for the router alert option) can consume significant CPU 
resources.  Bundling messages together reduces this overhead by reducing 
the number of packets sent/received.

SRefresh, on the other hand, has to do with the CPU and bandwidth 
overhead of having to retransmit all Path and Resv state messages.  IMO, 
this factor contributes much more to the RSVP's scalability issues than 
Bundle messages do.

If you set the "RR capable" bit in your common header, then you must be 
prepared to support both types of incoming messages.  You do not have to 
generate both as outgoing messages, however.

> 2. RFC 3209 section 5 Hello extn states that the Hello message can be
> included in the Bundle message. The usage of hello is for rapid node failure
> detection, wherein the Bundle message is for reducing the refresh overhead.
> Eventhough thousands of refreshes are sent to the neighbour there will be
> only one hello message sent to the neighbour.  Also the delay in hello being
> sent can result in the other node to assume the peer has reset.   Is there
> any specific reason behind the hello messages being bundled.

Just generality.  Any message, other than another Bundle, may be 
bundled.  It doesn't say you have to do this, though.  Personally, I 
agree with you - that you would not be able to get the rapid response 
necessary if Hello messages are bundled.

A router receiving RSVP messages may choose to prioritize messages in 
the IP stack, in order to allow Hellos to be processed ahead of other 
messages.  It may also choose to implement Hello in a line-card's 
firmware, in order to improve response time.  Including Hello in Bundle 
breaks both of these optimizations.

> 3.  In RFC 2961 section 4.5 states that
> 
> "If a Path
>    or Resv message contains the same Message_Identifier value that was
>    used in the most recently received message for the same session and,
>    for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the
>    message as a state refresh.  "
> 
> With respect to the above statement, I have the following questions.
> 
>    a)  In Accordance to RFC 3209, assume Refreshes with MsgIds (SRefresh
> probably) are going between Ingress/Egress and its immediate neighbour. Also
> the refresh messages carry RRO's.  When  RRO too large for MTU error message
> is received, the Ingress(In case of PATH msg)/Egress(In case of Resv
> message) should have to stop sending RRO's. Now the question being the
> Refresh message without RRO will be send with the same MsgId, which was used
> for the previous session (or) will be a new one.

If the message changes, then you must generate a new message ID. 
Otherwise the neighbor may ignore your changes.  It doesn't matter if 
this is something really significant like a TSpec or something less 
important, like an RRO.

>          Since an implementation on receiving a message with the same MsgId,
> Session and SenderTemplate, if it treats it as the refresh and fails to
> updates the RRO removal indication, the node that generated the error will
> still retransmit the error msg. Which MsgId should be transmitted Old/New.

No.  An SRefresh does not force the neighbor to re-transmit any errors 
that the original message caused.

If the error message was something serious (like bad TSpec or 
something), then corresponding state was never installed - meaning an 
SRefresh of it will result in a NACK (since the message ID doesn't match 
any installed state), and a normal refresh will result in a re-attempt 
to install that state, since there's no way of knowing that the message 
ID was previously used.

If the error message was something that doesn't prevent state 
installation (like an RRO growing too large), then either kind of 
refresh will simply have no effect.  Which is as it should be - why 
should you be continuously spewing out Notify messages?

>   b)  Also in the RRO's flags may toggle because of some local failure
> detection & recovery process. In these cases the MsgId Should be a Newly
> generated/Old one being retransmitted..

Again, if you are changing any part of the message, then you must 
generate a new message ID.  If you don't then your changes may be 
ignored by the router that receives the message.

-- David