Re: comments on draft-ietf-ccamp-inter-domain-framework-02.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Thanks,

I think we are closed down on nearly all of the points.

Adrian

> >>2. introduction
> >>    "However, domains of computational responsibility may also exist
as
> >>    sub-domains of areas or ASs. Wholly or partially overlapping
domains
> >>    are not within the scope of this document."
> >>
> >>how the second sentence should be interpreted wrt to the previous one
?
>
> i would say
>
> "Wholly or partially overlapping domains (e.g. path computation
> sub-domains of areas or ASs) are not within the scope of this document."

OK

> >>6. section 2.2
> >>
> >>this notion of contiguous LSP is unclear, if i correctly understand
the
> >>definition i can not establish a contiguous packet LSP using PSC links
> >>that are themselves TDM LSPs - why this restriction ?
> >
> > The notion we are trying to convey is that there is a single LSP
> > established from ingress to egress that does not require the use of FA
> > LSPs or stitching.
>  >
> > It is true that you could use hierarchical layered LSPs as you
describe,
> > but if you were to expose this fact, you would be using nested domains
> > (which are out of scope). On the other hand, if you hide this fact (by
> > presenting the TDM LSPs as TE links in the PSC domain) then these are
just
> > TE links and there is nothing special going on.
> >
> > So...
> > We struggled with the words for section 2.2. Every time we visited the
> > text, we deleted more words.
> >
> > Any suggestions?
>
> i was mainly referring to the following sentence "Signaling occurs
> between adjacent neighbors only (no tunneling), and hop-by-hop signaling
> is used."
>
> i think the notion of contiguous LSP is to be defined as 1) LSP for
> which TE links are not represented as FA links and 2) there is no
> incoming signaling flow interruption to trigger an FA link or an LSP
segment

The main point we wanted to make was continuous use of the same
Session/LSP ID along the whole path (i.e. at every LSR) of the LSP. The
points you make are valid, but they don't quite capture what we were
trying to say.

> >>11. section 3.2.2
> >>
> >>i guess the proposed formats are not meant to be exchaustive (would be
> >>worth indicating this)
> >
> > Hmmm. I can certainly make the text more ambiguous, but these were the
> > only two formats (apart from the mixed format as indicated) that we
could
> > come up with. Do you see any further formats for this mode of
visibility?
>
> i asked this because mixing does only refers to partial visibility while
> we can assume learning systems or possibility for having full visibility
> for some domains but not for others in this case "intermediate hops" (in
> the broad sense) would not necessarily represent "domains"

OK. Understood.

> >>16. section 4
> >>
> >>would it be possible to expand on "end-point" reachability information
> >>exchanges - which is at the end the only mandatory information needed
> >>the following "Where any cross-domain reachability and TE information
> >>needs to be advertised, consideration must be given to TE extensions
to
> >>BGP, and how these may be fed to the IGPs. ..." is again focusing on
TE
> >>info processing
> >
> > I'm not sure I get your point.
>
> the sentence under discussion here is
>
> "Where any cross-domain reachability and TE information needs to be
>   advertised, consideration must be given to TE extensions to BGP, and
>   how these may be fed to the IGPs."
>
> it is important to understand what the transposition of inter-domain
> reachability provides as real information before stating we need TE
> extensions to BGP

Indeed. The text does *not* say that we need extensions to BGP. It says
that consideration must be given. That is, if there is a need to advertise
cross-domain reachability and TE information then no new mechanism should
be developed without first considering existing protocols.

Obviously (ah, but maybe it is not so obvious? - so I will add an explicit
statement) the real need for inter-domain reachability and TE informaiton
must be established before doing any work on how to distribute that
information.

> >>18. section 5.1
> >>
> >>" Note also that where multiple diverse paths are applied end-to-end
> >>    (i.e. not simply within protection domains - see section 5.5) the
> >>    point of calculation for re-optimization (whether it is PCE,
> >> ingress, or domain entry point) needs to know all such paths before
> >> attempting re-optimization of any one path."
> >>
> >>the notion of diversity is unclear in this sentence i.e. diverse from
?
> >
> > mutually-diverse
>
> ok - so you mean mutually "resource disjoint" LSP

Then we have to define "resource" :-)

I think we understand each other. I will find some words that makes the
I-D clearer.

> >>20. section 5.5
> >>
> >>would be interesting to know what is meant by "easier" in the
following
> >>sentence "The problem is generally considered to be easier and more
> >>efficient when the diverse paths can be computed 'simultaneously' on
the
> >>fullest set of information."
> >
> > Replaced with "less complex".
>
> i would simply say "The problem can be resolved more efficiently (e.g.
> avoid so called "trap problem") when mutually resource disjoint paths
> can be computed 'simultaneously' on the fullest set of information."

Thanks.

> >> it would also be interesting to know what is meant by "Domain ID" in
> >> the context of the following sentence "The former might be identified
using
> >>a combination of domain ID and an SRLG ID that is administered by the
> >>domain." in particular if SRLGs are confined within a domain adding a
> >>domain id to the SRLG ID would only be useful if SRLG id values are
not
> >>unique across domains but the latter would then be expected to share
> >>that information - is that the intention ?
> >
> > As you note, this case is intended to apply where the constituents of
the
> > SRLG are confined within a domain, but the SRLG is identified with
wider
> > scope than the domain. Thus, either we need administration of SRLG IDs
> > across domains (to make the SRLG ID unique across domains) or we need
the
> > domain ID to form part of the SRLG identification.
>
> agreed & i suggest to formalize this as part of the text even if the
> former alternative is probably difficult to achieve

OK

> >>21. Section 5.8
> >>
> >>the major issue is whether end-points are supportive of the
capability -
> >>this should be highlighted in this section
> >
> > OK
> >
> >>editorial: this document refers to TE LSP and sometimes to LSP is
there
> >>any specific different or just a contraction ? i am asking this
because
> >>in the context of a document that speaks about Traffic Engineering
this
> >>is not necessarily clear
> >
> > Right.
> > I think it is just sloppy editing.
> >
> > The intention is to indicate that we are in the realm of RSVP-TE and
not
> > LDP, so all of the LSPs are really TE LSPs.
>
> the realm of this document is source/constrain-based routing which by
> definition implies the use of a protocol that support these notions

Understood.