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

Re: Progressing the three inter-domain I-Ds

Hello Mach,

I understood that the path compute element(Head-end, ASBR, or PCE)
should  have the inter-ASBR links info to compute an optimal or
near-optimal inter-domain path.

You said "But I think the inter-ASBR link should have AS flooding
scope." What do you mean by "AS flooding scope"? Is it within an AS or
among ASes? If within an AS, then that's the example shown in the
third document and mentioned in Dimitri's questions; if among ASes,
then how many ASes would be enough?

I just guess the contents of inter-AS link info to be flooded seems
easily to be decided (consider it as a special intra-AS TE link with
AS # attached), and might just need a simple document to define it;
the difficult thing is the flooding scope, which might be varied with
different path computing approaches or even the agreement among
operators.  Still seems to me hard to define a standard to rule it.
Or, leave every options open?

Regards,
Peng

On 1/15/07, Mach Chen <mach@huawei.com> wrote:

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