Re: [mpls-linux-general] about tunneling.

[Srinivas R. <ls...@tr...>]

thank you jim,


regards
lsreddy

On Tuesday 26 June 2001 21:09, you wrote:
> On Tue, Jun 26, 2001 at 04:21:43PM +0530, Srinivas Reddy wrote:
> > hello all ,
> >
> > 	i am getting confussion about tunneling. practically in which case we
> > get tunneling. when we get tunneling we have to send Targetted Hello
> > only(please correct me if i am wrong). Can some body guide me in which
> > cases we will create tunnel especially in the case if we use BGP .
>
> I'm not sure if I understand your question but here is an attempt to
> answer it :-)
>
> BTW I hate the term "tunnel" (as in an MPLS tunnel) but since you've used
> it, I will use the term and explain what I mean by it.
>
>
> If we have a signalling protocol set up an LSP to a remote router AND
> the signalling protocol associats the remote router ID with the LSP,
> then we have an instance where "tunneling" is feasible.  In this case
> "tunneling" means that I will treat the remote router as a directly
> connected peer (via the LSP) for the purpose of another protocol
> (signalling OR routing).
>
> Stepping back.  Signalling protocol that setup LSPs and associate router
> IDs are:
>
> RSVP-TE (user is responsible for assigning a "destination" address,
> in this case the destination address should be the remote router ID)
>
> CR-LDP (the FEC could be the remote router ID /32 or the user is
> responsible for assigning a "destination" address, same as for RSVP-TE)
>
> LDP (the FEC is the remote router ID and is normally sent via unsolicited
> mode (ala Juniper))
>
> In any of these cases the result will be an LSP which can be associated
> with the remote router ID (how the association is made varies).
>
> Once that assocaition is made then the remote router is can be considered
> as directly connect (as you would say, a "tunnel" has been created to the
> remote router).
>
> Now a second level of protocols can use this "tunnel".  Examples are:
>
> LDP (requires "tunnels" in both directions and then uses targeted hellos
> to establish an adj.  The resulting session needs to be associated
> with a "tunnel" for the label mappings to be used)
>
> RSVP-TE (the "tunnel" is treated as one hop in an explicit hop list)
>
> BGP (requires "tunnels" in both directions and each side must advertise
> their router ID as the next hop for each NRLI thus BGP can resolve the
> nexthop via the "tunnel")
>
> One note about the second level signalling protocols:
>
> The resulting label allocation made by second level signalling protocols
> are only known by the end point of the LSP.  Thus packet traversing the
> LSPs created by second level signalling protocols have 2 labels on them. 
> The top label is for the "tunnel" LSP and the bottom label is for the
> LSP created by the second level signalling protocol.
>
> I hope this answers your question :-)
>
> Jim
>
> PS In the above example you can replace router ID with "network wide unique
> address that is 'known' to be assocaited with the remote router and is
> still valid even when re-routing occurs due to link failures".  :-)
>
> > thanks in advance
> > regards
> > lsr
> >
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general