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

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

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 -

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

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



Igor

----- Original Message ----- From: "Kireeti Kompella" <kireeti@juniper.net>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, May 24, 2005 4:49 PM
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)



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: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
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





.