IDPR as a Proposed Standard

[[e-mail]]

Here is my response to Deborah's comments
>
>Following are points of Yakovs that I DISagree with. There are
>actually many questions and issues that Yakov raises  that i think are
>very important and that I AGREE with, but it is more importnat (fun)
>to talk about the things we dont agree on :}

     To provide a balanced picture, I would appreciate if you'll
     point out to the issues you and I agreed. I think it is
     as important to articulate the issues on which there is
     an agreement, as on the issues on which there is a disagreement.

>
>1. I believe i could find a quote in a paper by Dr. Rekhter and his
>illustrious colleagues :}  that explains why you need/should have
>source demand routing to support efficient, fine-grain, unpredictable,
>or source-specific policies. So I am confused why you keep questioning
>"Marthas Motives" for wanting to test a protocol that is a first
>attempt at source demand routing.

  I did not find anything in my first comment that even remotely
  resembles "questioning "Martha's Motives" for wanting to test
  a protocol that is a first attempt at source demand routing". That is
  a misrepresentation of my statement !!!

  To prove this, here is my original comment where I asked VERY specific
  technical questions that have NOTHING to do with "testing a protocol
  that is a first attempt at source demand routing":

    Can you provide any technical details that would elaborate on why
    "hop-by-hop message forwarding does not provide this assurance"
    Likewise, would you please elaborate more on why source-specifie
    is "the only way to gain the forwarding control required
    to true policy-based routing".

    By the way, what is the "true policy-based routing" ?

>
>2. your complaint about idpr being inefficient for small number of
>data messages is also true for TCP....if your point is that there
>should be an option to heave explicit source route instead of
>insisiting on setup, then i expect if you just say that everyone would
>agree!!! That does not mean that you never want to do setup and that
>it is not worth experimenting with a first version of a setup protocol

  I think Tony Li said enough in his response.

>
>3. why are you nitpicking about this issue of defining what a backbone
>or transit is. what is the issue. ?

  I want to understand what are the basic assumptions, and what
  are the implications of violating the assumptions.

>
>4. Of course supporing new types of service requires more than just
>changes to routing. but when the whole networking community talks
>about tos, they talk about the piece of the problem they ar eworking
>on. And they dont give numberrs predicitng what percentage of the
>hosts or traffic will use it. Why is that kind of crykstal ball needed
>here? the whole world agrees that we want to support other QOSs so
>this is one component of that problem.

   I really like your comment about "the whole world agrees...".
   Was it by a poll or by a vote ? :-)

   On a serious note, I've been trying to get the expected IDPR clientele
   and the percentage of that clientele. That is important in order
   to understand the impact of IDPR on the overall infrastructure.


>5. IDPR does NOT assume a particulakr charging model. The archiecture
>leaves room for charging model info to be distributed in updates when
>standard syntax and semantics is defined for various charging models,
>then this can be taken into account in route computaton.

   I think Tony Li comments on extensibility in IDPR should be taken
   seriously. I think that a model where you'll have an unconstrained
   prolifiration of of charging schemes needs to be examined very
   carefully with respect to its feasibility before putting functionality
   in a protocol to support such a model. Are we designing a protocol
   whose functionality is constrained by only our imagination ?
   Do we place some sanity checks in the design, to see whether
   our imagination has any roots in reality ?

>
>9. Obviously I agree with the notion that ultimately we dont run IDPR
>as the only interdomain routing protocol. But I dont see why that
>means we stop experimenting with IDPR as our current prototype of ak
>source demand routing protocol. Then by the time we go to impleent and
>finalize design of SDR compontnt of unified, we learn from that
>experience.

   I think you are accusing me of something I am not guilty of.
   I did not say a single word about stopping "experimenting with IDPR
   as our current prototype of a source demand routing protocol."

>
>There is BGP and IDRP and i see the justificatoin being similar altho
>of course the urgency for BGP to replace EGP was the primary
>compelling issue there and so it is a poor analogy that Yakov eill
>undoubtedly point out :}

   Yes, I undoubtedly will :-)