Re: Progressing the three inter-domain I-Ds

[Dimitri.Papadimitriou@alcatel-lucent.be]

hi j-p - see inline:





JP Vasseur <jvasseur@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
16/01/2007 15:42
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, 
owner-ccamp@ops.ietf.org
        Subject:        Re: Progressing the three inter-domain I-Ds


Hi Dimitri,

On Jan 13, 2007, at 6:49 AM, Dimitri.Papadimitriou@alcatel-lucent.be 
wrote:

> hi adrian
>
> o) a couple of generic comments on the third doc
>
> - the doc. states applicability to GMPLS but sometimes only ref. 
> MPLS-TE
> signaling further on e.g. section 3.1
>
> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>
> and many others in section 4.
>

ok.

> - the are many comparison with PCE technique along the doc. - well 
> that's
> fine but outside the scope of the document except if the purpose is to
> indicate how different techniques can be combined together and which
> interop issues may result from it
>

Because there are indeed two path computation techniques, it is 
useful to keep these references in order to provide a fair 
comparison. We could of course come up with a separate applicability 
ID, but there are already quite a few related IDs, thus it is 
preferable to keep the text here. I'll double check if there's any 
redundancy though.

[dp] i don't think i found much statements clarifying potential
interop aspects - hence the question becomes rather simple 

either there are prescriptive statements to be provided to ensure 
interop and henceforth these are to be addressed in this document 

or these are not prescriptive and hence an applicability document
would also do the job

otherwise there are no statements (interop is not resulting in any
specific behaviour) and then there is no need to perform any sort
of reference to the PCE technique


> o) a couple of specific comments
>
> end of section 2:
>
> section 3.1: "* The complete list of boundary LSRs along the path"
> -> list of domain identifier e.g. AS numbers also applies here ?
>
> last § of section 3.1 is the most important one, signaling protocol 
> are
> independent of the routing topology itself, i.e. not because a node is
> an ABR or an ASBR that comp. occurs but simply because he has no path
> to reach the next (loose) hop - an intermediate node should still 
> maintain
> capacity to perform such operation
>
> section 3.3 "The path computation
>    technique described in this document applies to the case of a 
> single
>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>    areas or any combination of the above.  For the sake of simplicity,
>    each routing domain will be considered as single area in this
>    document. "
>
> -> not sure to understand the reasoning, at the end these examples 
> must
> remain illustrative and not restrict applicability - all these 
> tutorial
> like material should better go in an appendix -

Not sure why ?

[dp] e.g. the last sentence of the paragraph pointed here above shows
the issue - why this doc considers (from the examples it provides) and
or restricts routing domain (AS) composed by a single area ?


> section 3.1 "In any case,
>    no topology or resource information needs to be distributed between
>    domains (as mandated per [RFC4105] and [RFC4216]), which is 
> critical
>    to preserve IGP/BGP scalability and confidentiality in the case 
> of TE
>    LSPs spanning multiple routing domains."
>
> then Section 4
> "In terms of computation of an inter-AS TE LSP path, an interesting
>    optimization technique consists of allowing the ASBRs to flood 
> the TE
>    information related to the inter-ASBR link(s) although no IGP TE is
>    enabled over those links (and so there is no IGP adjacency over the
>    inter-ASBR links).  ...
> "Thanks to such an optimization, the inter-ASBRs TE link information
>    corresponding to the links originated by the ASBR is made available
>    in the TED of other LSRs in the same domain that the ASBR 
> belongs to."
>
> but after
> "Note that no topology
>    information is flooded and these links are not used in IGP SPF
>    computations.  Only the TE information for the outgoing links
>    directly connected to the ASBR is advertised."
>
> -> can one of the author clarify 1) is flooding involved or not ?

I'll be happy to clarify. The idea is to flood the TE info for the 
Inter-AS link(s). Note that this does not contradict the requirements 
of RFC4216:
(1) Confidentiality relates to the topology of another domain: the TE 
information flooded in a domain is only augmented by Inter-AS links, 
not to any link in another domain.
(2) Scalability: of course, flooding the TE info of a few Inter-AS 
links will not compromise the scalability of the IGP.

> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216

Did I clarify ? If so, I'll add a paragraph in the ID.

[dp] point 3, you flood the inter-AS information "inside the connected 
AS" but what is the flooding scope ? - flooding of a link local info
inside the AS that is terminating that end of the link -

[dp] i think that the optimization provided here holds iff that info
is made available to the head-end area of that AS not only the tail-
end area

>
> o) a couple of edits
>
> section 1:
>
> ABR Router, ASBR Router - redundant R
>
> the most important def. is the "domain" def. which can be found in the
> frm doc but not recorded here this would clarify sentence like
>
> "The mechanisms proposed in this document are also applicable to MPLS
>  TE domains other than IGP areas and ASs."
>
> ref. H-LSP and S-LSP with the appropriate docs
>
> state that inter-domain recovery is going to be addressed in a set of
> specific docs

Thanks for the edits.

JP.

>
> hope this will help,
> - d.
>
>
>
>
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: owner-ccamp@ops.ietf.org
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <ccamp@ops.ietf.org>
>         cc:
>         Subject:        Progressing the three inter-domain I-Ds
>
>
> Hi,
>
> We now have updated versions of the three inter-domain signaling I-Ds:
>
> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> - draft-ietf-ccamp-lsp-stitching-04.txt
> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> Our plan is:
> 1. WG chairs do detailed review over the next couple of weeks
> 2. Editors apply necessary updates
> 3. We hold a WG last call for the three I-Ds together
>
> If you are interested in this work, I suggest that now might be a good
> time
> to remind yourself about the I-Ds, have a good read, and see if you 
> can
> get
> any substantial comments in to coincide with the WG chairs' review.
>
> Thanks,
> Adrian
>
>
>
>