Subject: RE: [Ieprep] Revised Topologies ID for WG consideration

From: "pat cain" <[email-masked]>
Date: Thu, 2 Jan 2003 18:18:17 -0500

James,

I read the scenarios-02 document. I had a couple of comments and one odd
suggestion.
[I know this is not a WG document (yet). But I figured I'd be nice and share
my comments.]

Comments:
1. I like short IDs. Good job. Very crisp. I hope this one stays short.

2. The four scenarios sound right, but I had problems with section 2.4
"End-to-End-IP".
The picture in 2.4 shows the IP Network as one big blob -- which I interpret
(probably incorrectly) as one network provider. I think this is the easy
scenario. I would suggest that the one blob be shown as two little blobs
with an interconnection, as I expect most of the scenario busters are going
to be in getting different parts of the "Inter"-net to "inter"-work. The
last months of QoS and, now, NAT, on the mail list make me believe that
getting a call across multiple IP networks may not be as easy as one big
'blob', and it really needs to be shown as multiple 'little blobs'.
I don't worry about this as much for the CSN pictures, as getting CSNs to
talk to each other has already been discovered (and maybe standardized), but
I think it will be painful for the multiple provider call across the
Internet. Particularly when one examines control traffic.

The odd suggestion:
3. Would it be useful to add a wee bit of control flow, or ascii-art control
boxes, to the pictures? This may complicate the pictures too much, but as I
walked through the scenarios in my head, I started out with "the call starts
here. And hits this controller. Which opens up an SS7 connection to here...
which must be someplace over here. And that opens a UDP stream to... etc
etc."  I don't expect that we'll do any real detailed call flows in this or
any other document, but we'll make requirements decisions based on some
assumptions about those flows, it may be nice to have them. The reason this
is an 'odd suggestion' is that I can't point out specific things to do to
the pictures, but I think there is some control detail that's going to be
necessary. Unless you think it's to much complication. Maybe just a "X" for
where the call manager et al, if neccesary, goes. ?

Nice document.

Pat
(I return you to the who's got more QoS in their NAT discussion) :)

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Jan 2003 18:12:36 -0600

Pat

comments in-line

>'blob', and it really needs to be shown as multiple 'little blobs'.

An all IP (with no CSN) packet flow (with or without) separate control
planes needed to be named within this WG - this document does this in its
simplest form. While I agree generally that it will not likely be the case
that an actual IEPREP call/session be placed only over a single IP
provider, it is a slippery slope in establishing (or ASCII drawing)
something that represents the e2e IP topology in multi-domain scenarios.
The Internet is implied to be a series of loosely connected IP domains. Are
you asking that this be explicitly stated in section 2.4 for clarity?

>
>The odd suggestion:
>3. Would it be useful to add a wee bit of control flow

This is the topic of another and purposely separate ID coming very soon

>(I return you to the who's got more QoS in their NAT discussion) :)

cheers,
James 

              *************************************
"People generally demand more respect for their own rights than 
                         they are willing to allow for others"

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Jan 2003 14:51:28 -0500

On Thursday, Jan 2, 2003, at 19:12 America/Montreal, James M. Polk 
> you asking that this be explicitly stated in section 2.4 for clarity?

I agree with Pat.

	The document needs to make it VERY clear that the typical scenario for 
any
traffic across the global Internet involves more than one ISP and 
several different
administrative domains.  A minimalist example along these lines would 
look
something like this:

		Source Domain ("A")
		Source's ISP ("B")
		Destination's ISP ("C")
		Destination Domain ("D")

	The document should also make clear that each of these 4 
administrative domains
is able to have their own policies and configurations -- and typically 
each domain's
policies and practices WILL be somewhat different from the others.  The 
document
should also explicitly note that both NAT and Firewalls are common in 
many end-user
(i.e. non-ISP) domains -- so end-to-end transparency is currently not 
always the case
(i.e. not a good assumption in general) for the deployed global 
Internet.

	We need for these aspects of the deployed reality to be very clear so 
that
folks don't erroneously think that the deployed situation is simpler 
than it is.

Cheers,

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Fri, 3 Jan 2003 14:57:11 -0500 (EST)

the purpose of the document is to define terminology
I do not think it is needed to overload it with a description of the Internet

Scott

----

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Jan 2003 14:51:28 -0500

I agree with Pat.

		Source Domain ("A")
		Source's ISP ("B")
		Destination's ISP ("C")
		Destination Domain ("D")

Cheers,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Jan 2003 15:33:21 -0500

> the purpose of the document is to define terminology

Scott,

	The above is NOT at all clear from the current document --
precisely because it does in fact talk at length about "topologies"
with an implication that they are real-world topologies of the Internet.

> I do not think it is needed to overload it with a description of the 

	It already has an description of the Internet.  Are you proposing to
delete that ?  The proposal a couple of us have made is to clarify the
description so that it is more accurate/complete.

	If you don't want to clarify the topologies as a couple of us have 
suggested,
then at minimum add a specific clear disclaimer that the document does 
NOT
describe actual real-world topologies present in the Internet, but 
instead is
only defining particular words (working from the above assertion that 
the
purpose is to "define terminology").

Ran