Re: Progressing the three inter-domain I-Ds

[Mach Chen <mach@huawei.com>]

Hi Peng,

I means that no matter what kind of path computation methods(Per-domain, BRPC, etc.) we adopt, 
if we want to compute a path spaning mutiple ASes, the compute element(Head-end, ASBR, or PCE)
SHOULD get the inter-ASBR links info.

With respect to the flooding scope and specification of inter-ASBR links info,  we need more discussion.
But I think the inter-ASBR link should have AS flooding scope.

----- Original Message ----- 
From: "Peng He" <peng.he.2000@gmail.com>
To: "Mach Chen" <mach@huawei.com>
Cc: <Dimitri.Papadimitriou@alcatel-lucent.be>; "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
Sent: Monday, January 15, 2007 11:26 AM
Subject: Re: Progressing the three inter-domain I-Ds


Hello Mach,

I am interested in such work. But I am not sure what you said "in oder
to perform  inter-AS path computation, inter-ASBR links fooding is
desired", say, different computing methods might need different
information about the inter-AS links and various flood ranges, and if
not a general method is considered as default, it seems to me hard to
define what exact info should be flooded. Just my personal thoughts.

Regards,
Peng

On 1/14/07, Mach Chen <mach@huawei.com> wrote:
> Dimitri and all,
>
> After reading these docs I also have the same concern with you about inter-ASBR links flooding.
> I think, in oder to perform  inter-AS path computation, inter-ASBR links fooding is desired. But
> such kind of inter-ASBR link info should include more information than "normal" TE links do,
> e.g: the inter-ASBR links info SHOULD still include the peer AS number and peer ASBR router id
> besides those link info which has been specified in rfc3630 and rfc3784.
>
> So I think there need a document to clarify and specify inter-ASBR links flooding. we are considering to
> write such a document. If someone interested in such work, we could cooperate.
>
>
>
> Best regards,
>
> Mach
>
> ----- Original Message -----
> From: <Dimitri.Papadimitriou@alcatel-lucent.be>
> To: "Adrian Farrel" <adrian@olddog.co.uk>
> Cc: <ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
> Sent: Saturday, January 13, 2007 7:49 PM
> Subject: Re: Progressing the three inter-domain I-Ds
>
>
> 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.
>
> - 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
>
> 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 -
>
> 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 ?
> 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
>
>
> 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
>
> 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
>
>
>
>
>
>
>