Subject: Re: Modifications to IP

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Jul 2001 16:38:35 -0400

At 11:21 19/07/01, Russ White wrote:
>The draft proposes additions to RPR to support IP better into the
>future--it does not recommend any changes to IP, nor any other
>protocol. 

A self-contradictory sentence.  "proposed additions to RPR" is 
semantically identical to "recommended change to another protocol".
Maybe you meant something else ?

>If you don't think RPR needs any additions to support IP or any
>other layer protocols, then I would suggest to you that it isn't
>going to hurt anyone to add the small things suggested in the
>framework doc and see what happens. 

I totally disagree that proposing to add stuff ("gorp") is
not going to hurt anyone.  In fact, adding stuff is likely 
to hurt the utility and deployability of 802.17 by making it 
overly complex, expensive, and hard to deploy.

>Let's not argue over things which are not in the framework. A
>layer 2 only philosophy is perfectly fine, but that philosophy
>should not preclude the addition of generic mechanisms which will
>allow others to use the medium in different ways than a layer 2
>only philosophy might entail.

If folks want to modify 802.17, the place to make such proposals
is within IEEE 802.17, not within IETF.  Certainly it is not proper
to do so within IETF when there is no consensus evident within IETF
for the proposal. Even if there were consensus here, the place where 
IEEE protocols should be discussed (and proposals made) is in IEEE 
not in IETF.  This is just a matter of proper scope for each standards 
group.

Ran
[email-masked]

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jul 2001 18:29:23 -0400 (EDT)

> not going to hurt anyone.  In fact, adding stuff is likely to
> hurt the utility and deployability of 802.17 by making it

I don't know much about the sections on other interfaces, but the
section I contributed, adding a simple mechanism for layer
three/layer 2.5 devices to find their logically adjacent
neighbors through the carrying of opaque data in a restricted
way, doesn't seem overly complex to me.

In fact, I will go so far as to say that_not_ adding this ability
will keep you from succesfully deploying traffic engineering over
rpr, which will keep it from being deployed at all in most real
networks.

> If folks want to modify 802.17, the place to make such
> proposals is within IEEE 802.17, not within IETF.  Certainly
> it is not proper to do so within IETF when there is no
> consensus evident within IETF for the proposal. Even if there
> were consensus here, the place where IEEE protocols should be
> discussed (and proposals made) is in IEEE not in IETF.  This
> is just a matter of proper scope for each standards group.

<ahem!> My entire concept of the framework document is as a set
of suggestions into the 802.17 working group. If you want mpls
and other traffic engineering types of things to run
_intelligently_ on 802.17, then you ask the people who know
something about those things what they would want to make them
work.

So, it seems to me that the ietf is the correct forum to ask:
"What things can the 802.17 working group add to the layer 2
mechanisms to make this work better with thoughtful layer 3
implementations?" It's called 'cooperation between standards
bodies that cover different areas of expertise.' Does the ieee
not take recommendations from asme on types of mechanical
connectors, physical wiring, and such?

As for concensus--I'm not certain anyone has actually commented
on the technical merits of the draft. I've heard a lot of noise
about not changing IP, but nothing about the rather simple
proposal that this working group can and should carry to the
802.17 working group as a _request_ to make this layer 2 protocol
actually more useful than ethernet.

It seems the three questions at hand are:

-- Is it appropriate for a working group within the ietf to
propose things to the ieee which would make a currently in
progress layer 2 protocol more useful to the upper layers? My
answer to this is yes--the ietf shold feel free to carry such
recommendations, within our area of expertise, to the 802.17
working group.

-- There are two things, I think, currently proposed in the draft
as things 'we' are saying ietf would like to see. Are both of
these valid? In other words, would they do things that would make
layer three protocols actually work better over rpr?

(before answering this--have you read the justifications for
them? Do you understand routing protocols and traffic engineering
within a routing protocol context well enough to make a judgement
on the justifications and mechanisms involved, and the problems
which will result if we do _not_ recommend these things, and they
are not put into rpr?)

-- Of the things that are considered valid, are they phrased and
designed in such a way to leave no holes, and make sense?

My _opinion_ is that if you vote no on the first question, then
you are dooming rpr to failure. We should abandon the working
group altogether, and ignore rpr until it ships. We can safely
ignore it after it ships as well because it won't offer anything
provocative or useful in real networks if it looks like yet
another ethernet.

I would be _glad_ to post and discuss with anyone why I think rpr
needs the ability I've described to support traffic engineering
at all--regardless of whether we are discussing mpls traffic
engineering or straight routing protocols choosing ring
direction. I _thought_ there was a note in the draft stating the
mechanism proposed for fulfilling the ability suggested was
simply a straw proposal for study and clarification. I'll be
happy if it's implemented this way. I'll be happy if it's
implemented some other way. As long as we have the ability to
find the immediate upstream and downstream logical neighbor, I'll
be happy.

