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

["Adrian Farrel" <[e-mail]>]

Thanks Dimitri,

> some comments on this document:
>
> 1. introduction refers to a separate document - but without much
precision -

Hmmm. There is some difficulty in providing a list which will necessarily
be assumed to be complete.

For the "techniques" (para 3) I propose to add a note to say that
references to these documents are given from the sections that discuss the
techniques.

For the case of GMPLS TE (para 4) I will add a pointer to...
   [GMPLS-AS]    Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
                 Traffic Engineering Requirements",
                 draft-otani-ccamp-interas-GMPLS-TE, work in progress.

> 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 ?

OK, this could be clearer.

The intention is is to give examples of domains and also not constrain
their use. But, we do want to restrict the discussion to non-nested
domains at this point.

So, computational domains might exist within a single area. The reasons
for such domains might be as simple as limited computation power, or
limited computation necessity (for example on a subtended ring).

Maybe it is OK simply to delete the sentence "However, domains of ...." as
this does not add much value.

> 3. section 2 refers to
>
> "Three distinct options for signaling TE LSPs across multiple domains
>     are identified. The choice of which options to use may be influenced
>     by the path computation technique used (see section 3), although
some
>     path computation techniques may apply to multiple TE LSP types."
>
> what are these LSP types ? i think this document is the right place to
> disambiguate the signaling methodology from

That final "multiple TE LSP types" should read "multiple signaling
options"

> 4. section 2.1
>
> "Furthermore, the mapping (inheritance rules)
>     between attributes of the nested and FA LSPs (including bandwidth)
>     may be statically pre-configured or, for on-demand FA LSPs, may be
>     dynamic according to the properties of the nested LSPs."
>
> worth indicating here that even in the dynamic case inheritance from the
> properties of the nested LSP(s) can be complemented by local or
> domain-wide policy rules

OK

> 5. section 2.1
>
> "During the operation of establishing a nested LSP that uses a
>   hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain
> unchanged along the entire length of the nested LSP." the same applies
> for the FILTER_SPEC object and any other object that has an end-to-end
> significance

OK. The point we wanted to make is that the Session remains constant. This
seems to be the most important end-to-end property. But I will extend the
text to say "and all other objects that have end-to-end significance".

> 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?

> 7. section 2.4
>
> could be interesting to have better insight on RRO methods to select
> signaling method "It may be desirable in this case for the choice of the
> various methods to be indicated along the path perhaps through the RRO."

The intention was not to use the RRO to select the method, but to report
the choice that was made. I have cahnged the text to read...
   It may be desirable in this case for the choice of the
   various methods to be reported along the path, perhaps through the
   RRO.

> 8. section 2.5
>
> refers to interoperability but in which sense ? object support or
> functionality

There are two concers as you identify. It is necessary to be backwards
compatible. But a greater concern (for me) exists with the creation of too
many options: that is, if it is acceptable for LSRs to select which
functional components they support, then there is a high risk of
"stnadard" implementations not interoperating. I have clarified this in
the text.

> 9. section 3.2
>
> indeed the destination must be provided but i suggest to indicate the
> corr. object(s) i.e. Session, ERO subobjects, etc.

Ni, I don't think so. The operator does not use Session, ERO or any other
objects. The operator simply fills in information in his GUI, CLI or
whatever.

> 10. section 3.2.1
>
> having full visibility provides the capacity to achieve optimality - at
> least for a given period of time - in brief, it is not a sufficient
> condition

OK.
"is best" was the wrong choice of words.
Changed it to "can be better".

> 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?

> 12. section 3.3
>
> 3rd paragraph is indeed expressing ERO construction per 3209, but then
> how to interpreet second bullet of the alternative presented in section
> 3.2.2.

Don't you just love the ERO processing rules in 3209? :-)

Suppose you have an ERO that says, {strict AS A, strict AS B, loose Bn}
where Bn is the egress.

When we reach A1 in AS A we may *replace* the hop {strict AS A} with the
sequence of hops {A2, A3, ...., An}. This is allowed because these hops
are all within the abstract node {AS A}. In this sense we are not
inserting hops before {strict AS B}.

However, when we arrive at An (the border node) the ERO looks like {An,
strict AS B, loose Bn}. At this point the abstract node {An} is not open
for expansion, and we are not allowed to insert hops before the next hop
which is strict, so we must now move on to B1.

> 13. section 3.4
>
> "The selection of PCE(s) may be driven by static configuration or the
> dynamic discovery by means of IGP or BGP extensions." would it be
> possible to detail in which context BGP PCE discovery would be
> appropriate and the corresponding mechanism applicable

I have views on this, but I think the politically correct thing to do here
is change the text to read...
   The selection of PCE(s) may be driven by static configuration or the
   dynamic discovery.

> 14. section 3.4.2
>
> paragraph 2 discusses (again) optimality issues but in the context of a
> section that speaks about confidentiality - not sure this is the best
> place in the document to do so -

I guess you are refering to the word "best"?

I will delete it as it is superfluous.

> 15. section 3.5
>
> what is the real purpose of this section ? lot of things is said about
> conditions prevailing in multi-domain environments but very few is said
> about what could be a baseline on "optimal multi-domain path" - may be
> worth considering the last paragraph only -

The intention is to point out that optimality by most definitioins is
likely to be degraded by the existence of more than one domain (or at
least the need to traverse more than one domain). The intention is then to
dodge the issue of defining optimality in any generic way.

Thus, as you note, there is no baseline for an optimal multi-domain path.

We can wordsmith the first paragrpah a bit, I think.

> 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.

> 17. section 5.1
>
> if this section is dedicated to re-optmization - and considered as an
> advanced mechanism - details included as part of section 3.4.2 should be
> moved in this section

Why?
3.4.2 is talking about normal LSP establishment.
I think the confusion comes from the text in 3.4.2 that says...
   In this way an end-to-end path may be computed using the full network
   capabilities, but confidentiality between domains may be preserved.
   Optionally, the PCE(s) may compute the entire path at the first
   request and hold it in storage for subsequent requests, or it may
   recompute the path on each request or at regular intervals.
This should really read as follows...
   In this way an end-to-end path may be computed using the full network
   capabilities, but confidentiality between domains may be preserved.
   Optionally, the PCE(s) may compute the entire path at the first
   request and hold it in storage for subsequent requests, or it may
   recompute each leg of the path on each request or at regular
   intervals until requested by the LSRs establishing the LSP.

> 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

> 19. section 5.4
>
> would it be possible to detail the following sentence, in particular,
> when FRR is used in combination with LSP stitching
>
> "The techniques that must be employed to use Fast Reroute for the
>     different methods of signaling LSPs identified in section 2 differ
>     considerably."

Hmmm.
Our aim here was just to flag that FRR does not simply transport itself to
work with hierarchical or stitched LSPs. We wanted to punt on this and
make it the responsibility of the applicability I-D or the signaling
extensions I-D.

I will, however, add a note that...
"In particular, there may be issues protecting the ingress and egress LSRs
of hierarchical LSPs or stitched segments."

> 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".

 > 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.

> 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.

Are there any specific instances of "LSP" which you feel confuse matters?

Thanks,
Adrian