Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc?

From: Ali Sajassi <[email-masked]>
Date: Wed, 22 Sep 2004 17:09:26 -0700

There are some areas of ambiguity and inaccuracies in this draft where I'd 
like to be addressed first.

Sec 5.1, 2nd para, pg 9:
-----------------------------------
"In this scenario, one issue that SPs needs to address is that different 
sites of a customer may have a mismatch of 802.1Q tags (either different 
.1q tags on each side, or .1q tag on one side, and untagged on the other 
side). For example, customer connectivity at one site will be tied to a 
port on a VPLS PE/MTU that will utilize a PW for tunneling this packet 
through the network. Customer connectivity at another site will be 
interconnected to a port on a QinQ switch that will utilize QinQ techniques 
(see the figure below). By mandating that "the Ethernet packet that 
traverses a VPLS is always a customer Ethernet packet", the [VPLS-LDP] 
solution naturally accommodates this need. "

If the access networks are based on 802.1ad standards (formerly QinQ), then 
this issue has already been addressed since .1ad standard allows for VLAN 
tag translation at the UNI (e.g., two customer sites can have two different 
tags).

Also the issue of port mode versus vlan mode is orthogonal to the type of 
PW used (e.g., tagged mode versus raw mode). In other words, in your 
example above, I can still have port mode service between MPLS and QinQ 
access and use tagged mode PW over MPLS although raw mode should be the 
preferred mode.

Sec 5.2,  1st para, pg 10:
-------------------------------------
"Providers that have already deployed VLAN based core may choose to overlay 
an MPLS edge on top of this existing L2 domain. In this method, provider 
802.1Q tags maybe assigned to MPLS backbone links that are then used for 
carrying VPLS traffic. While this approach may allow for a simple 
transition to solve some immediate deficiencies of a pure L2 network, it 
still does not solve some of the underlying problems associated with 
protocols such as spanning tree. In this case, although MPLS may provide 
some scaling advantages, the limitations associated with spanning tree can 
still pose potential problems to the overall infrastructure. "

This paragraph is not clear to me at all and I am not sure what is 
suggested here. I suggest if this is not viable solution, then delete this 
paragraph instead of suggesting something that creates more issues.

Sec 5.2,  2nd para, pg 11:
-------------------------------------
"Alternatively, a parallel VPLS core is built and connected to the existing 
802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively treated as a 
super-island. Then one by one, each individual Ethernet access island is 
disconnected from the existing core (i.e. super- island) and connected to 
the VPLS core. The migration issues then become similar to those described 
in 5.1. "

Need to mention that  inter-operability aspects between .1ad network and 
MPLS/VPLS network shall be worked out before such migration.

Sec 5.2, 3rd para, pg 11:
------------------------------------
"A third approach consists in configuring a second VPLS control plane in 
the existing QinQ PE, hence implementing two virtual networks over a single 
physical infrastructure. Once the PE/MPLS control plane is running, each 
customer can be separately migrated through a reconfiguration of its 
corresponding access ports. For increased stability, the dual control plane 
approach might require dedicating some links or PEs to the MPLS/VPLS network."

It should be mentioned that this is only feasible when the QinQ PE can be 
easily upgraded (e.g., via software/firmware) to MPLS PE; otherwise, you 
need to forklift everything.

Sec 6, 1st para, pg 11: The first paragraph talks about two instances of 
multi-homing but only a single instance is mentioned in the text below it.

Sec 7, 3rd para, pg 13: This paragraph is not clear.

Sec 7, 4th para, pg 13: I assume that the loop protection scheme that you 
are talking in here is the loop within the customer network and not the 
provider network - e.g., due mis-configuration of its loop prevention 
protocol or lack of one. If that is the case, then it should be clearly 
specified in this paragraph because having the loop within the customer 
network (when it is dual-homed) doesn't mean that there is a loop inside 
the provider network.

Sec 8, pg14: It should be mentioned that in steady state (e.g., when there 
is no failure), there shall be no re-ordering of Ethernet packets within a 
VPLS instance. This can be achieved by ensuring that ECMP algorithms do 
inter-flow (instead of intra flow) load balancing which is typically the 
case - e.g., load balance among different PWs and thus different VPLS 
instances.

