Subject: Re: RFC2961 clarification

From: "Hong Liao" <[email-masked]>
Date: Fri, 10 Jan 2003 10:22:25 -0500

Hi,

I think you might misunderstand my question.

I did not say the spec was wrong.  I just want to make sure the destination
and source address mentioned in the Srefresh msg is the src or destination
address in the ip header of the Srefresh msg or in the object (Message_Id
SRC_LIST, or MESSAGE_ID MCAST_LIST object.) of the Srefresh msg.  I just
need to clarify and confirm this.

Can someone give me the idea?  Since the spec was not very clear about
this.

Julia

                    David Charlap                                                                                      
                    <David.Charlap@ma        To:     [email-masked]                                                       
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                                        
                                             Subject:     Re: RFC2961 clarification                                    
                    01/09/03 05:08 PM                                                                                  

Hong Liao wrote:
>
> In spec RFC2961, Section 5.2
>
> 'Srefresh messages carrying Message_Identifier fields corresponding to
Path
> state are normally sent with a destination IP address equal to the
address
> carried in the corresponding SESSION objects.'
>
> Here the destination ip address and source ip address mentioned in the
> following paragraph is the one in srefresh ip header or in the Srefresh
> Message_Id SRC_LIST, or MESSAGE_ID MCAST_LIST object.
>
> I think it means the source and destination address in the ip header,
can
> anyone help me to confirm this?

The RFC is correct.  The SESSION address should be the destination, and
router alert should be used in order to enable the next-hop to intercept
this message.  This is required for multicast sessions, since the actual
next-hop addres is unknown.

For the subset of RSVP that is used by MPLS at this time, you may also
use the next-hop address in the IP header (without router alert.)  Note
the second half of the paragraph your cited:

     ... The destination IP address MAY be set to the RSVP next
     hop when the next hop is known to be RSVP capable and either
     (a) the session is unicast or (b) the outgoing interface is
     a point-to-point link. ...

This should be applicable for most current MPLS implementations.  It may
actually be applicable to all implementations, since I've never heard of
any means for running LSPs over broadcast links.

-- David