a***@psg.com
2004-07-30 20:59:35 UTC
Hi,
Earlier, I posted the latest notification of the latest version of
Requirements for Inter-Domain Routing.
.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-03.txt
From the answers below, I think you will notice 2 things:
- Some of the changes merit further discussion
- Some of the issues still need a response, or perhaps a better
response.
I will be going over this list during the IRTF RRG meeting on
Wednesday. I intend to update the doc after the meeting. After it has
been posted to this list for a few weeks I will resubmit it To the RFC
Editor - baring any open issues.
thanks
a.
why this will be an issue for the IESG, though of course I expect it
will
be an issue in any protocol developed to implement any resulting
architecture. I have, however, accepted the comment and have
added references to the sections where security is discussed.
Most of the editorial changes have been accepted and incorporated
into the document.
The suggestion has been accepted. All capitalization of imperatives
has been eliminated since these words really have no definition in
informational documents. Additionally since the introduction is
quite specific about all 'requirements' being strong suggestions, the
imperatives have no imperative force in this document.
I think the community at large that reviews any new architecture
will be the ones who need to make this determination. Expert Reviews,
rough
consensus, and running code will be the determinant.
As the document states this requirement, it is that the architecture
separates the functions, though it does not specifically use the word
'modular'. I think a review of the architecture will show whether it
has done an effective job of seperating these functions and
capabilities. We will of necessity, need to rely on expert review to
determine whether this recommendation has been adequately met.
All capitalized imperatives have been elimnated. But it stands to
reason that this is a priority.
The issue is that the architecture, per se, must not be the limitng
factor.
seems very
important to me.
Well, I got rid of the capitalized imperative. The next paragrapgh
goes on to explain that the architecture must be as simple as
possible with a merciless weeding of things that are not absolutely
necessary.
Since this was the product of group A, and the group has since
dissolved, I did not feel I could remove the requirement. As I do
not personally believe it to be content free, I did add an editor's
note that attempts to explicitly descibe the content of the requirement
as I understand it.
Replaced paragrapgh in 2.1.4 with reference to 2.1.7
2.1.6 discusses multi-homing while 2.1.23 discusses prefixes.
While using mutiple prefixes for a topological entity is indeed
a method for effecting multi-homing, it is not the only reason.
For example, in renumbering, it is quite possible that prefixes
might temporarily overlap.
I beleive the 2.1.28 is more specific then 2.1.24. One argues for
cooperative anarchy, without specifying how that should be done.
The other is explicit about the allowing multiple levels of
admisitration.
While there is a requirement for scalability, there is no specific
requirement on how this should be done.
2.2.8 indicates that renumbering itself is not the repsonsiblity of
the routing system. But it also indicates that the routing
system must cope with renumbering. 2.1.22 is a way of coping with
renumbering. The point is that the renumbering itself is still
not being done by the routing system.
The difference between the group A and group B efforts was that
group
A started with a clean state ideology - backward compatabilty was
not a constraint, whereas group B was required to considered
backward compatibility. I think the polarity is correct in this
case.
'Integrate with' and 'require' are very different in this case.
To 'integrate with indicates that the information from other routing
realms, though in the underlying structure, could be used when
avaialble, but does not indicate that the architecture would
require them, only that it should accomodate them.
In 2.2.2, while it is an obvious hyperbole, i think the meaning is
that each of N people will have a different and disjoint answer
in each of N-1 conversations.
In terms of deployment, not quite yet. And certainly when this
section was originally written, it still far from cerrtain. As
this document is supposed to reflect the work of groups that have
closed, I do not see the harm in the 'potential'. but I have
removed
the word potential - though I personally still believe it is a
potential, though a likely one.
Yes. and no. It is the IGP/EGP split in which BGP is the current
EGP. It also includes all of the practice that is not explicitly
part of a protocol but which applies to an architecture of which
BGP is but one part.
Substituted 'service'.
Changed
Substituted 'aggregated domain object'
Not to argue here for a looser defininiton of proof, I have ammended
the test to say that there are various means of demonstration and
proof.
While Noel was not in group B, several of the participants had been
part of the Nimrod effort and thus some, but by all means not all.
had absorbed some of the 'gospel'.
In order that the term be clear to non-'disciples', or anyone who does
not know what a Map distribution protocol is, I have added;
as defined in ref.07 - which describes to the Nimrod architecture.
Text changed to 'the current practice in router design'
If I understand the huh's referent:
This section indicates that the definitions of inter domain and intra
domain do not necessarily map to the current IGP/EGP split, but
rather to the notion of inside and outside.
It also indicates that the idea is relative, in that the same domain
can be an inner domain from one perspective but an external domain
from another perspective.
I think is taken care of by listing a reference for an earlier instance
of Map
R(17) indicates that the architecture should be stable under a
requirement for local convergence instead of global convergence.
The paragraph in 3.6.6 is referring to stability on the local basis,
when local is defined by 'a domain or group of domains'.
Earlier, I posted the latest notification of the latest version of
Requirements for Inter-Domain Routing.
.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-03.txt
From the answers below, I think you will notice 2 things:
- Some of the changes merit further discussion
- Some of the issues still need a response, or perhaps a better
response.
I will be going over this list during the IRTF RRG meeting on
Wednesday. I intend to update the doc after the meeting. After it has
been posted to this list for a few weeks I will resubmit it To the RFC
Editor - baring any open issues.
thanks
a.
(1) Formal problems
The IESG is going to balk at the Security Considerations section.
You need at least to specifically enumerate the section(s) where
you talk about security issues. A little blather here would not
be amiss... ;-)
Since this is an non WG and informational draft, I do not understanThe IESG is going to balk at the Security Considerations section.
You need at least to specifically enumerate the section(s) where
you talk about security issues. A little blather here would not
be amiss... ;-)
why this will be an issue for the IESG, though of course I expect it
will
be an issue in any protocol developed to implement any resulting
architecture. I have, however, accepted the comment and have
added references to the sections where security is discussed.
(2) Editorial problems.
Rather than list all the problems, we found it less work to
edit the suggested changes into the text. We are sending the
modified text and diff as: draft-irtf-routing-reqs-02a.txt and
draft-irtf-routing-reqs-02.wdiff.html. We have probably not
identified all the problems, but the rest can be handled during
our EDIT phase.
Please, carefully review the changes that we made. We think that we
interpreted your meaning correctly in every case, but sometimes
there were ambiguities in the original that may have led us astray.
ANS:Rather than list all the problems, we found it less work to
edit the suggested changes into the text. We are sending the
modified text and diff as: draft-irtf-routing-reqs-02a.txt and
draft-irtf-routing-reqs-02.wdiff.html. We have probably not
identified all the problems, but the rest can be handled during
our EDIT phase.
Please, carefully review the changes that we made. We think that we
interpreted your meaning correctly in every case, but sometimes
there were ambiguities in the original that may have led us astray.
Most of the editorial changes have been accepted and incorporated
into the document.
(3) We have questions and suggestions about the document.
o RFC authors have sometimes been abusing the
MUST/SHOULD/MAY ... words, and your document has this
failing in places. We would prefer that you to address
these issues, generally by de-capitalizing gratuitous
capitalization. In particular, here are some really
iffy examples.
ANS:o RFC authors have sometimes been abusing the
MUST/SHOULD/MAY ... words, and your document has this
failing in places. We would prefer that you to address
these issues, generally by de-capitalizing gratuitous
capitalization. In particular, here are some really
iffy examples.
The suggestion has been accepted. All capitalization of imperatives
has been eliminated since these words really have no definition in
informational documents. Additionally since the introduction is
quite specific about all 'requirements' being strong suggestions, the
imperatives have no imperative force in this document.
- You say the architecture MUST be clear, well thought out, ...
(2.1.1)
REALLY? How can you determine if you did it?\
ANS:(2.1.1)
REALLY? How can you determine if you did it?\
I think the community at large that reviews any new architecture
will be the ones who need to make this determination. Expert Reviews,
rough
consensus, and running code will be the determinant.
- You say the architecture MUST be modular (2.1.2).\
REALLY? What does that mean, and how do you
know?
ANS:REALLY? What does that mean, and how do you
know?
As the document states this requirement, it is that the architecture
separates the functions, though it does not specifically use the word
'modular'. I think a review of the architecture will show whether it
has done an effective job of seperating these functions and
capabilities. We will of necessity, need to rely on expert review to
determine whether this recommendation has been adequately met.
- You don't say MUST in section 2.1.3, 3rd bullet 1
(must be slower than Moore's law.)
Did you mean to?
ANS:(must be slower than Moore's law.)
Did you mean to?
All capitalized imperatives have been elimnated. But it stands to
reason that this is a priority.
- You say the architecture MUST NOT limit the # of alternate\
paths (2.1.6).
REALLY? No limit? That would be hard to
believe, even if it were only SHOULD.
ANS:paths (2.1.6).
REALLY? No limit? That would be hard to
believe, even if it were only SHOULD.
The issue is that the architecture, per se, must not be the limitng
factor.
- You don't say MUST for "No Bad Data" (2.1.9)
(twice).
Well, I have gotten rid of all capitalized imperatives. But, yes, it(twice).
seems very
important to me.
- You say the architecture MUST be simple enough for
Radia Perlman to explain in a hour.
Give us a break! That is a content-free MUST.
Ans:Radia Perlman to explain in a hour.
Give us a break! That is a content-free MUST.
Well, I got rid of the capitalized imperative. The next paragrapgh
goes on to explain that the architecture must be as simple as
possible with a merciless weeding of things that are not absolutely
necessary.
Since this was the product of group A, and the group has since
dissolved, I did not feel I could remove the requirement. As I do
not personally believe it to be content free, I did add an editor's
note that attempts to explicitly descibe the content of the requirement
as I understand it.
We probably missed some, but these are the ones we noticed.
o Citations and References
- Mike O'dell quote in 2.1.2 needs a citation and
reference (the words
must be quoted from SOMEWHERE!)
REQUEST: Can someone help me with a citation?o Citations and References
- Mike O'dell quote in 2.1.2 needs a citation and
reference (the words
must be quoted from SOMEWHERE!)
- "One respected network sage" (2.2.3) is Dave Clark, and
we believe he said it in an IETF plenary, probably
around 1991.
REQUEST: Can someone help me with a citation?we believe he said it in an IETF plenary, probably
around 1991.
- References [10] and [14] have formatting errors.
ANS: Fixedo Inconsistencies and duplications
- 2.1.7 appears to duplicate the next to last paragraph of
2.1.4.
ANS:- 2.1.7 appears to duplicate the next to last paragraph of
2.1.4.
Replaced paragrapgh in 2.1.4 with reference to 2.1.7
- The last paragraph of 2.1.7 duplicates 2.2.7. Suggest
instead (or in addition): "See also Section 2.2.7".
ANS: Replaced paragrapgh in 2.1.7 with a reference to 2.2.7instead (or in addition): "See also Section 2.2.7".
- Section 2.1.13 needs at least a reference to 2.2.9, to
explain why host mobility was omitted from 2.1.13.
ANS: Inserted.explain why host mobility was omitted from 2.1.13.
- (How) does 2.1.23 differ from 2.1.6?
ANS:2.1.6 discusses multi-homing while 2.1.23 discusses prefixes.
While using mutiple prefixes for a topological entity is indeed
a method for effecting multi-homing, it is not the only reason.
For example, in renumbering, it is quite possible that prefixes
might temporarily overlap.
- (How) does 2.1.28 differ from 2.1.24? If multiple
administrations are not just a case (the only case?)
of "cooperative anarchy", what does the latter
mean??
ANS:administrations are not just a case (the only case?)
of "cooperative anarchy", what does the latter
mean??
I beleive the 2.1.28 is more specific then 2.1.24. One argues for
cooperative anarchy, without specifying how that should be done.
The other is explicit about the allowing multiple levels of
admisitration.
- 2.2.1 appears to contradict 2.1.3.
ANS:While there is a requirement for scalability, there is no specific
requirement on how this should be done.
- 2.2.8 appears to directly contradict 2.1.22.
ANS:2.2.8 indicates that renumbering itself is not the repsonsiblity of
the routing system. But it also indicates that the routing
system must cope with renumbering. 2.1.22 is a way of coping with
renumbering. The point is that the renumbering itself is still
not being done by the routing system.
- The title of 2.2.10 is reversed in polarity; suggest
"Backwards Compatibility".
ANS:"Backwards Compatibility".
The difference between the group A and group B efforts was that
group
A started with a clean state ideology - backward compatabilty was
not a constraint, whereas group B was required to considered
backward compatibility. I think the polarity is correct in this
case.
o Questions
- It would be useful to define what you mean by "address
portability" (2.1.14).
NOTE: I have not dealt with this one yet. Suggestions welcome.- It would be useful to define what you mean by "address
portability" (2.1.14).
- We did not really grok what 2.1.19 meant. Should
"integrate with" be "require"?
ANS:"integrate with" be "require"?
'Integrate with' and 'require' are very different in this case.
To 'integrate with indicates that the information from other routing
realms, though in the underlying structure, could be used when
avaialble, but does not indicate that the architecture would
require them, only that it should accomodate them.
- In 2.2.3, you say "N!". You can't be serious. How
about N opinions from N people?
ANS:about N opinions from N people?
In 2.2.2, while it is an obvious hyperbole, i think the meaning is
that each of N people will have a different and disjoint answer
in each of N-1 conversations.
- Section 3.2.2, bullet "Potential addition of a second..."
Why "potential"; isn't IPv6 already a
reality?
ANS:Why "potential"; isn't IPv6 already a
reality?
In terms of deployment, not quite yet. And certainly when this
section was originally written, it still far from cerrtain. As
this document is supposed to reflect the work of groups that have
closed, I do not see the harm in the 'potential'. but I have
removed
the word potential - though I personally still believe it is a
potential, though a likely one.
- Section 3.2.3.3: What IDR proposal; aren't
you referring to BGP?
Ans:you referring to BGP?
Yes. and no. It is the IGP/EGP split in which BGP is the current
EGP. It also includes all of the practice that is not explicitly
part of a protocol but which applies to an architecture of which
BGP is but one part.
- Section 3.2.3.7 seems to be talking about forwarding
paradigms, not routing paradigms. Thus, there
seems to be some overlap/confusion between this
section and section 3.2.3.4.
NOTE: I have not fixed this one yet.paradigms, not routing paradigms. Thus, there
seems to be some overlap/confusion between this
section and section 3.2.3.4.
- Section 3.4.3: what (??!) is a "wayleave"? (A
wayleaf?)
ANS:wayleaf?)
Substituted 'service'.
- Section 3.5 item 6, last sentence: shouldn't this
be "some domains may..."? Surely, not all domains
will be tens of thousands of routers!
ANS:be "some domains may..."? Surely, not all domains
will be tens of thousands of routers!
Changed
- Section 3.6.1: "replaced by a domain collection object..."
Maybe this should be "collective domain object"
or "aggregate domain object" ?
ANS:Maybe this should be "collective domain object"
or "aggregate domain object" ?
Substituted 'aggregated domain object'
- Section 3.6.6: The term "heuristic proof" seems like an
oxymoron.
ANS:oxymoron.
Not to argue here for a looser defininiton of proof, I have ammended
the test to say that there are various means of demonstration and
proof.
- Sections 3.10.4, 3.10.5: again, "map" and "map distribution"
are introduced without definition or
explanation (or citation). Only the disciples
of Noel Chiappa/Nimrod know what this means!
[I am puzzled that Noel was not in group B;
these sections are straight Gospel According to
Noel!]
ANS:are introduced without definition or
explanation (or citation). Only the disciples
of Noel Chiappa/Nimrod know what this means!
[I am puzzled that Noel was not in group B;
these sections are straight Gospel According to
Noel!]
While Noel was not in group B, several of the participants had been
part of the Nimrod effort and thus some, but by all means not all.
had absorbed some of the 'gospel'.
In order that the term be clear to non-'disciples', or anyone who does
not know what a Map distribution protocol is, I have added;
as defined in ref.07 - which describes to the Nimrod architecture.
o Confusing Text
- Last paragraph of section 3.2, "Current practice ..."
Not clear what you are trying to say here.
ANS:- Last paragraph of section 3.2, "Current practice ..."
Not clear what you are trying to say here.
Text changed to 'the current practice in router design'
- Section 3.2.1: Huh??\
ANS:If I understand the huh's referent:
This section indicates that the definitions of inter domain and intra
domain do not necessarily map to the current IGP/EGP split, but
rather to the notion of inside and outside.
It also indicates that the idea is relative, in that the same domain
can be an inner domain from one perspective but an external domain
from another perspective.
the term "map" suddenly appears here without
explanation or definition.
ANS:explanation or definition.
I think is taken care of by listing a reference for an earlier instance
of Map
- Section 3.6.6, the paragraph "Routing policies are
compatible if...": it is unclear how "convergent"
differs from "stable", as in R(17).
ANS:compatible if...": it is unclear how "convergent"
differs from "stable", as in R(17).
R(17) indicates that the architecture should be stable under a
requirement for local convergence instead of global convergence.
The paragraph in 3.6.6 is referring to stability on the local basis,
when local is defined by 'a domain or group of domains'.