Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt

From: Ken Carlberg <[email-masked]>
Date: Fri, 01 Nov 2002 11:54:37 +0000

> >> 3.1.  Alternate Path Routing
>
> And actually, this "requirement" is one driven by a PSTN-like 
> architecture
> where routing is NOT dynamic and instead is static, configured at call
> setup time.  The Internet does not have that problem so doesn't need the
> above "requirement".

it will probably be easier to take the word "requirement" out of the
section title.  the document is just a framework, and not a requiremnts
document.

> With the IP world's dynamic routing, the above requirement is not 
> appropriate or helpful to achieving better quality connectivity during 
> a calamity. The 9/11 calamity, several earthquakes, and sundry other 
> disasters around the world have shown that dynamic IP routing is nearly 
> impossible to beat.
> To give another example, the Iraqis reportedly used dynamic IP routing
> to keep some of their command & control networks up and working during 
> the Gulf War

right,  but here is a counter argument.  IP routing may still route flows
through a path that has loss that is tolerable to elastic traffic, but
considered intolerable for VoIP traffic.  hence, alternate path 
application layer routing (ala TRIP) may be of help to circumvent this 
duality.

within the context of the framework document, its simply a value added
functionality to be considered.

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 09:41:02 -0800 (PST)

> functionality to be considered.

I think Ran's point, and mine, is that this is not a value add, it's a
value subtraction.  In the real world, this simply won't work.  It's a
Rube Goldberg contraption which no one has any incentive to try to make
work.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 2 Nov 2002 07:08:22 -0500

> Rube Goldberg contraption which no one has any incentive to try to make

My other point is that if the intent really is *application-layer* 
routing,
then that precision was not obvious in my reading of the current text.
Though I do basically share the belief that relying on normal IP dynamic
routing is probably the more successful strategy overall...

Ran

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 08 Nov 2002 13:27:06 +0000

Ran,

> routing is probably the more successful strategy overall...

the intent was to raise awareness to the reader of another form of
routing (application level) and of work being done within a more
constrained context of intra-domain routing (MPLS).  however, neither
is presented as a solution or even approaches that must be taken.  

> Editing several of our documents to have more words like that would be
> generally helpful.  Putting words like "This document only applies to
> operators who choose to offer [x], [y], and [z]." in a scoping paragraph
> at the beginning of a document would also be helpful.

yes, words to this effect will be added to the Framework document.

as for your comments on the status of the Framework draft...

> I think that the "framework" draft is hopeless to edit into
> an IETF-style requirements draft.  

agreed, and just for clarity, was never the intent by the authors

> I think that it IS useful,
> if edited into being an (obviously) purely informational document
> on what might be done and how diverse pieces might fit together.
>
> In my view, this would be published as an Informational status
> document, not standards-track, and would have the word "requirement"
> edited out throughout the document.

right.  as stated previously, the word "requirement" in the draft was
an unfortunate choice and can be easily edited out.  given the charter 
stating that the drafts are to be Informational, that was the original
intent by the authors.

in addition to the above, two other items need to be edited out.
the first is a suggested set of new attributes for TRIP.  the second
is suggested Namespace.Value for SIP.  both of these cross the line 
and becomes too specific as solutions.

-ken