Re: comments on the draft of LSP hierarchy

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Lucy,

> > > 1) When LSP is used for Client/Server Network: the server network sets
> > > LSP as private link with one or more client IGP instances; When LSP
> > > is used as routing adjacency: the network sets LSP as non-private link
> > > with routing adjacency. Is this correct?
> >
> > I think that if the link is private, there is no need and possibly no
> > meaning to set a client IGP instance. Setting an IGP instance implies 
> > that
> > the link is to be advertised in some IGP instance, and a private link 
> > will
> > not be advertised.
>
> [Lucy:] I though that signaling is within an IGP (say IGP A). So if
> signaling a LSP for client/server network (say IGP B), RSVP needs set 
> action
> as private link (not adv in IGP A), FA, and lists other IGP instances (IGP
> B).  It seems my understanding is not correct.
> Are you saying that RSVP signaling is not tight to an IGP instance? 
> Without
> using private link indication, how does the LSA of IGP A know if it should
> advertise in IGP A or not?

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.

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.

If the link is to be advertised in a separate instance of an IGP (perhaps an 
IGP that advertises links in another network layer) then the IGP instance is 
indicated in the signaling message used to set up the LSP as described in 
this draft.

If the link is not to be advertised (i.e. is a private link) then you do not 
include the IGP instance because it is not needed.

> > > 3) A component link in a link bundle has component link identifier. 
> > > This
> > > identifier is the link ID that is advertised in LSA. Is that correct?
> >
> > Section 2.4 says...
> >
> >    When an LSP is to be used as a component link of a link bundle, the
> >    LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
> >    the bundle is addressed and used, and a new TLV indicates the
> >    component link identifier for the link that the LSP creates.
> >
> > Only the component 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
> > inormaiton is coordinated by some other means.
>
> [Lucy:] If component link identifier is used locally, why does it be
> advertised in the IGP?

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.

> > > 4) In section 3.3, it states:
> > >
> > >   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
> > >   object is set, the other fields of the object apply to the link
> > >   bundle itself. That is, the interface identifiers (numbered or
> > >   unnumbered) and the other flags in the Actions field apply to the
> > >   link bundle and not to the component link that the LSP will form.
> > >
> > >   Furthermore, the IGP Instance Identifier TLV (if present) also
> > >   applies to the link bundle and not to the component link.
> > >
> > > It seems odd way to set actions for link bundle. Should we first set 
> > > the
> > > link bundle with the action, then add component link to the link bundle
> > > without action?
> >
> > The issue is that the link bundle itself is not signaled. Only the
> > component links correspond to LSPs that are signaled. Thus,
> > when the first component link is signaled, there is no link bundle
> > in existence.
>
> [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.

> 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.

> > > 6) For CTG scenarios, we create a set of LSPs to form a single 
> > > composite
> > > link to client/server network. We can first create a composite link as 
> > > a
> > > private link with one or more client IGP instances with (at least one
> > > component link); then individual component link can be added to and
> > > removed from the composite link. Component links are also private link
> > > (different from component link in link bundle) and have different TE
> > > properties. We can also create composite link for routing adjacency
> > > (single IGP case). We need some extension to cover these scenarios.
> > > Could we consider adding this into the document?
> >
> > I believe that the mechanisms in the hierarchy bis draft will be
> > applicable to the creation of LSPs that are used as components of
> > CTGs. In my view (as an author) it would be premature to add this
> > to the draft at this stage as it would create a normative reference to
> > the CTG work which has not yet been adopted by any working group
> > and is bound to take some time to complete.
>
> [Lucy:] Operator want to implement CTG soon and hope the framework and
> requirement draft can be completed soon. Although CTG can be manually
> configured at beginning, it would be nice to have an GMPLS way to 
> configure
> it as well.

Yes. I agree.

Hence my proposal below.

> > My preferred approach is that the hierarchy bis draft creates the
> > framework and a registry of actions carried in the flags field (see
> > section 5.2).
> > Any new work, such as your CTG work, can then request the
> > allocation of a further bit and can define the behavior if the bit
> > is set.
>
> [Lucy:] Thank you for the suggestion.

Regards,
Adrian