[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)
Dimitri, see in-line.
----- Original Message -----
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Kireeti Kompella" <kireeti@juniper.net>; <ccamp@ops.ietf.org>
Sent: Sunday, May 29, 2005 3:54 AM
Subject: 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
>
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.
> > 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 -
>
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
> > 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"
IB>> See above
> > 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
IB>> And I repeat again that FA has nothing to do with the nesting
Igor
>
> > 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
> >>
> >
> >
> >
> >
> > .
> >
>