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

Re: draft-dachille: Comments on CAC issues



Hi Vishal,

Your summary regarding the CAC issues that I had raised basically looks
fine. I think for ii) I meant any kind of setup failure, I suspected CAC
failure to be more common due to i). I will also check my notes to see if
there were any other issues and get back to you.

thanks,
-arthi

> Thanks for your feedback on our draft/scheme during the
> Seoul IETF.
>
> As mentioned in the email to the ML and to JL,
> before addressing people's comments, we are summarizing them
> ensure that (a) we rightly understood the comments, and (b) to
> help people on the ML follow and contribute to the subsequent
> discussions.
>
> Upon looking at my notes from our discussions, I see that
> your main comments related to aspects of CAC in our scheme,
> and have summarized them below.
>
> Please let me know if you had any additional comments
> as well. We will take these into account in providing our
> responses, and, later, in updating the document.
>
> Best regards,
> -Vishal
>
> ****************************************************************
>
> i) What happens to bandwidth accounting during path set up?
> Since the border router that is the entry point for the primary path
> into an area/AS is the one that also computes the secondary path, how does
> bandwidth accounting work to minimize CAC failures during the actual setting
> up of the secondary?
> (Note that other nodes in the area would not immediately learn of the amount
> of bandwidth that primary and secondary paths have consumed.)
>
> ii) What happens if the diverse path setup fails due to a
> CAC failure? (Namely, the set up of the second path fails.)
> To what does the scheme default then?
>
> iii) If I recall correctly, you also had a comment on the
> security of such schemes. That is, the problem of hiding info.
> about one area from other (remote) areas.
>
>