[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)
Igor Bryskin wrote:
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
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
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
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
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"
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
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
----- Original Message -----
From: "Kireeti Kompella" <email@example.com>
Sent: Tuesday, May 24, 2005 4:49 PM
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)
This starts a two week CCAMP WG Last call on:
Please send your comments to the list (preferably) or to the authors
latest by June 7, 23:59 GMT.
---------- Forwarded message ----------
Date: Mon, 23 May 2005 15:39:15 -0400
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts
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