Subject: ppvpn effort support

From: "Steven.Wright" <[email-masked]>
Date: Wed, 23 Apr 2003 13:15:23 -0400

I regard the vpls effort as an important and significant development, both
for the evolution of MPLS technology, but more importantly for solving
various scaling issues in providing Ethernet related services. In order to
progress that work there need to be several different types of documents
developed as working group documents  -

- Service definition documents :
to define the specific problem space in which a solution is sought
e.g.
draft-shah-ppvpn-arp-mediation
draft-shah-ppvpn-ipls

define specific protocol functionalities that are not well defined elsewhere
and  it would be commercially useful to have industry agreements  in these
areas.
so I would like to support those as being working group documents.

They are, however, only addressing specific corner cases of Ethernet service
extensions and are somewhat peripheral to the main vpls discussion.

perhaps I have missed it, but I do not think there is a good description of
the problems that vpls is attempting to solve.
draft-fin-ppvpn-bridging-vpls  provides some insight into the bridging
component, but this is incomplete as a description of a bridging service.
there are Operations, administrating ad provisioning aspects that are also
not addressed effectively.
 draft-vaccine-ppvpn-mgt-frwk is a framework only , but mechanized
administration interfaces are required to scale beyond the limits of command
line administration.

QoS support will eventually be required in the service context.
draft-chiussi-ppvpn-qos-framework  attempts to address this. It is difficult
to effectively address this topic  however, without agreement on the service
context and the implementation architecture.

Solution space documents:

draft-lasserre-vkompella-ppvpn-vpls  provides a useful illustration of a
number of interesting components of a potential vpls service. I am not sure
that I understand all the design tradeoffs that are implied by this specific
solution though. The range of discussion on this list implies that there are
many viable solutions in this space.

In looking at the constraints associated with our networks, there are at
least two separate applications.

(1)  I believe there is a need for scaling the Ethernet service concept
into smaller low density implementations - and  draft-radoaca-ppvpn-gvpls
seems to capture this. I would support this as a working group effort.
(2)  We have a need for  scaling the Ethernet service concept beyond the
metro and into regional scales. The major issue here is extending service
across multiple  administrative boundaries.
while the hierarchical concepts of draft lasserre are important, I expect
these notions of hierarchy will be associated with administrative
boundaries. Administrative boundaries also imply administrative policy  and
BGP is the accepted tool for managing this. so I believe we need a solution
along the lines of draft-kompella-ppvpn-vpls and I think this should be a
working group document.

Steven Wright
Science & Technology
BellSouth

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Apr 2003 13:20:09 -0400

Steven> while the  hierarchical concepts of draft lasserre  are important, I
Steven> expect  these   notions  of   hierarchy  will  be   associated  with
Steven> administrative  boundaries.  Administrative  boundaries  also  imply
Steven> administrative  policy and  BGP is  the accepted  tool  for managing
Steven> this. 

I wonder  if you could  be more specific  about this, perhaps an  example of
inter-AS L2VPN  service where you  want to set  up policies at  the inter-AS
border.   I'd like  to  understand better  the  degree to  which the  policy
management is dependent on the underlying signaling protocol.

---

From: "Steven.Wright" <[email-masked]>
Date: Thu, 24 Apr 2003 13:42:33 -0400

Assume you have a large emulated Ethernet network that stretches across
multiple service boundaries i.e multiple AS's. I expect you will want to
have an  Ethernet service abstraction corresponding to each AS, i.e.
something like each AS will appear as a virtual switch in the emulated
topology. I think those virtual switch notions  are similar to the hierarchy
notions identified as needed for vpls. My point is that there will be
operational and administrative reasons for  having some emulated service
abstractions to match up with underlying network boundaries.

I expect that the emulation of Ethernet services over a Multi-AS network
will be of interest to a number of service providers, both within their own
networks and between service providers.
Even in the case of a  single provider Multiple-AS instantiation of a vpls
service, I expect BGP will be involved. I don't think there are any other
viable alternatives for inter-AS MPLS. So we needs must make best use of
what is available.

Steven Wright

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, April 24, 2003 1:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: ppvpn effort support
>
>
>

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 24 Apr 2003 20:54:06 +0300

> networks and between service providers.

sure.

 > viable alternatives for inter-AS MPLS. So we needs must make best use of