Sec 13.1, pg 16: Customer tag enforcement should be done at the UNI and I 
don't see how a link between a CE and a PE can be shared by multiple 
customers. Also in the last sentence, do you mean a bridge instead of a 
router. The only case that I can think of is for .1q (and not .1ad since 
.1ad allows for tag translation). If it is for .1q, then it should be 
clearly stated and it should be mention that in order to enforce 
non-overlapping VLAN among different customer, an ACL per customer AC 
should be used.

Sec 13.2, pg 16: There should be a distinction made between broadcast 
domain and mac address domain. FIB tables guarantee the separation of MAC 
address domains among different VPLS instances and a full-mesh of PWs per 
VPLS instance guarantees the separation of broadcast domains among VPLS 
instances. So the two toegther guarantee traffic separation between VPLS 
instances. The section should be modified to reflect this accordingly.

Sec 15, pg 20, one-to-last para: This paragraph should be corrected - 
Ethernet OAM already provides trace route capability for fault isolation 
without the need for TTL.

-Ali

At 11:43 AM 9/3/2004 +0200, Loa Andersson wrote:
>WG,
>
>in the L2VPN meeting in San Diego a L2VPN applicability
>statement were discussed. The minutes says:
>
>"... ask the question on the mailing list and see if
>there is consensus to make this a WG document. The Chairs
>specifically request input from service providers with
>deployment experience."
>
>The draft has now been updated and the current version is
>draft-lasserre-l2vpn-vpls-ldp-applic-02.txt.
>
>Please respond to the question above, whether this should
>be a l2vpn working document or not, preferably to the
>mailing list, but at least to the wg chairs. A simple
>yes or no is sufficent. Since this a call to see there
>is consensus both positive and negative responses are
>appropriate.
>
>Responses within in two weeks, snce the wg chairs plan
>to make the consensus call the week of August 20th.
>
>Input from operators/service providers is encouraged.
>
>Note: Adopting an ID as a working document is not to
>       say that it covers every aspect of the problem,
>       but that it is a good enough starting for the
>       working group when solving the problem.
>
>
>/Loa
>
>--
>Loa Andersson
>
>Principal Networking Architect
>Acreo AB                           phone:  +46 8 632 77 14
>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>Kista, Sweden

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 Sep 2004 11:29:16 +0200

Ali (and working group),

thanks for these valid and valuable comments. I guess I
aggree with most, and see them good input to iomprove the
doc.

With my wg co-chair hat on I don't see them as stoping the
draft to become a wg doc.
The way I see the process is that when a ID becomes a working
document is when the working group takes over the revision
control of the document. At that point we need the following:

- an ID addressing a problem that there is rough consensus
   on that the working group needs to solve
- a rough consensus that this ID is a good enough starting
   point to solve this problem

After this the working group starts preparing the ID to
eventually be published as an RFC, I see your comments as
part of that process.

I think we have that ID and therefore I've requested that
the authors republish the document as:
draft-ietf-l2vpn-vpls-ldp-applic-00.txt

I've also told them in doing so it would be useful to
incorporate and/or respond to your comments.

/Loa

Ali Sajassi wrote:

