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

Re: Progressing the three inter-domain I-Ds



Hi Peng,

On Jan 13, 2007, at 9:55 AM, Peng He wrote:

Hi,

Sill about the the third doc:

1. in the "3.1.  Common assumptions" part, it is assumed that
"Boundary LSRs are assumed to be capable of performing local path
computation ..." . So I guess that ABR or ASBR has the function (or
part of) of PCE.

2. My understanding to Dimitri's questions:
I believe there is flooding here but only within the domain that the
ASBR belongs to.

Right.

So now a domain includes non-ABSR LSRs and ABSR LSRs
and the links among them, AND the inter-domain links originating (not
terminating) from the ASBRS of this domain. Tthe flooding is among
these LSRs, but not between domains. So, it is still can be considered
as intra-domain flooding and it happens when the TE info changes I
guess.


This is right.

Example:

<---- AS 1 --->                    <--- AS 2 ---->
                    ASBR1----ASBR2

ASBR1 advertises in AS1 the links that belongs to AS1 + the ASBR1- ASBR2 links.
Same thing for ASBR2.

3. The purpose of the above is to "improve the chance of successful
signaling along the next AS in case of resource  shortage ..." I
understand this, I just want to mention that it seems only true in
theory and the practical effect is not so good as expected. I
simulated this years ago when we extended DCR into inter-domain case
and just no encouraging results found.

It of course depends of the assumptions that you used in your simulations (topology, TMs, ...) but flooding that piece of data can only improve the success rate of course. To what extent ? That depends of a few parameters. For example, if your Inter-ASBR are over- provisioned, that won't help since the cause of CAC rejection is not likely to be because of insufficient bandwidth on your links but there are certainly cases where this can happen, in which case this will help.

Thanks.

JP.


Regards,
Peng


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



On 1/13/07, Dimitri.Papadimitriou@alcatel-lucent.be
<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.

- 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