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

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

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

> -----Original Message-----
> From: Sasha Vainshtein 
> Sent: Thursday, November 07, 2002 6:17 PM
> To: [email-masked]'; [email-masked]'
> Cc: Ppvpn (E-mail 2); PWE3 WG (E-mail); Eric Rosen (E-mail)
> Subject: Doubts regarding draft-sajassi-mvpls-00.txt
> 
> 
> 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.

At 06:16 PM 11/7/2002 +0200, Sasha Vainshtein wrote:
>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

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.

>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

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.

>3. In Section 8 you describe the process of forwarding of "known unicast"
>          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
>    a) How does the PE distinguish between the MVPLS packet and any other

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)

> 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,
> 
> that such an
> IMHO this raises
> scope of the
Does this mean that the scope of the proposal is limited to a 
single AS?
> only PEs but not
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.
> lookup the MAC DA
> The IP header
> frame gets
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.