Subject: comments on the draft of LSP hierarchy

From: Lucy Yong <[email-masked]>
Date: Mon, 08 Dec 2008 16:33:29 -0600

Hi Shiomoto and Adrian,

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?

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.

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?

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? 

5) LSA should not advertise LSP used as private link. Should this be
explicitly stated in section 3.4?

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?

Cheers,

Lucy

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Dec 2008 10:50:37 -0000

Hi Lucy,

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

> link in a link bundle? The doc. is described it but not considers it as

Good catch.
The overview text was not updated to reflect updates to the main body.
I will update.

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

> link bundle with the action, then add component link to the link bundle

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.

> explicitly stated in section 3.4?

OK.
I'll add this to the definition of a private link in section 1.1.3.

> some extension to cover these scenarios. Could we consider adding this 

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.

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.

Cheers,
Adrian

---

From: Lucy Yong <[email-masked]>
Date: Tue, 09 Dec 2008 10:31:02 -0600

Hi Adrian,

Thank very much for the explanation. See below.

Regards,
Lucy

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2008 4:51 AM
> To: Lucy Yong; [email-masked]; [email-masked]
> Subject: Re: comments on the draft of LSP hierarchy
> 
> Hi Lucy,
> 
[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?

> inormaiton is coordinated by some other means.
[Lucy:] If component link identifier is used locally, why does it be
advertised in the IGP? 
> 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? 
> 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.
> further bit and can define the behavior if the bit is set.
[Lucy:] Thank you for the suggestion.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Dec 2008 17:27:19 -0000

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

> [Lucy:] If component link identifier is used locally, why does it be

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.

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

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.

> right? Or we only require the first signaled component link to indicate a

I think that might depend on application.

> distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object?

They have different TLV type values.

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

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

Regards,
Adrian

---

From: Lucy Yong <[email-masked]>
Date: Tue, 09 Dec 2008 17:41:32 -0600

Hello Adrian,

Thank again. See below.

Regards,
Lucy

 [Snipped]
> When an LSP is signaled in RSVP-TE it can be used to create a link in one
or
[Lucy:]  yes. 
> 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]
> 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]
> (and only if?) the bundle/composite link needs to be communicated in
[Lucy:] All the actions are indications for LSP egress point not transit
points, right?
> > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV,
> how
> > to
[Lucy:] where are they specified?

---

From: Lucy Yong <[email-masked]>
Date: Fri, 12 Dec 2008 15:26:14 -0600

Hi Adrian,

I would like to clarify on the use of IGP instance Identifier.

If there is no such TLV listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is
to be advertised in the same instance of the IGP as was used to advertise
the TE links that the LSP traverse, or 
If there are such TLVs listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is
to be advertised in those IGPs in TLV list. In order to advertise in the IGP
as was used to advertise the TE links that the LSP traverses, an TLV has to
be used but just fill value as 0xffffff. 

Is my understanding correct?

I think how client/server network (1.1.6) can apply to inter AS case. In
this case, the LSP is created in server network (IGP A) as inter-AS link
between AS B and AS C. Each end point of LSP connects IGP B and IGP C,
respectively, i.e. one end need to advertise in IGP B and another end
advertises in IGP C. In this case, only ingress end point needs to know its
side IGP identifier so no needs to list IGP B and IGP C in TLVs. But we also
don't want to advertise this LSP in the IGP A. Can we address this case?

Regards,
Lucy

> Sent: Tuesday, December 09, 2008 11:27 AM
> >> > link to client/server network. We can first create a composite link
as
> >> > a