why would you need bgp or mpls if you have radius and l2tpv3?  radius
discovery works fine between providers and doesn't care about ASes.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Fri, 25 Apr 2003 12:25:55 -0400

Steven> Assume you have a large emulated Ethernet network that stretches across
Steven> multiple service boundaries i.e multiple AS's. I expect you will want to
Steven> have an  Ethernet service abstraction corresponding to each AS, i.e.
Steven> something like each AS will appear as a virtual switch in the emulated
Steven> topology. I think those virtual switch notions  are similar to the hierarchy
Steven> notions identified as needed for vpls. 

Are you  suggesting that if a  VPLS spans two  ASes, a MAC lookup  table for
that VPLS  needs to reside in the  border routers that attach  the two ASes?
I think that would correspond to  the hierarchy of the HVPLS scheme, but the
need to  do the MAC lookups  on the border  routers seems to place  a pretty
heavy load on them. 

Steven> My  point  is that  there  will  be  operational and  administrative
Steven> reasons for  having some emulated  service abstractions to  match up
Steven> with underlying network boundaries. 

I can see  that you might want your control connections  to terminate at the
border routers,  but I"d have  thought that you  still want to  maintain the
PE-to-PE pseudowire across the boundaries.

Steven> Even in the case of a  single provider Multiple-AS instantiation of a vpls
Steven> service, I expect BGP will be involved. I don't think there are any other
Steven> viable alternatives for inter-AS MPLS. 

I'd be  happy to hear the  specifics of what  BGP features make it  the only
viable alternative.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 25 Apr 2003 09:45:50 -0700

Eric,

> Steven> multiple service boundaries i.e multiple AS's. I expect you will want 
> Steven> to have an  Ethernet service abstraction corresponding to each AS, i.e.
> Steven> topology. I think those virtual switch notions  are similar to the hie
> Steven> hierarchy notions identified as needed for vpls. 
> 

Isn't that what is suggested by draft-lasserre-vkompella-ppvpn-vpls-04.txt ?

 10.3.  Multi-domain VPLS service 
    
   Hierarchy can also be used to create a large scale VPLS service 
   within a single domain or a service that spans multiple domains 
   without requiring full mesh connectivity between all VPLS capable 
   devices.   Two fully meshed VPLS networks are connected together 
   using a single LSP tunnel between the VPLS gateway devices.  A 
   single spoke pseudowire is setup per VPLS service to connect the two 
   domains together.  The VPLS gateway device joins two VPLS services 
   together to form a single multi-domain VPLS service.  The 
   requirements and functionality required from a VPLS gateway device 
   will be explained in a future version of this document. 

I certainly agree with you that doing the MAC lookup on the border
routers (aka VPLS gateways) would place a pretty heavy load on them, 
and more generally would adversely impact scalability. 

Moreover, doing MAC lookup  on border routers (aka VPLS gateways)
would also require the service provider to run STP on a per VPLS
customer to make sure that there is no looping when either (a) a
pair of ASs have more than one interconnect, or (b) VPLS service
spans more than one AS and the topology at the AS level is richer
than a spanning tree, or (c) both (a) and (b). 

Yakov.

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 25 Apr 2003 10:04:29 -0700

Yakov,

>    will be explained in a future version of this document.

What does inter-AS mean?  Some providers have a lot of AS's.  Does it mean
across provider boundaries, administrative domains, does it involve security
considerations?

Multi-domain VPLS is just to show that there is a way to connect metro areas
(which is what the primary motivation that some providers gave us for that
particular section).

---

From: "Mark Seery" <[email-masked]>
Date: Sat, 26 Apr 2003 15:16:50 -0700

>> Vach: What does inter-AS mean? <<

Let us take two common uses of domain/area and AS concepts a) to aid scaling
b) to provide administrative boundaries.

Remembering that we are creating a VPLS per subscriber company, reminds as
that one of the benefits of using a server trail (arguments about Ethernet
defficiencies aside for now) is to provide complete service transparency,
i.e. the subscriber should be able to use any addressing (MAC, VLAN,
etc.)they desire.

Therefore, when going across an AS boundary, this service transparency
should be maintained. If we just dump everything out again into native
Ethernet at the AS boundaries, can we maintain this service transparency?
There are probably more issues than just the burden of MAC address lookup on
the border routers, there is the need to map back to QinQ for example to
maintain service transparency across an aggregated link.

