The MPLS WG Archive

["Abes, Andi" <aabes@quarrytech.com>]

Dimitry,


If I understand your point -
An ingress can choose a seemingly randon value to 
put in the SESSION object's extended Tunnel ID.

Then, no - this is not the point.
The bypass draft suggest using exactly the same SESSION
object - including the extended Tunnel ID, but 
using a different IP address in the SENDER_TEMPLATE -
meaning - 
creating a new sender in the same session for the backup
tunnel, but the original and the backup tunnels all
belong to the same SESSION.

If you think about it - at points in the network
where the backup and original happen to co-exist -
no "double-booking" will occcur, since the resources
can be shared among different senders in the same tunnel.

If the SESSION object were modifed in any way, like
changing the extended tunnel ID - this would not work -
and resources would have to be reserved for both the original
and backup tunnel.

Andi.








> -----Original Message-----
> From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
> Sent: Friday, April 14, 2000 3:09 PM
> To: Abes, Andi; Dimitry Haskin; Eric Gray
> Cc: mpls@UU.NET
> Subject: RE: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> 
> 
>  
> > 
> >  Back to reality, draft-swallow-rsvp-bypass-label-00.txt
> > > provides an example
> > > of different ingress nodes using the same session objects
> > > including the
> > > extended tunnel id for association of backup LSPs with LSPs
> > > being backed up.
> > >
> > >
> > 
> > 
> > Dimitry,
> > 
> > I was looking for the refrence you gave, but the only
> > thing I found was an example discussing using different IP addresses
> > in the sender_template, not in the session.
> > 
> Isn't it the point?
> 
> > (end of section 3.1)
> > 
> >    We therefore propose that backup tunnels be identified 
> as follows.
> >    The SESSION object and the LSP_ID are copied from the LSP tunnel
> >    being backed up.  The IPv4 tunnel sender address is set to 
> > an address
> >    of the PLR node.  If the head-end of a tunnel is also 
> acting as the
> >    PLR, it must choose an IP address different from the one 
> > used in the
> >    SENDER_TEMPLATE of the original LSP tunnel.
> > 
> > 
> > Did you mean something else ?
> > 
> No, this is it.
> > 
> > Andi. 
> > 
>