Subject: Doubts regarding draft-sajassi-mvpls-00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 7 Nov 2002 18:16:33 +0200

Ali, Hussein and all,
I have serious doubts regarding draft-sajassi-mvpls-00.txt.
I would highly appreciate clarification on the following issues:

1. The draft, as posted, assumes that a unique unicast IP address is
allocated for
    each Attachment Circuit connecting a customer site participating in the
MVPLS
    with its adjacent PE. (The draft considers the option that such an
address 
    is allocated per PE per VPLS "due to PE limitations"). IMHO this raises
strong 
    scalability issues especially when dealing with IPv4 networks, because 
    IP addresses that are unique within at least within the scope of the
provider's 
    network are a scarce resource. (I think that similar issues have been
    raised by Eric Rosen in his comments on
draft-ietf-ppvpn-cl-tunneling-vpn-00.txt
    that have been posted on the PPVPN WG list)

2. The common approach to PWE3 and PPVPN assumes (and this is reflected,
    e.g., in the PWE3 charter) that these activities affect only PEs but not
the
    core routers in the provider's network. IMHO your approach contradicts
    this approach because:
    a) Adding a new VPLS instance requires allocation of a new multicast IP
        address, and all the PE devices participating in this VPLS instance
        must join the multicast group associated with this address
    b) Adding a new Attachment Circuit requires an IGP update so that
        the network "learns" routes to the associated IP address
    c) AFAIK, each of these operations affects all the routers in the
       provider's network. 

3. In Section 8 you describe the process of forwarding of "known unicast" 
   frames in the egress PE like following:
<quote>
         When an egress PE receives a unicast MVPLS packet from the core, it

         performs the MAC SA lookup, and possibly learning, as has been 
         described in Section 8.2. The egress PE does not lookup the MAC DA
of 
         the received frame since the destination IP address of the received

         packet readily identifies the interface associated with the AC. The

         packet is immediately delivered to that interface. The IP header
and 
         the L2TPv3 header are removed before the Ethernet frame gets
forwarded 
         over the AC towards its destination. 
<end quote>

   This text raises several questions:
   a) How does the PE distinguish between the MVPLS packet and any other
      packet with the destination address that has been allocated
      for the Attachment Circuit? IMHO, the vague reference to L2TPv3
      is not sufficient, because the L2TPv3 switching engine would
      most probably just discard the packet with an unknown Session
      ID - and in order to make the Session ID known to this engine,
      it must be explicitly set up - via signaling or manually.
      In other words, your forwarding decisions seem to prevent
      "normal" usage of L2TPv3 in the same PE
   b) How are other packets with this destination address (e.g.,
      the ICMP Echo) processed? In other words, is the IP address
      associated with the AC in this PE treated as one of the
      IP addresses of the PE, or not?

With best regards,
                                   Sasha Vainshtein
email:     [email-masked]
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 07 Nov 2002 12:02:36 -0800

Sasha,

Thanks for your comments and inquiry. Please see my reply inline.

>     that have been posted on the PPVPN WG list)

Within the scope of the provider's network, the private address block 
[RFC1918] can be used which can provide very large number of IP addresses 
to address the scalability concern.

>     c) AFAIK, each of these operations affects all the routers in the

As described in draft-ietf-pwe3-requirements :
"PWs can be path-oriented or non-path-oriented. For path-oriented PWs, core 
network devices must maintain state information for them. If a large number 
of path-oriented PWs are used, core network devices will have to maintain a 
large amount of state information"
Furthermore, because of route summarization, not every time a new 
Attachment Circuit is added, it generates a IGP update.
Also, the MPtP and MPtMP PWs that are used in this draft, are not defined 
yet in the PWE3 framework and may need to be defined in the future.

>       "normal" usage of L2TPv3 in the same PE

We are just talking about a shim header for encapsulating Ethernet packets. 
Therefore, with respect to L2TPv3, we are just talking about the 
encapsulation portion of it and not the signalling. If you prefer, you can 
use some other name for it.

>       IP addresses of the PE, or not?

The packets with protocol-type of L2TPv3 for that AC gets forwarded to that 
interface and other packets with non-L2TPv3 protocol-type gets processed 
internally by the PE.

Regards,
Ali

---

From: Sasha Vainshtein <[email-masked]>
Date: Sat, 9 Nov 2002 14:58:50 +0200

Ali and all,
Thank you for a prompt response.
Please see also several brief 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: Thursday, November 07, 2002 10:03 PM
> To: Sasha Vainshtein; [email-masked]'; [email-masked]'
> Cc: [email-masked]; PWE3 WG (E-mail); Eric Rosen (E-mail)
> Subject: Re: Doubts regarding draft-sajassi-mvpls-00.txt
> 
> 
> 
> Sasha,
> 
Does this mean that the scope of the proposal is limited to a 
single AS?
> yet in the PWE3 framework and may need to be defined in the future.
Please note that the notionof path-oriented PW has been dropped in the
latest PWE3 Architecture document (draft-ietf-pwe3-arch-01.txt) exactly
for the reasons I have mentioned.
> interface and other packets with non-L2TPv3 protocol-type 
I am afraid this cannot work in a device that supports "normal"
L2TPv3, because it would not know whether the L2TP packets with
one of its own IP addresses should be forwarded to its L2TPv3
switching engine or to the MVPLS decap engine and, from there,
to the AC corresponding to the destination IP.