[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





Adrian - some hints inside to complete this discussion

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.

ok

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.

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

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"

ok

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?

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

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.

ok

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.

ok

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.

i understand - if you refer here to the information that must be supplied by an external "entity" such as to construct the request then the source should be part of this set


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

ok

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"


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.

ok - i understand better now whatt you meant with "strict hops giving abstract nodes representing each domain"


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.

ok

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.

it is probably more specific here - i mean there is indeed a trade-off and as far as my reading goes there is something that must be formalized there is either an explicit mechanism or an implicit mechanism, in the former case confidentiality is also involved in the second optimality (as far as this notion can indeed be provided in a multi-domain environment)


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.

ok

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

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.

ok

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

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

ok

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


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


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


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

i would say that "MPLS TE" does implicitly means the above

Thanks,
Adrian






.