Subject: Issues with draft-sajassi-mvpls-00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 20 Nov 2002 23:58:56 +0200

Ali and all,
I would like to re-state the issues I have raised at the PPVPN WG Session
today.
All these issues deal with the unicast part of the proposal.

1. Allocation of huge numbers of IP addresses (an IP address per AC).
   This looks highly problematic in inter-provider or even inter-AS
situations
   (where use of private IP addresses is precluded).

2. Involvement of core routers in the VPLS: with each new AC, all the core
routers
   have to learn routes to the associated IP address.
   I'd like to remind you that the PWE3 Charter (I am not sure about the
PPVPN one)
   explicitly states that PW functionality is limited to PEs only and that
PWs do not
   exert control over the underlying network. IMHO the proposal violates
these 
   principles.

3. Forwarding in the egress PE. The draft states that it is is based
   on the destination IP address found in the packet. It does not state
   whether aIP ddresses associated with an AC are considered as IP addresses
   owned by the PE router terminating this AC,or not. If they are not,
   the packets with the AC-associated destination IP address should be 
   forwarded as IP packets which seems wrong, because such forwarding 
   does not persume stripping of IP header, MAC address look-up etc.
   If they are, they would be treated based on the protocol number
   and according to the protocol-specific rules. In particular,if the
protocol
   is L2TPv3 (as mentionedin the presentation), the Session ID lookup would
be
   done and,if such a lookup fails (as it should since the draft explicitly
states
   that no sessions are established), the packet will be discarded (or so I
presume).

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked]
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

---

From: Ray Qiu <[email-masked]>
Date: Wed, 20 Nov 2002 20:52:22 -0800

I would think another potential scaling issue is that core routers have to
track all the Multicast states for all the VPLS's.

- Ray

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 22 Nov 2002 15:10:17 -0800

Sasha,

I answered some of these questions earlier but let me elaborate further ...

>    (where use of private IP addresses is precluded).

I think we agree that we don't have an issue with intra-AS since a provider 
has access to large address space based on RFC 1918.
Now if the majority of the traffic is intra-AS, then for the small 
percentage of the end-points that require inter-AS communications, one can 
assign addresses from the public address space.
However, if one still wants to reduce the number of public IP addresses, 
then he can do one of the following:
a) Assign an IP address per VPLS instance instead of per AC for that PE 
(this is described in the draft)
B) Make use of VPLS hierarchy with Ethernet access network (QinQ access 
network)
C) Use multi-segment Emulated LAN (one segment per AS)

>    have to learn routes to the associated IP address.

Not quite. Contrary to MPLS labels, IP addresses do get summarized in the 
core and thus not every time you add an AC, a route update is needed in the 
P nodes. Because of this route summarization, the amount of the states in 
the core is relatively small.

>    exert control over the underlying network. IMHO the proposal violates

Either requirements draft or the charter needs to be updated to make them 
consistent with each other.  I think the main reason for non-path-oriented 
PW is the network scalability (avoid keeping per PW state in the core) and 
if keeping per PW state in core is not a requirement for a path-oriented 
scheme, then that scheme can be considered as an alternative option.

However, given that MPVLS doesn't use the traditionally defined PW (as in 
PWE3), I might use the term tunnel instead of PW in the next rev. of the 
document to avoid confusion.

>    that no sessions are established), the packet will be discarded (or so I

As explained previously, it is the later case (IP addresses associated with 
the AC are owned by the PE) and as mentioned in the presentation, it can 
use either GRE or L2TPv3 encapsulation. In case of L2TPv3, it only uses the 
encapsulation part without session-id as I described in my previous email. 
Frankly given that L2TPv3 encap doesn't buy us anything over GRE, I am 
inclined to make it simple and narrowed it down to only GRE.

Regards,
Ali

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 22 Nov 2002 15:13:10 -0800

>track all the Multicast states for all the VPLS's.

There is only one multicast group address per VPLS instance and in tems of 
scalability is similar to multicast for L3VPN.

-Ali

---

From: Ray Qiu <[email-masked]>
Date: Fri, 22 Nov 2002 16:51:47 -0800

> scalability is similar to multicast for L3VPN.
That is true, but if you compare it with other VPLS solutions?

- Ray

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 22 Nov 2002 18:38:59 -0800

>That is true, but if you compare it with other VPLS solutions?

MVPLS is intended to complement (and not compete with) baseline VPLS 
solution by providing an efficient mechanism for the support of customers' 
multicast data.

-Ali