Eric Rosen asked the question why not just extend the psuedowire across the
boundaries. Beautiful. This maintains the VPN/VPLS and hence the service
transparency. However, does it aid in scaling (does it limit the PE mesh -
perhaps a spoke between two hubs?), and does it aid in administration (are
there policy engines that can be applied to psuedowires; are policy engines
required/useful for a signaled connection/NNI)?

That we may come to a point where we observe that there is inter-domain work
that is different and unique to intradomain work seems entirely consistent
with our experience in other contexts. This may also be a reason why
multiple VPLS proposals go forward, as has been suggested by Philippe Niger
and Steven Wright.

Mark

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 28 Apr 2003 06:00:30 -0700

Vach,

>>> need to  do the MAC lookups  on the border  routers seems to place 
>>> a prety heavy load on them.
>>

"inter-AS" means spanning more than one Autonomous System (AS). It
should cover both the case where the ASs belong to the same provider,
as well as to a group of providers.

> (which is what the primary motivation that some providers gave us for that

That is the *only* way documented so far in 
draft-lasserre-vkompella-ppvpn-vpls-04.txt. And as I mentioned
before, it has fairly poor scaling properties due to (a) the need to
perform the MAC lookups on the border routers, and (b) the need to
run STP on a per VPLS basis for VPLSs that span multiple ASs.

In fact, those familiar with BGP/MPLS VPNs (aka 2547 VPNs), and
specifically with the inter-AS support could notice that the inter-AS
support proposed in draft-lasserre-vkompella-ppvpn-vpls-04.txt is
analogous to the option (a) in Section 10 of 2547bis. In contrast
the inter-AS approach described in draft-kompella-ppvpn-vpls-01.txt
can support what is analogous to the option (c) in Section 10 of 2547bis, 
which (as observed in 2547bis) is more scalable than option (a).

Yakov.

---

From: [email-masked]
Date: Mon, 28 Apr 2003 15:20:18 +0200

Vach, all,

it has been suggested for draft-lasserre-vkompella to refer to
draft-rosen-ppvpn-l2-signaling-02.txt for the LDP-based signaling. Is
this planned for when/if draft-lasserre-vkompella becomes a WG draft ?

This should enable one to use draft-rosen-ppvpn-l2-signaling, section
5.5 for inter-AS scenarios, which would be more like what
draft-kompella-ppvpn-vpls proposes.

Jeremy.
--

---

From: Eric Rosen <[email-masked]>
Date: Mon, 28 Apr 2003 10:51:04 -0400

Yakov> In  fact, those  familiar with  BGP/MPLS  VPNs (aka  2547 VPNs),  and
Yakov> specifically with the inter-AS support could notice that the inter-AS
Yakov> support  proposed  in  draft-lasserre-vkompella-ppvpn-vpls-04.txt  is
Yakov> analogous to the option (a) in Section 10 of 2547bis. 

There's  nothing fundamental  about the  lasserre-vkompella  procedures that
forces one to  have MAC lookup tables in the border  routers.  With a slight
generalization of the signaling protocol  (using the "Generalized ID FEC" of
draft-ietf-pwe3-control-protocol),  one   can  provide  a   model  which  is
analogous to  the other,  more scalable, options  of section 10  of 2547bis.
See section  5.5.4 of draft-rosen-ppvpn-l2-signaling.   (Thanks, Jeremy, for
noticing!)   That also  shows how  one can  run the  pseudowires  across the
boundary, while also  providing a control point at the  boundary that can be
useful in  doing OAM,  and in determining  whether packets are  entering and
leaving  your system  as they  should  be; this  could be  important in  the
multi-provider finger pointing exercises. ;-)

I had thought  that a suggestion was made to (a)  provide a service boundary
of some sort at the border routers, and (b) to use BGP-based signaling to do
so.  That's what I was asking for clarification about.

---

From: "Vach Kompella" <[email-masked]>
Date: Mon, 28 Apr 2003 12:14:56 -0700

Yakov,

You misunderstand what is described in draft-lasserre-vkompella.

The spoke connection between a "border" PE and another is a draft-martini pipe.
The behavior is exactly analogous to that described in section 10(a) of
draft-ietf-ppvpn-rfc2547.  This behavior is precisely that of extending a
customer sub-interface into the VPLS over an extension that may be an RFC1483
PVC, an RFC 1490 PVC, a draft-martini pipe, a q-tagged pipe, etc.  Perhaps it
seems that the spoke has those VPLS properties because it may be connected to an
MTU that is bridging capable.  That, however, is not a spoke property; rather it
is the property of a bridge that has multiple spokes (aka interfaces, whether
logical or physical).

A spoke does not have learning associated with it.  An ethernet packet put into
a spoke is just transmitted down the spoke.  In fact, this particular behavior
is what makes the spoke a scalable addition to the basic VPLS model in the
intra-metro HVPLS model.

However, if you have two spokes, you have to replicate on the spokes (a VPLS
function at the PE, and an 802.1d bridge function at an MTU, not a spoke
function).

No STP is needed for a VPLS.  STP may be required on a spoke.  However, if one
is required on a spoke, it is because spokes are treated as extensions to
customer interfaces, and STP may run on customer interfaces.

-Vach

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 6:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> >> Isn't that what is suggested by
> draft-lasserre-vkompella-ppvpn-vpls-04.txt ?
> >>

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Apr 2003 07:22:47 -0700

Vach,

> You misunderstand what is described in draft-lasserre-vkompella.

I don't think so...

> The spoke connection between a "border" PE and another is a
> draft-martini pipe.  The behavior is exactly analogous to that
> described in section 10(a) of draft-ietf-ppvpn-rfc2547. 

Glad that you agree with me that the inter-AS solution proposed
in draft-lasserre-vkompella is exactly analogous to the
option (a) in Section 10 of rfc2547bis. 

> This behavior is precisely that of extending a customer sub-interface
> into the VPLS over an extension that may be an RFC1483 PVC, an RFC
> 1490 PVC, a draft-martini pipe, a q-tagged pipe, etc.  Perhaps it
> seems that the spoke has those VPLS properties because it may be
> connected to an MTU that is bridging capable.  That, however, is
> not a spoke property; rather it is the property of a bridge that
> has multiple spokes (aka interfaces, whether logical or physical).
> 
> A spoke does not have learning associated with it.  An ethernet
> packet put in to a spoke is just transmitted down the spoke.  In
> fact, this particular behavior is what makes the spoke a scalable
> addition to the basic VPLS model in the intra-metro HVPLS model.
> 
> However, if you have two spokes, you have to replicate on the spokes
> (a VPLS function at the PE, and an 802.1d bridge function at an
> MTU, not a spoke function).
> 
> No STP is needed for a VPLS.  STP may be required on a spoke.
> However, if on e is required on a spoke, it is because spokes are
> treated as extensions to customer interfaces, and STP may run on
> customer interfaces.

To make the discussion more specific let's look at couple of examples:

Example 1: CE1, CE2, and CE3 belong to the same VPLS that spans three 
ASs (AS1, AS2, and AS3):

                                    Border --- AS 3 -- PE C - CE3
                                    Router 31  
                                  /                 
                                 /                   
 CE1 -- PE A ------- AS 1 --- Border ----- Border ------ AS 2 -- PE B -- CE2
                              Router 12    Router 21       

Q1: When some host behind CE1 sends a packet destined to some host
behind CE2, and the packet arrives at Border Router 12, how would
this border router know whether to send this packet to Border Router
21 or to Border Router 31 (other than by performing MAC address
learning) ?

Q2: When this packet arrives at Border Router 21, how would this
border router know that it has to send the packet to PE B, rather
than to some other PE (other than by performing MAC address learning) ?

Example 2: CE1, CE2, and CE3 belong to the same VPLS that spans
two ASs (AS1 and AS2), and these ASs have multiple interconnects):

                            -  Border---- Border --
                           |  Router 23  Router 32 |
                           |                       |
                           |                       |
 CE1 -- PE A ------- AS 1 --- Border ----- Border ------ AS 2 -- PE B -- CE2
                              Router 12    Router 21       |
                                                           |
                                                          PE C
                                                           |
                                                           |
                                                          CE3

Q3: Since AS1 and AS2 are interconnected not by one, but by two
pairs of ASBRs, would both ASBRs simultaneously be used for forwarding
VPLS traffic for the VPLS formed by CE1, CE2 and CE3 ? If not, then
what are the procedures by which only one of those pairs be selected ?
If only one of these pairs is selected, then what are the procedures
to handle either failure of an ASBR in the selected pair or a link between
the selected ASBRs ?

Yakov.