Subject: RE: IPORPR Presentation to IEEE 802.17WG

From: Albert Herrera <[email-masked]>
Date: Wed, 18 Jul 2001 14:01:46 -0400

Ran,

I'm sure there are others that share your view
and my job here is to moderate the group. So
your comments are most welcome.

However, if you look back at how we tried to do
IP after most ATM was done, you don't exactly
find a smooth integration. And maybe you're right,
maybe we shouldn't have made any changes to IP
to accommodate ATM. We're just trying to be
pro-active here and hopefully bypass any bumps 
as we had with ATM.

As for presenting at IEEE, I presented the draft 
as NOT a final consensus but as a work-in-progress
and I did urge for participation and feedback 
from 802.17 to shape the Framework. I made sure 
concerns voiced at IETF were just as well 
represented on the presentation and not just a single
viewpoint. That's the reason we now have three options
of how to go about IP over 802.17.

I guess you'd rather someone design a pan for you to boil 
water on rather than suggesting that maybe you need a kettle
if it would serve them just as well.

I believe we have very useful work here and the parallel
efforts can only benefit both IEEE and IETF in the long 
run.

Albert

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 1:28 PM
> To: Albert Herrera
> Cc: iporpr@external. cisco. com (E-mail)
> Subject: Re: IPORPR Presentation to IEEE 802.17WG 
> 
> 
> At 11:55 18/07/01, Albert Herrera wrote:
> >I presented the Framework draft as input to 
> >last week's IEEE 802.17WG plenary. 
> 
> Albert,
> 
>         As I said at the last IETF meeting, I think the current 
> Framework draft is essentially misguided and isn't solving 
> any real problem, whether technical or procedural.  I suppose
> it probably does help bolster the authors' resumes.
> 
> >We presented three approaches of running 
> >IP over 802.17. The third approach which is
> >'Enhanced L2/l3 Interaction' got the most
> >questions as well as objections.
> 
> I heartily agree with those objections.  This IETF WG ought NOT 
> be modifying ANY IEEE or IETF protocols just for 802.17.  IP/802.17 
> *ought* to just work without changing anything, just as FDDI did 
> and as other LAN type media do and as POS does.
> 
> >I mentioned that IPORPR and 802.17WG might have to 
> >work closer the coming months to make sure that
> >any synchronization issues gets resolved the same
> >way we synchronize existing overlapping features
> >today such as protection mechanisms from L1,L2&L3.
> 
>         I actually think that your continued attempts to use
> IETF to leverage your personal views within 802.17 are
> totally inappropriate.  The comments and feedback at the
> last IETF meeting were really CLEAR that most folks in 
> attendance did NOT agree with the drafts presented at that 
> meeting and that most folks do NOT want IETF to be telling
> IEEE how to design their 802.17 MAC protocol.
> 
>         I further object to you making presentations to IEEE
> as if the content of those presentations were something
> that had IETF WG consensus, when in fact such consensus 
> does not exist in this WG.
> 
> Yours,
> 
> Ran
> [email-masked]
>

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 18 Jul 2001 14:11:16 -0400

>pro-active here and hopefully bypass any bumps 

ATM is radically different than a LAN technology
such as 802.17 is developing, so is a tremendously
poor comparison point.  ATM had actual circuits
and signalling and packet shredders and other gorp.
Comparing with ATM is an approach with tremendous
intellectual poverty.

in contrast, FDDI makes for a good comparison.  Neither 
FDDI nor IP needed changes for the two technologies
to work well together.  FDDI had dual-counter
rotating rings and lots of Layer-2 capabilities
(e.g. in SMT).

>as NOT a final consensus but as a work-in-progress

Folks at IEEE 802.17 report that it came across as
being an "IETF perspective", so your disclaimers
need work for next time.  Also, the WG ought to
have been given a chance to review the proposed
presentation, given that it came across as an IETF
position.

>if it would serve them just as well.

        I'd rather have WG Chairs focus on chairing,
instead of using their position to advance their
personal views which are not supported by WG
consensus.

>efforts can only benefit both IEEE and IETF in the long 

        At the last meeting there was a lot of vocal disagreement
with the sentence above.  I guess you didn't hear that part.
The primary useful work proposed here so far has been 
some joint work with 802.17 on an SNMP MIB, IMHO.

Ran
[email-masked]

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Thu, 19 Jul 2001 08:27:39 -0400

>Comparing with ATM is an approach with tremendous

Technically, true. But that does not eliminate
the issue that IP-over-ATM is a really bad fit,
in part because of all the gorp you mention.
The idea of this working group (as I understand
it) is to try and provide information to the 
IEEE effort so that they know that "gorp"
can be a Really Bad Idea from IP's perspective and
that if they put "gorp" in their technology, it may
hinder IP deployment over it. 

As an intellectual exercise, suppose that the 
ATM developers 
a) had good feedback from the IP world before they
   standardized their gorp and
b) took that feedback to heart and therefore
c) found less gorpy ways (sorry for being technical
   here :-) to do what they wanted and so made it 
   'easier' for IP to run over ATM.
Perhaps ATM would not be the legacy technology it is fast
becomming today...

I do disagree, some, with your apparent characterization 
of 802.17 as a 'LAN' technology. It is meant for metro-areas
at least. Cisco's DPT/SRP (a precursor to 802.17) is deployed
in metro areas and more, so it is not unreasonable to expect
that if 802.17 is deployed, it will enjoy similar geographic 
scales.

