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

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

Adrian,

Thanks for taking my comments into consideration.

The text WRT domain boundary path computation I will provide shortly.

Igor

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


> Hi,
>
> Some proposed resolutions...
>
> > > > > 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
>
> The citation is perceived as too definitive. That is, while MRN may cover
> some cases of nested domains, it does not cover all cases.
>
> This will be clarified in the revised I-D.
>
> > > > > 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).
>
> We have established two points.
> 1. Discussion of layering is not material
> 2. The terms FA and FA-LSP are too limiting and should be replaced with
> "TE link" and "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)
>
> As with nesting, the term "FA" needs to be replaced with "TE link".
>
> > > > > 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.
>
> Igor will supply some text that highlights the danger of loops in domain
> boundary computation, and notes 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.
>
> Although sorely tempted, he will not include discussion of solutions!
>
> > > > > 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
>
> Resolved by text suggetsed in previous emails.
>
> Thanks,
> Adrian
>