RE: comments on the draft of LSP hierarchy

[Lucy Yong <lucyyong@huawei.com>]

Hi Adrian,

Thank very much for the explanation. See below.

Regards,
Lucy

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Tuesday, December 09, 2008 4:51 AM
> To: Lucy Yong; shiomoto.kohei@lab.ntt.co.jp; ccamp@ops.ietf.org
> Subject: Re: comments on the draft of LSP hierarchy
> 
> Hi Lucy,
> 
> > I study through this draft and appreciate that you specify many
necessary
> > MLN scenarios that LSP can be used for. Some of them can apply to CTG
> > (composite transport group) scenario. Here are some clarification and
> > questions:
> >
> > 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?

> > 2) Should section 2.2 add one more categories: -LSP is used as a
component
> > link in a link bundle? The doc. is described it but not considers it as
> > category.
> 
> Good catch.
> The overview text was not updated to reflect updates to the main body.
> I will update.
> 
> > 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? 
> 
> > 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.
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. 

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? 
> 
> > 5) LSA should not advertise LSP used as private link. Should this be
> > explicitly stated in section 3.4?
> 
> OK.
> I'll add this to the definition of a private link in section 1.1.3.
> 
> > 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.
> 
> 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. 
> 
> Cheers,
> Adrian
>