Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)

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

Hi Igor, Dimitri,

> > Section 1.1 Nested domains:
> >
> > For further consideration of nested domains see [MRN]
> >
> > MRN does not cover nested domains, ITU hierarchical routing does.
> > This is a hole in (G)MPLS TE
>
> not sure to understand your comment here, in particular when
> considering "switching capability domains" - i suggest you take a
> look for instance at section 5.1.7 of MRN that provides you an
> example if this can help understanding

I also don't understand Igor's point.

The point about nested domains is that you may represent an entire domain
as a node or a link (depending on your favorite aggregation technique)
within the nesting domain. Traversing a nested domain is a good candidate
for hierarchical LSPs. Multi-region and multi-layer networking are usually
associated with nested domains.

But this I-D deliberately does not consider domain nesting. It is
initially targeted at the TE problems of multi-area and multi-AS while
keeping the door open for further developments into multi-layer in the
future. Note that although areas are a nested concept, there case of
traversing a nested area is limited to disconnections in area 0 and the
use of virtual links.

So, this I-D is aiming to solve today's problems, and we might well expect
future work to examine tomorrow's problems.

> > Section 2.1 LSP Nesting
> >
> > FA and FA-LSP are not accurate terms for describing LSP nesting,
> > which is using an LSP created in one network layer as a data link
> > in other layer(s).
> > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised
> > as a TE link, the link is not necessarily FA, that is, it may require
> > direct IGP adjacency between its ends to provide necessary control
> > plane connectivity.
>
> note: a hierarchical LSP does also translate as (using your words) "LSP
> created in one network layer as a data link in other layer(s)" the whole
> discussion point here is about the control plane instance and
> relationship -

I'm sorry, but Igor seems to be re-defining LSP nesting as "using an LSP
created in one network layer as a data link in other layer(s)." There may
be some mileage in this by forcing the layering PSC1...PSC4, but this
doesn't define nesting. Nesting is the process of carrying one LSP within
another.

I suggest re-reading section 2.1. It discusses both FAs and hierarchical
LSPs, and makes the point that a hierarchical LSP might (or might not) be
used as FA LSPs.

> >    Note also that the IGP/EGP routing topology is maintained
> > unaffected by the LSP connectivity and TE links introduced by FA LSPs.
> > That is, the routing protocols do not exchange messages over the FA
> > LSPs, and such LSPs do not create routing adjacencies between routers.
> > is not correct in the case when an H-LSP created in one domain is
> > advertised as a TE link into a different domain
>
> so, the document is consistent from that perspective, FAs are not used
> for exchanging routing informations - but the previous paragraph must
> be reflect this since it makes use of the term "hierarchical LSP"

I am lost!

Igor says that the text he quotes is wrong if "FA LSP" is replaced by
"H-LSP". But the whole point of the text is that it does not say "H-LSP"!
Is there anything wrong with the paragraph as it stands?

The previous paragraph, as Dimitri points out, mentions hierarchical LSPs.
It says that a hierarchical LSP might or might not be used as an FA LSP,
so I don't see what additions or changes are required.

If you asking for clarification that it is easy to advertise a
hierarchical LSP as a TE link and operate it as a routing adjacency (i.e.
set up a virtual link) then that is fine, and I would welcome some
proposed text. We should note, however, the considerable dangers of
establishing IGP adjacencies across virtual links.

On the other hand, I feel that your issues with the use of the term FA are
based largely on you thinking in terms of nested domains rather than
contiguous domains.

> > Section 2.3 LSP stitching
> >
> > Again, a stitching segment created in one domain and advertised as
> > a TE link into a different domain is not an FA, it is just a
> > "regular" TE link not distinguishable from a TE link supported by
> > static data link(s)
>
> indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..."
> - but not for the reason you have indicated - simply because there is
> no notion of nesting when considering an LSP segment

Consider, please, how stitching is used within the control plane. There
is, I contend, no difference between how stitching segments are used and
how hierarchical LSPs are used. The difference is entirely in the data
plane where, as Dimitri correctly states, there is no notion of nesting.
We could go further and point out that for stitching, regardless of the
bandwidth actually used, once an end-to-end LSP makes use of a stitching
segment, the whole capacity of the corresponding TE link becomes
unavailable.

I assume that the only sentence in this section that you have issue with
is...
    LSP segments may be managed as FAs and advertised as TE links.

Igor says that the a stitching segment created in one domain and
advertised as a TE link into a different domain is just a "regular" TE
link not distinguishable from a TE link supported by static data links. I
agree, and I don't see anything written in the I-D that contradicts this.
But, please note (again) that we are not dealing with nested domains. So
the question of advertisement from one domain to another is very much
moot.

I would suggest that the same issues present themselves in stitching as
exist in hierarchical LSPs. Do you advertise as a TE link? Do you
establish a routing adjacency or just a forwarding adjacency?

> > Section 3.3 Domain Boundary Computation
> >
> > I'd like to see a clause here stating about necessity of avoiding
> > loops with the LSP head segment during domain boundary path
> > computation and describing some mechanisms how this could be achieved.


I think it would be appropriate to highlight the danger of loops in domain
boundary computation. We might also note that such dangers only exist in
non-linear (i.e. mesh) domain topologies, and even then, only when the
domain sequence (expressed as the sequence of domain boundaries) has not
been supplied in the ERO. It would not be appropriate to specify solutions
in this I-D, but it would be a good idea to suggest the scope of such
solutions.

Would you like to suggest some text?

> > Section 5.10 Applicability to Non-Packet Technologies
> >
> > I'd like to see in this section a statement saying that earlier
> > described FRR does not work well in non-packet environments and
> > other techniques should be considered for inter-domain service
> > recovery. One of such techniques is the segment recovery, which
> > IMHO works equally well in packet and non-packet environments

Note that section 5.4 does not endorse FRR. What it says is that FRR
exists and works, and must continue to work in the inter-domain case.

Further, please note the final paragraph of section 5.4 which seems to
say what you want said.

I will qualify the definition of FRR in section 5.4 to show that it is
for packet-based LSPs. It now reads...
   MPLS Traffic Engineering Fast Reroute ([FRR]) defines local
   protection schemes intended to provide fast recovery (in 10s of
   msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node
   failure.

In section 5.10 I will add the following paragraph as para 2...
   On the other hand, some problems such as Fast Re-Route on domain
   boundaries (see section 5.4) may be handled by the GMPLS technique of
   segment protection [SEG-PROT] that is applicable to both packet and
   non-packet switching technologies.

Thanks,
Adrian