[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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.
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.
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.
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