Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document?

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 13 Dec 2004 04:10:59 -0500

Pekka Savola wrote:
> On Fri, 3 Dec 2004, Curtis Villamizar wrote:
>> Anything that is not a WG item and is being considered for a WG item
>> is by definition new work for the WG and therefore it should be
>> determined that there is a requirement for it.  I think those several
>> service providers should speak up for themselves if they are
>> interested in seeing this work progress.
>> 
>> Having been on the provider side of this business in the past I know
>> that at times a vendor will approach a service provider with an idea
>> and if they provider doesn't bodily throw them out the door the
>> vendor counts them as "possibly interested" for the purpose of
>> discussions such as this.  Therefore I'd like to see the providers
>> speak for themselves rather than the vendor speak and there is
>> plenty of precedence in the IETF for asking for that.
> 
> I'll echo Curtis's concern.
> 
> ATM has gone out so long time ago that I'd expect that the vast
> majority of serious SPs have already solved this problem without a
> real need for this mechanism. I'm not sure we want to add ATM hacks to
> BGP as well..

I object against the use of the word "ATM hack". The draft represents a straightforward application of Multi-Protocol extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols". Now that we propose to use this to carry ATM routing information, it is suddenly a hack??

[snipped]

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Dec 2004 12:55:21 +0200 (EET)

On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote:
> I object against the use of the word "ATM hack". The draft 
> represents a straightforward application of Multi-Protocol 
> extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This 
> document defines extensions to BGP-4 to enable it to carry routing 
> information for multiple Network Layer protocols". Now that we 
> propose to use this to carry ATM routing information, it is suddenly 
> a hack??

Depends on what you call 'Network layer', I guess :). Network layer 
typically refers to the layer of "IP".  From the perspective of IP, 
ATM routing information is at the link-layer.  This would seem the 
similar to propagating Ethernet MAC addresses of VPLSs (for example) 
in NLRIs.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Dec 2004 10:05:28 -0800

At 12:55 PM 12/13/04 +0200, Pekka Savola wrote:
>typically refers to the layer of "IP".  From the perspective of IP, ATM 
>routing information is at the link-layer.  This would seem the similar to 
>propagating Ethernet MAC addresses of VPLSs (for example) in NLRIs.

I agree that this terminology is generally used, but it is in fact 
incorrect. Lets take an aside into the definitions and meanings of words.

<tangent>
Going back to the definitions of the terms, a "Link" is a physical 
connection between two Nodes on a network, and the Link Layer is the 
communications layer that provides for the reliable transfer of information 
across a Link. Both of those definitions, I believe, derive from Stallings, 
1991, and reflect the preoccupation of the time with reliability at the 
link layer. In other words, the physical layer is something you can touch 
or otherwise describe in terms of physics and includes the mechanism for 
encoding data (often binary but not necessarily; see QPSK), and the link 
layer separates the exchanged data into noise and signals exchanged between 
physically connected systems. The network layer is by definition a layer 
which creates virtual connectivity (circuits or connectionless routes as 
appropriate) out of a sequence of zero or more link layer connections 
between nodes in the graph.

IP is called the "Internet Protocol" because it connects networks (think 
for a moment about what "inter" and "network" mean etymologically). These 
networks may be pure IP networks, but (surprise) may be switched LANs over 
which IP data is flowing, ATM networks, Frame Relay Networks, or a long 
list of other kinds of networks.

You'll ask why we call these "link layer networks". Well, there are two 
reasons. One is that ballpark 1979 the Internet community decided to switch 
from BBN 1822 to X.25 as an access technology into the ARPANET, and 
observed (correctly) that X.25 described what happened at a user-to-network 
(UNI) or network-to-network (NNI) interface, but did not describe what 
happened in the network itself. As such, they had trouble thinking of it as 
a real communication layer, but rather wanted to treat it only as the UNI 
or NNI. They therefore (tweaking noses in CCITT immensely) relegated it to 
a layer beneath them. Five years later, IEEE wanted to define Ethernet and 
Token Ring Bridging (as "switching" was then called), and (since the 
network layer belonged to ANSI by prior agreement) called theirs a "link 
layer network". It did, after all, use the link layer header...

But trust me, an ATM network is a network, and by definition belongs in 
what I call the "Intranet" sublayer of the Network Layer of the OSI 
Reference Model. What distinguishes the various technologies at this 
sublayer as much as anything is that they are designed to connect things 
that ought to be connected, and are operated by a single administration. 
The Internet Protocol connects disparate such networks and the hosts in 
them end to end, and is operated by disparate administrations with 
disparate intents and policies. The Internet is a network of networks, and 
many of those networks are not fundamentally IP networks, but only carry IP 
as an overlay.

Which is why we can deploy a different Internet protocol over the same 
network...
</tangent>