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