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

["Igor Bryskin" <ibryskin@movaz.com>]

Adrian,
See my comments in line.

----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Dimitri Papadimitriou" <dpapadimitriou@psg.com>; "Dimitri
Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>; "Igor Bryskin"
<ibryskin@movaz.com>
Cc: "Kireeti Kompella" <kireeti@juniper.net>; <ccamp@ops.ietf.org>
Sent: Monday, May 30, 2005 8:52 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)


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

IB>> Not just that. Also an ability to compute path on an entity within
containing domain that traverses the nested domain(s) (with no or limited TE
visibility) and possibly comes back to the containing domain with full
visibility

> Traversing a nested domain is a good candidate
> for hierarchical LSPs. Multi-region and multi-layer networking are usually
> associated with nested domains.

IB>> Sorry, this is not true. Nesting of domains can happen within a single
layer, like ATM, for example. PNNI handles this because it takes advantage
of hierarchical routing, that does not exist in (G-)MPLS TE based on IGP
extensions

>
> But this I-D deliberately does not consider domain nesting.

IB>> That is exactly my point - you've got to define or provide a reference
to what you explicitly claim you do not consider.
So far, you look like using multi-region/multi-layer networking and
hierarchical networking interchangably,and I have a problem with that.

 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.

IB>> Sounds pretty loose to me. Where does this definition come from? What
exactly I am re-defining?

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

IB>>I can see that you are lost completely because I am saying quite
opposite. My point is that the word "FA" should not be used in this document
at all, it should be replaced with H-LSP or S(stitching)-LSP. This is
because it makes little sense to advertise H-LSPs and S-LSPs into the same
domain where they were created, and when they are advertised into differnt
domains they are not FAs already :=), that is, they require direct IGP
peering within the domains they are advertised, hence, they are just
"regular" TE links not distinguishable from TE links supported by static
links.

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

IB>> My comments are based on the discussions with the authors of LSP-HIER
(Yakov and Kireti) regarding FAs and H-LSPs and I'd appreciate if they
correct me if I am wrong, but my understanding is that they interpret the
notion FA differently compared how it is used in your document.

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

IB>> Agrreed. My point was that none of them are FAs.

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.

IB>> This is actually has nothing to do with nesting 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?
>

IB>> Yes, I can do it. Note, that just excluding the RRO of the head segment
won't do the job.

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

IB>> Sounds good.

> Thanks,
> Adrian
>