[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : draft-dachille: Comments on topology summarization and optimality
Hi Vishal,
This is a correct summary of the discussion we had during the Seoul meeting.
Just one clarification regarding comment iii,
You make the following routing assumption (section 4):
"In the following we will assume that every border router, say B1,
that is directly attached to area X maintains a summarized
topological view consisting of the exact intra-area topology of X
plus several so called ôvirtual linksö. Virtual link are present
between the border routers of area X, say B2 B3 etc., and the
possible destinations: they merely represent external paths to remote
destinations that are reachable through some inter-area path. Virtual
link might be assigned a cost"
The question is how do you perform such TE topology summarization ?
More particularly how do you summarize information on link admin-groups, which basically need to be taken into acount during path computation ? Let's assume that there are N paths between an ABR an a destination, each with a distinct avaialble bandwidth, and a distinct admin group (a path admin group being expressed as a logical AND of the afinities of each link in the path).
You then need to advertise N Virtual links, each with a distinct admin group.
IMHO this does not scale and also compromises one of the main motivations of IGP hierarchy, i.e. the containement of routing information.
This is actually one of the reasons, in the inter-area requirement draft, for precluding such leaking of summarized TE-link information across areas.
Actually you use this virtual topology, in 4.1 and 4.2, to select downstream ABRs. IMHO your JSA approach can work independantly of the method used to select downstream ABRs. Thus, you should IMHO let downstream ABR selection beyond the scope of the draft, and remove all text related to virtual topologies.
Regards,
JL
> -----Message d'origine-----
> De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la
> part de Vishal Sharma Envoyé : dimanche 18 avril 2004 09:17
> À : CCAMP
> Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; Fabio Ricciato; Alessio
> D'Achille; Ugo Monaco; Marco Listanti
> Objet : draft-dachille: Comments on topology summarization
> and optimality
>
>
> Hi JL,
>
> Thanks for your feedback on our draft/scheme during the
> Seoul IETF.
>
> As mentioned in an earlier email to the ML, before we address the
> various points made by folks who gave us their valuable feedback, we
> are summarizing their comments to ensure that
> (a) we rightly understood their inputs :-), and (b) to help
> people on the ML follow and contribute to the subsequent discussions.
>
> After reviewing my notes from our discussions and discussing them with
> my co-authors, I have summarized your comments as below.
>
> If I missed something or did not capture some of your
> questions/comments correctly, please do let us know. We will take this
> into account in providing our responses, and, later, in updating the
> document.
>
> Best regards,
> -Vishal
>
> *********************************************************************
>
> Editorial:
> i) Replace "area" --> "region" throughout, since you cover ASs as
> well.
>
> ii) Note in the draft that the scheme is general and does more that
> merely helping with efficient backup path computation and setup.
>
> Technical:
> iii) The draft needs to make clear what is meant by a virtual
> topology, and what info. is used to create it. This is because it
> seems from a current reading of the draft that the virtual topology
> relies on info. about TE links and their bandwidth, but there is a
> strong requirement not to advertise TE link info. between areas.
>
> iv) How does this approach differ from the PCS/PCE approach? Some
> comparison and contrasting would be useful.
>
> v) You also suggested that one needn't be confined to carrying only
> one ARO. So for better optimality, one might carry multiple ARO's
> computed for the secondary path, and when the secondary is being set
> up, the ingress for the secondary could select one of the ARO segments
> for traversing it's area. This might lead to a more optimal setup than
> would otherwise be possible.
>
> vi) Sec. 4.1 on inter-area is ok.
>
> vii) However, for the section on inter-AS, you asked "how does the
> scheme computes the set of AS's that the diverse paths will use?"
>
> viii) Do you need the optical island ID?
> Even in the optical case, if one is using IP protocols, it is likely
> that OSFP/IS-IS areas/levels and ASs will be defined, so this then
> becomes the same as the inter-area/inter-AS cases.
>
> ix) Mention that the scheme can work for IS-IS levels as well. (Note
> IS-IS levels can, in turn, have areas.) (One issue here is how does
> one identify IS-IS levels?)
>
>
>
>