> 
> 
> There are some areas of ambiguity and inaccuracies in this draft where 
> I'd like to be addressed first.
> 
> Sec 5.1, 2nd para, pg 9:
> interconnected to a port on a QinQ switch that will utilize QinQ 
> techniques (see the figure below). By mandating that "the Ethernet 
> packet that traverses a VPLS is always a customer Ethernet packet", the 
> [VPLS-LDP] solution naturally accommodates this need. "
> 
> If the access networks are based on 802.1ad standards (formerly QinQ), 
> then this issue has already been addressed since .1ad standard allows 
> for VLAN tag translation at the UNI (e.g., two customer sites can have 
> two different tags).
> 
> Also the issue of port mode versus vlan mode is orthogonal to the type 
> of PW used (e.g., tagged mode versus raw mode). In other words, in your 
> "Providers that have already deployed VLAN based core may choose to 
> overlay an MPLS edge on top of this existing L2 domain. In this method, 
> provider 802.1Q tags maybe assigned to MPLS backbone links that are then 
> used for carrying VPLS traffic. While this approach may allow for a 
> simple transition to solve some immediate deficiencies of a pure L2 
> network, it still does not solve some of the underlying problems 
> associated with protocols such as spanning tree. In this case, although 
> MPLS may provide some scaling advantages, the limitations associated 
> with spanning tree can still pose potential problems to the overall 
> infrastructure. "
> 
> suggested here. I suggest if this is not viable solution, then delete 
> this paragraph instead of suggesting something that creates more issues.
> 
> "Alternatively, a parallel VPLS core is built and connected to the 
> existing 802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively 
> treated as a super-island. Then one by one, each individual Ethernet 
> access island is disconnected from the existing core (i.e. super- 
> island) and connected to the VPLS core. The migration issues then become 
> similar to those described in 5.1. "
> 
> the existing QinQ PE, hence implementing two virtual networks over a 
> single physical infrastructure. Once the PE/MPLS control plane is 
> running, each customer can be separately migrated through a 
> reconfiguration of its corresponding access ports. For increased 
> stability, the dual control plane approach might require dedicating some 
> links or PEs to the MPLS/VPLS network."
> 
> It should be mentioned that this is only feasible when the QinQ PE can 
> be easily upgraded (e.g., via software/firmware) to MPLS PE; otherwise, 
> you need to forklift everything.
> 
> 
> Sec 7, 4th para, pg 13: I assume that the loop protection scheme that 
> you are talking in here is the loop within the customer network and not 
> the provider network - e.g., due mis-configuration of its loop 
> prevention protocol or lack of one. If that is the case, then it should 
> be clearly specified in this paragraph because having the loop within 
> the customer network (when it is dual-homed) doesn't mean that there is 
> a loop inside the provider network.
> 
> Sec 8, pg14: It should be mentioned that in steady state (e.g., when 
> there is no failure), there shall be no re-ordering of Ethernet packets 
> within a VPLS instance. This can be achieved by ensuring that ECMP 
> algorithms do inter-flow (instead of intra flow) load balancing which is 
> typically the case - e.g., load balance among different PWs and thus 
> different VPLS instances.
> 
> Sec 13.1, pg 16: Customer tag enforcement should be done at the UNI and 
> I don't see how a link between a CE and a PE can be shared by multiple 
> domain and mac address domain. FIB tables guarantee the separation of 
> MAC address domains among different VPLS instances and a full-mesh of 
> PWs per VPLS instance guarantees the separation of broadcast domains 
> among VPLS instances. So the two toegther guarantee traffic separation 
> between VPLS instances. The section should be modified to reflect this 
> accordingly.
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

---

From: "Marc Lasserre" <[email-masked]>
Date: Thu, 23 Sep 2004 13:31:56 +0200

Ali,

Thanks for your valuable feedback. I will update the draft to incorporate 
your comments and address the ambiguities that you have raised before 
submitting it as a WG doc.

Marc
----- Original Message ----- 
From: "Ali Sajassi" <[email-masked]>
To: "Loa Andersson" <[email-masked]>; "L2VPN" <[email-masked]>; "Rick Wilder" 
<[email-masked]>; "Vach Kompella" <[email-masked]>
Sent: Thursday, September 23, 2004 2:09 AM
Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc?

> techniques (see the figure below). By mandating that "the Ethernet packet 
> that traverses a VPLS is always a customer Ethernet packet", the 
> then this issue has already been addressed since .1ad standard allows for 
> VLAN tag translation at the UNI (e.g., two customer sites can have two 
> different tags).
>
> used for carrying VPLS traffic. While this approach may allow for a simple 
> existing 802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively treated 
> as a super-island. Then one by one, each individual Ethernet access island 
> is disconnected from the existing core (i.e. super- island) and connected 
> to the VPLS core. The migration issues then become similar to those 
> described in 5.1. "
>
> single physical infrastructure. Once the PE/MPLS control plane is running, 
> each customer can be separately migrated through a reconfiguration of its 
> corresponding access ports. For increased stability, the dual control 
> plane approach might require dedicating some links or PEs to the MPLS/VPLS 
> network."
>

---

From: "John Smith" <[email-masked]>
Date: Thu, 23 Sep 2004 17:38:32 +0530

Hi,

Can we use this draft to automatically discover VPLS nodes across different
sites?

Regards,
John

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 23 Sep 2004 16:02:13 -0700

>incorporate and/or respond to your comments.

Yes, the issues were not show stoppers, so I am O.K. with incorporation of 
my comments in the next rev of this draft as WG draft.

-Ali

>>MPLS may provide some scaling advantages, the limitations associated with 
>>spanning tree can still pose potential problems to the overall 
>>infrastructure. "
>>access island is disconnected from the existing core (i.e. super- island) 
>>and connected to the VPLS core. The migration issues then become similar 
>>to those described in 5.1. "