RE: comments on the draft of LSP hierarchy

[Lucy Yong <lucyyong@huawei.com>]

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



> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Tuesday, December 09, 2008 11:27 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,
> 
> >> > 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
>