>rotating rings and lots of Layer-2 capabilities

FDDI is not an unfair analogy, but it is not complete
either. The demands of networking are different today 
than they were 15 years ago. Things like QoS and 
traffic engineering were simply not issues. Today they 
are. Also, the environment envisioned for 802.17 is
different than FDDI. FDDI was primarily an intra-
enterprise LAN backbone (though there were some 
wider area deployments envisioned). 802.17 is
a MAN/WAN technology carrying and interconnecting
multiple providers. 

>need work for next time.

We may be arguing words here -- "IETF perspective" does
not (to me) necessarily denote "final consensus". 

>Also, the WG ought to
>presentation

That's not unreasonable.

Frank Kastenholz
co-chair, IPORPR

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Jul 2001 17:22:14 -0400

At 08:27 19/07/01, Kastenholz, Frank wrote:
>traffic engineering were simply not issues. 

        Disagree.  15 years ago, the DDN was preparing
to roll out IP Type-of-Service and then did so globally.  
Today we call that deployment "Differented Services".  
The technology is essentially the same, though back then 
several OSPF implementations included support for ToS-based 
routing.  This was used, for example, to select SATCOM vs copper
paths for trans-Pacific links.  This did not (and DiffServ
does not today) require layer-2 support or changes.

        Moreover, FDDI actually supported some forms of
layer-2 QoS.  FDDI-II, which wasn't ever widely deployed,
primarily varied from FDDI in its enhanced QoS feature set.

        Finally, we haven't changed either the PPP spec,
the SONET spec, or the Ethernet spec while implementing
IP traffic engineering.  To believe that we should be
putting such into layer-2 at all is an interesting leap
from the current belief that it needs to be done using
mechanisms such as MPLS -- precisely because we have 
heterogeneous layer-2 technologies (and always will have).

>Today they are. Also, the environment envisioned for 802.17 is
>wider area deployments envisioned). 

        I know of several MAN deployments of FDDI, though no
WAN deployments.

>802.17 is a MAN/WAN technology carrying and interconnecting
>multiple providers. 

        Perhaps.  It might also be a LAN/MAN technology
with a single administrative domain.  The presence of both
deployment models argues for keeping the layer-2 protocol 
simple.

>not (to me) necessarily denote "final consensus". 

        Several attendees at IEEE were left with the impression 
that there is current IETF consensus on the current contents
of the Framework I-D.  I don't think such consensus actually
exists, perhaps I'm just blind.  If there is such consensus
already, then the Framework document should probably go out 
as an RFC now.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 20 Jul 2001 09:17:05 -0400

At 08:43 20/07/01, Kastenholz, Frank wrote:
>At 05:22 PM 7/19/01 -0400, RJ Atkinson wrote:
>
>Speaking as an IP-veteran, not as co-chair
>You are correct, _we_ (the IETF in general
>and I, and I believe you personally) do not 
>believe in doing TE, QOS, etc. 

        I've actually deployed TE to work around a hot spot
in a large network.  I've also deployed QoS (specifically
IP ToS, called DiffServ these days, but the same stuff).
That said, you are quite right that I am inclined not 
to deploy either -- unless I need to for some set of technical 
reasons.

>Others, however, do not hold this particular religious bias.
>If those unnamed others, in an attempt to be "helpful",
>- Added TE/QOS/etc capabilities that did not
>  work well with what the IP-world likes to do and
>- Did not provide ways to turn those features off
>well, it would be A Bad Thing.

Agree with that.  

I find that having L2-specific mechanisms for QoS/TE is
not typically useful and is often actually obstructive
to getting the L3 QoS/TE to work right.  This was the case
with both FDDI's limited QoS mechanism and (in a huge way)
with ATM stuff.  By contrast, my experience with very simple
L2 technologies (e.g. POS, Ethernet) is that I could do
the stuff I needed to do at L3, without L2 gorp getting
in the way and without having to deal with the L2 gorp
if I had simply over-provisioned my network (as is my usual
druthers when I have a choice).

>Speaking as co-chair...
>The only consensus I see now, and it is actually pretty 
>rough, is to continue working on and refining the current
>document. That is to say, the consensus is that the current
>document is the path we wish to follow, but we have not
>yet reached the end point. 

Fair enough.

Ran
[email-masked]

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Fri, 20 Jul 2001 08:43:07 -0400

Speaking as an IP-veteran, not as co-chair
You are correct, _we_ (the IETF in general
and I, and I believe you personally) do not 
believe in doing TE, QOS, etc. Others, however,
do not hold this particular religious bias.
If those unnamed others, in an attempt to be
"helpful",
- Added TE/QOS/etc capabilities that did not
  work well with what the IP-world likes to do and
- Did not provide ways to turn those features off
well, it would be A Bad Thing.

Speaking as co-chair...

Speaking personally (i.e. NOT as cochair)
I do not think the document is ready for RFC-hood yet since
there is still some spirited discussion which has raised
some good points (your comment about how L2 should be 
as simple as possible probably deserves more thought,
refinement, and working into the draft, for example).
Also, my _personal_ view is that this document probably
should be a living document, that we can edit and update
fairly rapidly to respond to new input from the working group
and in response to new ideas coming out of 802.17.

Frank Kastenholz - man of many hats