1. Sections 3.4, 3.5, and 3.11...
...seem to be very close to each other. Can they be
packed into a single section (or become subsections
in such a section) on the denser connectivity mesh?
In particular, if the following is the authors' position:
-- > -----Original Message----- > From: Kastenholz, Frank [mailto:FKastenholz@unispherenetworks.com] > Sent: Thursday, March 07, 2002 9:13 AM > To: Howard C. Berkowitz; irtf-rr@nether.net > Subject: Re: Group A Section 3.11 > > > > We mean multihoming in a very broad sense -- A has multiple "things" > to B. Those "things" may be separate fibers/wires, or MPLS tunnels, or ... > > > As to possible solutions above the IP/Internet layer -- that is > interesting, > but outside of our scope. -- then 3.11 becomes just a partial case of 3.4.2. Section 3.6
I pretty strongly agree with Howard here that this section needs to be reworked (possibly, with help of the BMWG), so that "changes" and "things" would never "ripple back and forth" :)
3. Section 3.7
I have concerns with this portion: -- When the routers are on point-to-point links, with routers at each end, there is no need to encrypt the routing protocol traffic; there is no possibility of a third party intercepting the traffic, and if one of the two routers are compromised then it doesn't matter. -- Only when you hold a *physical* point-to-point link in you *physical* hands, you can be sure that there is no possibility of traffic getting intercepted. Even worse, with certain types of links (emanating electro-magnetic waves), even this "special handling" is not a guarantee. So that you cannot say that there is no need for encryption on point-to-point links (especially when they pass through all the wonders of a circuit provider).
4. Section 3.9
I think there is a better way to approach policy, and that would be more consistent with Section 3.2, which I like.
I'd define policy to be one of (many possible) *external constraint* subsystems. Namely, if we want to have a separable topology component producing "natural" routing, then we need to be able to support *various* components of external constraints (to this "natural" routing), what many people call "policy routing" today being just an example.
This would be more consistent with the data network routing theoretical framework. Plus, this would leave more space for the "policy routing vs. traffic engineering" discussion.
5. Section 3.9.1
While the authors criticize GroupB's draft as too BGP-centric, some portions of GroupA's draft become even more BGP-centric as the draft version increases... :))
6. Section 3.9.2
Examples here are suspiciously close to what a great portion of those N people from Section 4.2 would call "pure TE", whereas Section 4.2 is non-requirement. Quite confusing, I think :)
Again, I'd say that TE/policy, being external constraint components, need to be able to interface with the topology component. In that sense, they are requirements.
7. Section 3.10
What does that mean to "squeeze out the old architecture"? My assumption is that there may be great portions of network that would never have to be "touched", -- especially if the "Hypernet" deployment scenario takes place.
8. Section 3.12
Some repetitions with TE-like "examples" from Section 3.9.2, while the fundamental theoretical advantage of multi-path routing is missed (the multi-path routing in data networks with even multiple additive constraints is usually polynomial problem -- the single-path integer constraint makes the problem NP-complete).
9. Section 3.17
So, what is more important: human understanding or efficient code? At the algorithmic level, for example, simpler algorithm (from the point of view of a human) does not always allow for simpler (less lines of code) implementation (even more so for efficiency of the algorithm).
10. Section 3.19
In addition to comments already made on this section, -- what do authors understand under "IP" here? Based on the last paragraph of Section 3.15, one may (erroneously???) conclude that "IP" is a synonym for packet switching...
And after all, MUST or MUST NOT "IP" be "agnostic" with respect to any "routing" or "topology" at the "sub-IP" "layers"? (especially when "IP" "routing" "wishes" not to be "agnostic":) (that is, the last paragraph seems to be inconsistent with the first one).
11 Section 5
...does not reflect the current state of the GroupA drafts. -- dima.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT