On Wed, 18 Jun 2003, Vach Kompella wrote:
> > > - the IETF is too large, so we shouldn't be adding more work
> >
> > Yes.
>
> So we should not do any new work?!
We should focus on the work that is more integral to IP and the Internet.
> > 1. Virtual Private LAN Service. This is Internet-wise ethernet bridging
> > over routing protocols such as BGP, IS-IS, etc; further, this has
> > typically little respect for security implications which are implicit (or
> > even explicit) in LAN networks.
> >
> > So, my main points are:
> >
> > - we must not overload routing protocols and such infrastructure (IMHO,
> > this seems an inevitable path the work would go towards..)
>
> If you use LDP, it is NOT a routing protocol. The specific mode of use
> (targeted LDP) is already described in RFC 3036. The FECs are different, but
> the FEC TLV was defined in such a way as to be extensible.
Then LDP has been quite carefully cloaked as being one ("graceful restart
for LDP, ..") :-)
The problem is of course also with the statement "If you use LDP..". But
there also seem to be some interests in placing stuff elsewhere, like
in BGP.
> > - we must not create complexity by deploying ethernet bridging all over
> > the Internet. Our work should be focused on making IP work, not
> > specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a *service*).
>
> Primarily, folks want to use it as in "Ethernet-over-MPLS". That may not
> necessarily go down well with you either, but think of MPLS as a logical FR.
> Providers do not want to change their infrastructure, e.g., replace a FR cloud
> with an ATM cloud, then with SONET or GigE. That's mega-expensive. By
> abstracting the L2 using MPLS, they can provide the L2VPN service without
> wholesale infrastructure replacement.
Bridging networks at layer _3_ with VPN's is a bit questionable, but that
is a bit more in our radar. I don't think this is something we can
endorse, as a model.
> > - it is architecturally wrong: use different subnets, period -- that's
> > what those are meant for in the first place!
>
> Use different subnets to create VPNs? I don't understand what you mean. VPLS
> and VPWS address a requirement for multiple domains (aka VPNs), logically
> distinct from and invisible to each other.
Why would you want to do something like:
__-----___
Ethernet ( ) The _same_ Ethernet
segment ======= ( Internet ) ===== segment!
(__ ___)
-----
Instead, build two separate ethernet segments: one with IP addressing from
1.1.1.0/24 and the other from 1.1.2.0/24. You may even want to build a L3
VPN between the two.
But Ethernet? That seems misguided.
> > 2. Virtual Private Wire Service
> >
> > This is slightly better as you're "only" performing point-to-point
> > communication. Same considerations as above apply, to a slightly lesser
> > extent.
> >
> > Btw. how is this different from currently-specified GRE tunneling? It
> > being made a "service"?
>
> GRE-tunneling is one option, but only for the transport of the VC. However, you
> need a demux field to identify the VC that you are carrying. Carrying one
> customer VC between a pair of PEs is obviously not adequate.
I meant GRE tunneling between CPE's. :-)
> Tunneling is not new in the IETF. The fact that you are tunneling what may be
> non-IP packets seems to be giving you the heebie-jeebies. Why? What about the
> tn3270, dlsw, netbios over ip work that has gone on in the past? A little
> massaging to make the packet look like data to be carried over an IP network,
> and some implementation details at the edges.
I remember the multipoint media happen to have some assumptions about the
network, e.g. the use of interpacket delay and the use collision
detection. These change a lot of when you expand the scope of an Ethernet
beyond a physical segment. Of course, these may not be always
problematic, if you require switched Ethernet segments, but the thought is
worrisome regardless.
Moreover, we work on an IP layer. We enable IP layer to be able to handle
our tasks. If there is some problem why we cannot just use different IP
subnets between the two (or multiple) end-points, we need to fix that
problem, not burrow even further down the ISO layers.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings