The MPLS WG Archive

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

Dimitry,


But in this case the initiator of the backup tunnel
is not an igress LSR for the LSP, if you make that 
argument - than each transit LSR would have to replace
the SESSION object.


Andi.


> -----Original Message-----
> From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
> Sent: Friday, April 14, 2000 4:33 PM
> To: Abes, Andi
> Subject: RE: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> 
> 
> Andi,
> 
> I believe the contention was if the same address could be used as an
> extended tunnel id by different LSRs. So the point was that it could. 
> 
> ----------------------------------------------------------------------
> Dimitry Haskin
> Lucent Technologies Internetworking Systems
> 
> 
> > -----Original Message-----
> > From: Abes, Andi [mailto:aabes@quarrytech.com]
> > Sent: Friday, April 14, 2000 4:05 PM
> > To: Dimitry Haskin; Abes, Andi; Eric Gray
> > Cc: mpls@UU.NET
> > Subject: RE: FW: I-D
> > ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> > 
> > 
> > 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. 
> > > > 
> > > 
> > 
>