[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: comments on the draft of LSP hierarchy



Hello Adrian,

Thank again. See below.

Regards,
Lucy

 [Snipped]
> 
> I am a bit confused by your question.
> 
> When an LSP is signaled in RSVP-TE it can be used to create a link in one
or
> more other networks.
[Lucy:]  yes. 
> 
> If the link is to be advertised in the same instance of the IGP that was
> used to advertise the links that were used by RSVP-TE when it signaled the
> LSP, then this is a Forwarding Adjacency as already described.

[Lucy:] I would like to better understand client/server network case
(1.1.6). As described, the server network LSP does not form FA because
client and server network run separate instances of the control plane
routing protocols.
Now, I guess "instances of the control plane routing protocols" are
different from IGP instances. (I thought they mean the same before). 
Could you give an example to use LSP_TUNNEL_INTERFACE_ID object for a LSP
that is created in one network and used in another network as a virtual
link? 
> 
> 
[Snipped]
> 
> I'm sorry, I mistyped (that will teach me to try to write emails to you
> while concentrating on ITU-T politics ;-)
> 
> I should have written...
> 
> Only the *bundle* link identifier is advertised by the IGP. The component
> link identifier is used locally (between link end points), but may also be
> present in an ERO and RRO in signaling with the assumption that this
> information is coordinated by some other means.
[Lucy:] Make sense. So without this extension, operator has to configure
component link identifier at link end points. So a component link in a link
bundle is never advertised.
> 
[snipped]
> >
> > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a
> > link bundle first? It can apply to composite link as well.
> 
> You could come up with a way to do that. You should not use LSP signaling
to
> do this - the bundle or composite link should not be known at transit
points
> of the LSP. You might want to use a GMPLS call to achieve this function if
> (and only if?) the bundle/composite link needs to be communicated in
> advance.
[Lucy:] All the actions are indications for LSP egress point not transit
points, right?
> 
> > If we stay as it is, when adding the second component link to a link
> > bundle,
> > RSVP has to make sure all the actions have to be the exact same, is that
> > right? Or we only require the first signaled component link to indicate
a
> > link bundle properties.
> 
> I think that might depend on application.
> 
> > If we want to add a component link in a link bundle to an IGP instance,
we
> > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV,
> how
> > to
> > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object?
> 
> They have different TLV type values.
[Lucy:] where are they specified?
>