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

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 3 Dec 2004 15:31:05 -0500

Curtis Villamizar wrote:
>> Is anyone actually interested in deploying this or is it more of an
> intellectual exercise.  The routing area has in the past required that
> there be a clear requirement for new work in a work group.
> 
> Curtis

I know of two vendors who are working on implementations and several Service Providers who have expressed interest.

In addition, the draft hardly qualifies as "new work". It is a straightforward application of MP-BGP. 

Peter

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 03 Dec 2004 16:51:49 -0500

In message <[email-masked]>
> In addition, the draft hardly qualifies as "new work". It is a straightforward application of MP-BGP. 

Peter,

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.

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Dec 2004 09:45:16 +0200 (EET)

> 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..

A couple of particular comments on the applicability text of the 
draft:

    To avoid manual provisioning of addresses, operators could provision
    point-to-point pseudo-wires between the ATM switches that directly
    connect to the MPLS core, and run PNNI routing and signaling on these
    pseudo-wires.

==> exactly, I'd suspect this has been done and continue to be done, 
and requires no special support at all.

    However, for several reasons that might be
    undesirable. Firstly, the ATM network islands may belong to different
    administrative domains.

==> this is an identical problem with the existing ATM cloud, i.e., 
introducing MPLS does not make it any worse.  As it is, you'll already 
have to use static ATM routes or run them in a single ATM cloud.

    Secondly, even within one administrative
    domain, an operator might not want to create one single, large ATM
    network because of scaleability concerns.

==> again, this already applies to the existing ATM network, or you'll 
have to do the same manual config.

    Thirdly, the introduction
    of an MPLS core creates a topological challenge that does not exist
    in traditional ATM networks. The overlay approach results in a full
    mesh of O(N*N) PNNI routing adjacencies, where N is the number of ATM
    switches that directly connect to the MPLS core. Each ATM switch that
    is directly connected to the MPLS core has to deal with O(N)
    adjacencies, where N can be quite large, thereby imposing a scaling
    burden on its ATM control plane.

==> is the number of ATM clouds connected over MPLS really that 
great?  If you are bothered by this scalability concern, you could 
also deploy a couple of ATM switches to keep down the number of 
adjacencies (similar to BGP route reflectors are used with BGP).

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