The mechanism proposed as a straw man, however, is well thought
out--it keeps a clean line between l2 and l3, it places minimal
requirements on l2 (no state/etc), etc. Again, I'd be happy to
discuss these, since these are technical topics which relate to
the merit of the draft, rather than political and linguistic
arguments.

Russ

_____________________________
[email-masked] <>< Grace Alone

---

From: "Khaled Amer" <[email-masked]>
Date: Thu, 19 Jul 2001 14:44:35 -0700

Folks,
I'm surprised at this discussions which has been going on and on.

I think that it doesn't hurt for the IEEE 802.17 to know about some of the
suggestions that the IETF has in order to develop a better standard. Right
now, at the IEEE 802.17WG, we're looking at all proposals and inputs that we
can get. We all welcome input from the IETF too (even if it's tentative
and/or not completely agreed upon yet). Keeping the dialog open can only
help and we should encourage cooperation between the IEEE and the IETF
(unless there is more to all of this than what I've been reading through the
reflector).

Khaled Amer
President, AmerNet Inc.
Architecture Analysis and Performance Modeling Specialists
Address:     13711 Solitaire Way, Irvine, CA 92620
Phone:        (949)552-1114                      Fax:     (949)552-1116
e-mail:         [email-masked]
Web:           www.performancemodeling.com

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Jul 2001 18:49:29 -0400

>way, doesn't seem overly complex to me.

It does to me.

>rpr, which will keep it from being deployed at all in most real

Disagree.  Folks have successfully deployed Traffic Engineering
over lots of other layer-2 technologies without having any
layer-2 mechanisms to support it.  POS and Ethernet
are examples of this that are in wide deployment today.

>bodies that cover different areas of expertise.' 

        If IEEE wants to ask that (they haven't yet as far as is documented),
then can.  I doubt they will feel a need to do so since LOTS of folks 
here are also directly participating in 802.17.  This means they
already have a lot of the relevant expertise among their own
participants.

>Does the ieee

        Actually, they mainly take input from folks inside IEEE 
who already have that expertise.

>on the technical merits of the draft. 

        I've been trying to object to the whole draft for months now. 
I strongly prefer a technical specification that is light-weight
and object to each proposal in the current draft.

>I've heard a lot of noise

        I object to IETF originating that proposal on grounds 
it is overly complex and not needed for IP/802.17 to work well.

>recommendations, within our area of expertise, to the 802.17

        Even if one believes the above, the current I-D still ought not 
be sent over or presented in IEEE-land until AFTER the WG chairs 
have formally determined that there is consensus here (presumably
the draft goes to RFC Editor about then as well).

>layer three protocols actually work better over rpr?

        I see those as things that authors of the draft wish to see.
They are not things the WG as a whole has reached a conclusion
on (pro, con, or sideways) so far.  Certainly some, me included, 
object to IETF originating them.

>which will result if we do _not_ recommend these things, and they

        I've implemented routing code inside very widely deployed
IP routers.  I've also done network engineering for a large 
multi-continent IP network (Europe, Americas, Australia) and network
consulting on the only all continents IP network.  And so I disagree 
in an experienced and informed way with your assessment that there 
are "serious problems" if we do not recommend the proposal(s) 
currently in the I-D.

>designed in such a way to leave no holes, and make sense?

I see none as valid.

>you are dooming rpr to failure. 

Not at all.  I see simplicity as the best shot for RPR to be wildly
successful and widely deployed with IP networks.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Jul 2001 19:48:16 -0400

At 17:44 19/07/01, Khaled Amer wrote:
>suggestions that the IETF has in order to develop a better standard. 

        A large part of the issue is that individual folks in IETF are
packaging their individual ideas, which might or might not have
broader buy-in, as if they had broader buy-in from the IETF community.

>Right now, at the IEEE 802.17WG, we're looking at all proposals and 
>inputs that we can get. We all welcome input from the IETF too 
>(even if it's tentative and/or not completely agreed upon yet). 

        Some of us think that some of the ideas (which aren't merely
tentative, but are rather purely one or two people's personal ideas)
are misguided and object to them being marked with the IETF label
when they are in fact individual or corporate contributions.

        IETF rules are that stuff ought not proceed without rough
consensus.  Its not clear that these ideas have that level of support.

        Now, if those folks want to make those ideas known to IEEE
as personal/corporate contributions (e.g. via personal Internet-Drafts
clearly marked or other means) that would be totally non-objectionable.

Ran