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

[dimitri papadimitriou <[e-mail]>]

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