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

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 24 Nov 2002 07:23:08 +0200

Ali,
Thank you for a prompt response.
Please see some questions/comments inline.

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

> -----Original Message-----
> From: Ali Sajassi [mailto:[email-masked]]
> Sent: Saturday, November 23, 2002 1:10 AM
> To: Sasha Vainshtein; Ali Sajassi (E-mail)
> Cc: Ppvpn (E-mail)
> Subject: Re: Issues with draft-sajassi-mvpls-00.txt
> 
> 
> Sasha,
> 
> I answered some of these questions earlier but let me 
> elaborate further ...
> 
> At 11:58 PM 11/20/2002 +0200, Sasha Vainshtein wrote:
> >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).
> 
> 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)
I do not really understand how this helps. Can you please elaborate?
> C) Use multi-segment Emulated LAN (one segment per AS)
How will different segments be inter-connected?
> 
> 
> >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.
> 
> 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.
> 
I believe that ability of core routers to summarize routes depends on
specific allocation of IP addresses per AC in the given PE.
In other words, you should define some "allocation rules", e.g.:
* define a subnet per VPLS per PE with substantial width to accomodate
  a number of prospecive ACs
* subnets allocated for different PEs must be disjoint
* PEs must advertise route(s) to the subnets allocated to it.

> >    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.
> 
> 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.
>
I agree that the Charter and the requirements document must 
correspond to each other. To the best of my knowledge, the
new revision of the requirements draft (not posted yet) solves this
problem by dropping the notion of path-oriented PWs.
> 
> 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.
> 
I agree.
> 
> >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).
> 
> 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
> 
How will this interoperate with (potential) other uses of GRE in the
same PE, e.g., for MPLS-in-GRE?
> >
> >
> >-------------------------------------------------------------
> ---------------
> >--------
> >With best regards,
> >                           Sasha Vainshtein
> >email:   [email-masked]
> >phone:  +972-3-7659993 (office)
> >             +972-8-9254948 (home)
> >             +972-58-674833 (cellular)
>

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 25 Nov 2002 17:12:41 -0800

>Thank you for a prompt response.

You're welcome. Additional comments/clarifications inline ...

>Please see some questions/comments inline.

Basically it helps by reducing number of IP end points (e.g., IP PEs). When 
access network is Ethernet, the MVPLS will be confined to the core network 
and thus fewer number of IP end points are needed. You can think of the 
Ethernet access network as an aggregation network where customers' traffic 
first get aggregated before getting feed into the IP PE. Each customer VPLS 
instance is represented by a service provider vlan-id (the outer tag) in 
the access network. Ethernet access network is a low-cost and efficient way 
of traffic aggregation.

>How will different segments be inter-connected?

Each segment represent an emulated LAN and it looks and feels like a vlan 
to a GW. Therefore, a GW that connects multiple Emulated LAN segments, 
basically provides bridge functionality among them.

>   a number of prospecive ACs

Not per VPLS but per PE (this is unicast data that we are talking about).

>* subnets allocated for different PEs must be disjoint

yes

>problem by dropping the notion of path-oriented PWs.

Good.

Cheers,
Ali