draft-dachille: Comments on topology summarization and optimality

["Vishal Sharma" <v.sharma@ieee.org>]

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