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

From: Kireeti Kompella <[email-masked]>
Date: Tue, 24 May 2005 13:49:27 -0700 (PDT)

Hi All,

This starts a two week CCAMP WG Last call on:
draft-ietf-ccamp-inter-domain-framework-02.txt

Please send your comments to the list (preferably) or to the authors
latest by June 7, 23:59 GMT.

Thanks,
Kireeti.
-------

---------- Forwarded message ----------
Date: Mon, 23 May 2005 15:39:15 -0400
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Framework for Inter-Domain MPLS Traffic Engineering
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-inter-domain-framework-02.txt
	Pages		: 19
	Date		: 2005-5-23

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 27 May 2005 13:58:38 -0400

Hi,

I have several comments on the document.

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

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.
Thus, the abstract:

   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

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)

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.

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

Igor

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 29 May 2005 09:54:24 +0200

> MRN does not cover nested domains, ITU hierarchical routing does. This is a

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

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

> case when an H-LSP created in one domain is advertised as a TE link into a

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"

> 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

>>A New Internet-Draft is available from the on-line Internet-Drafts
> 
> directories.
> 
>>This draft is a work item of the Common Control and Measurement Plane
> 
> Working Group of the IETF.
> 
> .

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 30 May 2005 08:33:15 -0400

Dimitri, see in-line.

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>; <[email-masked]>
Sent: Sunday, May 29, 2005 3:54 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)

> at section 5.1.7 of MRN that provides you an example if this can help

IB>> I think we have a problem with the definition of a nested routing
domain and this draft is actually a good place to provide such definition.
Here is from MRN 5.17:

In calculating the path for the PSC-LSP, the
        TE database is filtered to include the link, both ends of which
        include only PSC. In this way hierarchical routing of the PSC-
        LSP and TDM-LSP is done by using a TE database filtered with
        respect to switching capability. The hierarchical routing IHMO is
not about filtering TED with respect to switching capability. The computing
entitity in the containing domain cannot do this because it has zero or
limited TED information about nested domains. In my view nesting of routing
domains and nesting of network regions or layers have nothing in common. For
example, nesting of routing domains may happen within a single (say, IP or
ATM) layer.

> discussion point here is about the control plane instance and

IB>> Despite that you quote my own words I have no idea what you just said
:=) I just want to remind you that in Minneappolis we had a lengthy
discussion (you and Arthi took part in it as well as the authors of LSP-HIER
Yakov and Kireeti) about FA and hierarchical LSPs. We all seemed to agree
that Forwarding Adjacency (FA) is unfortunately confusing name for a TE link
that does not require direct IGP adjacency between its ends for control
plane connectivity, that, although H-LSPs and FAs often come together, they
do not have to relate to each other. The results of this discussionis are
reflected in
www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
, section 3.9

> reflect this since it makes use of the term "hierarchical LSP"

IB>> See above

> notion of nesting when considering an LSP segment

IB>> And I repeat again that FA has nothing to do with the nesting

Igor

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 30 May 2005 13:52:35 +0100

Hi Igor, Dimitri,

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

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

> > 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)
>
> - 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?

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

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Mon, 30 May 2005 17:33:53 +0200

Igor Bryskin wrote:

[snip]

>>>MRN does not cover nested domains, ITU hierarchical routing does. This
>>>is a hole in (G)MPLS TE
>>

i don't think you have quite understood the example in the ref'ed 
section, now as you are moving the debate to hierarchical routing the 
response to your question is already detailed in the ason req. document 
section 4.2 - no need to repeat things all over -

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

i am not discussing this i just want to highlight that from a data plane 
perspective relationship is the same, the section could have been called 
LSP nesting but introducing the distinction between FA's and non FA's 
based on the control plane relationship

[snip]

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

i don't understand your comment the document says "LSP segments MAY be 
managed as FAs" it could simply add "... or any suitable methods for 
making these segments usable by nodes not being the head or the tail-end"

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 30 May 2005 13:42:30 -0400

Adrian,
See my comments in line.

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Dimitri Papadimitriou" <[email-masked]>; "Dimitri
Papadimitriou" <[email-masked]>; "Igor Bryskin"
<[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>; <[email-masked]>
Sent: Monday, May 30, 2005 8:52 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)

> 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

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
> doesn't define nesting. Nesting is the process of carrying one LSP within

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

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

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.

> how hierarchical LSPs are used.

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

The difference is entirely in the data
> But, please note (again) that we are not dealing with nested domains.

IB>> This is actually has nothing to do with nesting domains.

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

>    non-packet switching technologies.

IB>> Sounds good.