[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE : draft-dachille: Comments on topology summarization and optimality
Hi JL,
Thanks much for your note, and for confirming that we had
captured your comments correctly.
Your point about virtual links and topology summarization
is well taken. We recognize that the explanations in
Section 4.1 and 4.2, w.r.t. virtual links need to be made
clearer (and we need to think more about whether we require
them). This is a point we have been discussing internally,
and really appreciate your inputs on it.
We will respond to your other comments in the next day or
two, and to this issue a bit later, after we discuss it
further and clarify our thinking on it.
In the meantime, if there are any other inputs you have,
please do let us know.
Regards,
-Vishal
> -----Original Message-----
> From: LE ROUX Jean-Louis FTRD/DAC/LAN
> [mailto:jeanlouis.leroux@francetelecom.com]
> Sent: Thursday, April 22, 2004 11:04 AM
> To: v.sharma@ieee.org; CCAMP
> Cc: Fabio Ricciato; Alessio D'Achille; Ugo Monaco; Marco Listanti
> Subject: 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?)
> >
> >
> >
> >