Re: Progressing the three inter-domain I-Ds

[Mach Chen <mach@huawei.com>]

Hi Peng,

>----- 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: Tuesday, January 16, 2007 11:17 AM
>Subject: 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 means it's just within an AS, and it's enough for those proposed 
path computation methods, e.g: Per-Domain, BRPC, etc. 

If such inter-ASBR links are flooded among ASes, there would be scalabilty
and confidentiality issues. 

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

Best regards,

Mach