Subject: Comments on draft-ietf-l2vpn-vpls-multihoming-06

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 29 Jul 2013 12:18:13 +0000

Hi there

I have reviewed this draft and have a few comments and questions.  Please let me know if any of it requires clarification.  Generally, I think it looks good and adds good function.

Best regards
Jon

Section 1

"Section 7<http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-multihoming-06#section-7> may

   someday discuss security considerations."
You should probably fix that before the security ADs see it :)

Section 1.1
It is intuitively quite easy to picture what a VPLS Site is, but I am confused by its formal definition.

"A VPLS site is a grouping of ports on a PE that belong to

   the same VPLS domain."

is incompatible with

"A VPLS site connected to multiple PEs is called as multi-homed site."

since the former statement defines a VPLS Site to be a grouping of ports on a single PE only.  The former statement also seems incomplete as it disallows a situation where multiple customer sites in the same VPLS domain are homed to a single PE router (which is clearly within the scope of the draft).

My intuitive understanding of a VPLS Site is something like a subset of a customer network that would remain connected at layer 2 if the service provider network were removed.  I think the definition should be built around this idea.  This allows >1 site to connect to a single VE, and clarifies what is really meant by a multi-homed VPLS site.

Section 3.2
para 4 :

"If both CE1 and

   CE4 connectivity to PE1 is down, remote PEs can chose not to send

   multicast traffic to PE1 as there are no VPLS sites reachable via

   PE1."

Typo: s/chose/choose/

This sentence implies that remote PE routers use the D bit in the CE NLRI to decide that the sending PE router has lost connectivity to all its sites.  But, if it is optional to assign a CE ID to single-homed sites then there is no way to know that there is not another site, say CE5, hiding behind PE1.

I think that the sentence is misleading.  Remote PE routers use the D bit in the VE NLRI, not the CE NLRI, to make this decision.

Rather than connectivity going down, I think the more relevant case is when PE1 loses the DF election for CE1.  (This is discussed in section 3.4.)  In this case, the D bit will not be set.  But, remote PE routers can still decide not to send multicast traffic to PE1 when it loses the DF election for CE1 provided that they are sure there are no other sites that are homed to PE1.  They cannot make this decision unless a CE ID is assigned to CE4.

I think the draft should give a stronger requirement on advertising CE-IDs for single-homed sites.  If a multi-homed site connects to a given PE router, then any single-homed sites in the same VPLS domain that also connect to that PE router MUST be configured with CE-IDs.

Section 3.3.1
Figure 3 - alignment is off.

On this new text:

"Note that F bit is only applicable to VE NLRI and is not

       applicable to CE NLRI."

I think it's the other way around - the F bit is applicable in the CE NLRI and not the VE NLRI.  At least, that's what it says in section 5.1.

Section 3.4
"egress PEs" is a bit confusing.  They can also be ingress PEs for traffic going the other way...  You mean the PEs that are not connected by an AC to the multi-homed site.

Section 6.1
Why not create PWs to all unique VEs?  If you only choose one of them, won't you end up isolating all but one of the sites connected to the back-level PE?  Perhaps I am missing something.

---

From: Bhupesh Kothari <[email-masked]>
Date: Mon, 29 Jul 2013 11:06:50 -0700

Hi Jon,

Thanks for the detail review.  My comments are inline.

Bhupesh

Jonathan Hardwick <[email-masked]> wrote:

> Hi there
> 
>  
> 
> I have reviewed this draft and have a few comments and questions.  Please let
> me know if any of it requires clarification.  Generally, I think it looks good
> and adds good function.
> 
>  
> 
> Best regards
> 
> Jon
> 
>  
> 
>  
> 
> Section 1
> 
> ?Section 7 may
> 
>    someday discuss security considerations.?
> 
> You should probably fix that before the security ADs see it J

Will fix by next version.

> ?A VPLS site is a grouping of ports on a PE that belong to
> 
>    the same VPLS domain.?
> 
>  
> 
> is incompatible with
> 
>  
> 
> ?A VPLS site connected to multiple PEs is called as multi-homed site.?
> 
>  
> 
> since the former statement defines a VPLS Site to be a grouping of ports on a
> single PE only.

It does not say or imply that customer ports connect to only a single
PE.  All it is saying is that grouping of customer ports on a PE
(within a VPLS domian) is a VPLS site.

>  The former statement also seems incomplete as it disallows a
> situation where multiple customer sites in the same VPLS domain are
> homed to a single PE router (which is clearly within the scope of
> the draft).

All procedures and explanation are in the context of a single VPLS
domain as operation across VPLS domains is meaningless.  Of course,
you can have many VPLS domains (that maps to many customers) on a PE. 

> My intuitive understanding of a VPLS Site is something like a subset of a
> customer network that would remain connected at layer 2 if the service provider
> network were removed.  I think the definition should be built around this
> idea.  This allows >1 site to connect to a single VE, and clarifies what is
> really meant by a multi-homed VPLS site.

The definitions are from the perspective of PE.  Consider a VPLS
domain with N customer facing ports.  Whether those N ports are
grouped in one, two or N sites is upto the operator (hopefully based
on the actual customer network topology).  However, no direct
inference should be made simply based on how ports are grouped into
sites.  For example, two different customer locations single homed to
the same PE can still be grouped together as one VPLS site on the PE.
If you remove the PE (provider network), the two locations will not be
able to communicate. 

If you have a better way of explaing the definitions, feel free to
provide the text.

> ?If both CE1 and
>    PE1.?

Will fix it.

> This sentence implies that remote PE routers use the D bit in the CE
> NLRI to decide that the sending PE router has lost connectivity to
> all its sites.  But, if it is optional to assign a CE ID to
> single-homed sites then there is no way to know that there is not
> another site, say CE5, hiding behind PE1.  I think that the sentence
> is misleading.  Remote PE routers use the D bit in the VE NLRI, not
> the CE NLRI, to make this decision.

You are correct.  I reword the paragraph.  I'll add another section to
further clarify what a local and remote PEs do when site connectivity
is lost. 

> 
>  
> 
> Rather than connectivity going down, I think the more relevant case is when PE1
> loses the DF election for CE1.  (This is discussed in section 3.4.) 

Both cases are equally relevant for the aspect of explaining what the
procedures are. 

> In this case, the D bit will not be set.  But, remote PE routers can
> still decide not to send multicast traffic to PE1 when it loses the
> DF election for CE1 provided that they are sure there are no other
> sites that are homed to PE1.  They cannot make this decision unless
> a CE ID is assigned to CE4.

Remote PEs must always send multicast traffic to PE1 unless PE1
advertises D bit in its VE NLRI.  Note that if D bit is set in the VE
NLRI, the complete VPLS instance is operationally down on PE1 and no
traffic for that VPLS domain should be send to PE1.

Multicast is a special case and it is not necessary to send multicast
traffic to all VPLS sites, but how to achive that is outside the scope
of this draft.  This draft describes the defalt case of sending it all
VPLS sites.  The only time a remote PE can decide to not send is if D
bit is set in VE NLRI.

As I said before, I'll reword paragraph 4 of Section 3.2 and explain
more about use of CE NLRIs and how to handle connectivity status
updates.

> I think the draft should give a stronger requirement on advertising CE-IDs for
> single-homed sites.  If a multi-homed site connects to a given PE router, then
> any single-homed sites in the same VPLS domain that also connect to that PE
> router MUST be configured with CE-IDs.

Mandating to have CE-IDs for single homed sites can handle one case:
to indicate to remote PEs that connectivity to all local sites is
down.  However, this can also be achived by simply advertising D bit
in the VE NLRI.

> 
>  
> 
> Section 3.3.1
> 
> Figure 3 ? alignment is off.

Will fix it.

>  
> 
> On this new text:
> 
>  
> 
> ?Note that F bit is only applicable to VE NLRI and is not
> 
>        applicable to CE NLRI.?
> 
>  
> 
> I think it?s the other way around ? the F bit is applicable in the CE NLRI and
> not the VE NLRI.  At least, that?s what it says in section 5.1.

In the data path, there is no association of MAC addresses to remote
VPLS sites.  The association is between MAC addresses and PWs.  In
other words, a remote PE receiving the traffic simply creates an
assocation of MACs to PWs.  Therefore, when it is time to flush the
MACs from a particular site, a PE cannot determine which MACs to flush
and can only flush all the MACs assocated from the PE it received.
This is explained in paragraph 2 for Section 5.1.  However, paragraph
3 of Section 5.2 has a typo; it should be VE and not CE in context
of F bit.  I'll fix it.
 
Note that how to flush limited set of MAC addresses is outside the
scope of the draft.  This is also mentioned in the draft. 

>  
> 
> Section 3.4
> 
> ?egress PEs? is a bit confusing.  They can also be ingress PEs for traffic
> going the other way...  You mean the PEs that are not connected by an AC to the
> multi-homed site.

Egress PEs in this paragraph are in the context of PEs doing the DF
election on processing the VPLS advertisements from the PEs that have
multi-homed sites.  I'll repharse the sentence. 

> 
>  
> 
> Section 6.1
> 
> Why not create PWs to all unique VEs?  If you only choose one of them, won?t
> you end up isolating all but one of the sites connected to the back-level PE? 
> Perhaps I am missing something.

This section is for backwards compatibility.  In exisiting
implementations, a PE (for a particular VPLS domain) can advertise
valid label blocks for multiple CE IDs as opposed to just the VE ID in
this draft.  To interop with existing behavior, Section 6.1 provides
procedures on how to do it. 

Bhupesh

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 29 Jul 2013 19:31:20 +0000

Hi Bhupesh

Thanks for the quick reply.  Please see some discussion inline below - look for [JEH]...[/JEH].

Best regards
Jon

<snip>

[JEH] OK, I think you have defined what a VPLS site is from the perspective of one PE router, whereas I was thinking of it as a collection of CE devices.  Anyway, I understand your definition now so we'll leave it.  [/JEH]

> homed to a single PE router (which is clearly within the scope of

[JEH] For the record, apologies, my statement above is incorrect.  Reading it again, the definition of VPLS site does allow for multiple sites connecting to one PE. [/JEH]

<snip>

For example, two different customer locations single homed to
the same PE can still be grouped together as one VPLS site on the PE.
If you remove the PE (provider network), the two locations will not be
able to communicate. 

[JEH] OK, I had not appreciated that. [/JEH]

[JEH] Here is a proposal for your consideration.  This wording would have reduced my initial confusion.

   A VPLS site is a grouping of ports on a PE that belong to the same VPLS
   domain.  The terms "VPLS instance" and "VPLS domain" are used
   interchangeably in this document.

   If the CE devices that connect to a VPLS site's ports have connectivity
   to any other PE device then the VPLS site is called a multi-homed VPLS
   site.  Otherwise, it is called a single-homed VPLS site.  The terms
   "VPLS site" and "CE site" are used interchangeably in this document.

One final question on the definition.  Is it correct to say that no port on a PE router can be in >1 VPLS site?  If so I would add the following sentence to the definition above.

   The ports are partitioned between VPLS sites such that each port is in
   no more than one VPLS site.

[/JEH]

<snip>

Remote PEs must always send multicast traffic to PE1 unless PE1
advertises D bit in its VE NLRI.

[JEH] But I think this contradicts section 3.4 which says:

" If PE1 is the
   designated forwarder for CE1, based on the DF election result, PE3
   can chose to not send unknown unicast and multicast traffic to PE2 as
   PE2 is not the designated forwarder for any customer site and it has
   no other single homed sites connected to it."

So PE3 is using the DF election result, not the D bit, to decide not to send multicast traffic to PE2.  It seems that section 3.4 is not correct.

If PE2 loses all of its DF elections, should it set the D bit in its VE NLRI?  I think not, because it still has connectivity.

[/JEH]

<snip>

[JEH] If the F bit is used in the VE NLRI and not the CE NLRI then I think there is a problem.  Apologies if I am missing something obvious, I am relatively new to this, but please consider this scenario.

PE router PE1 is connected to two multihomed sites CE1 and CE2 and is DF for both of them.  It advertises VE NLRI with F bit 1.

Now, some other PE router connects to CE2 and is elected the DF for CE2.  PE1 is not the DF for CE2 any more so it advertises the VE NLRI with F bit 0, causing a flush of all MAC addresses on its peers.  But it is still the DF for CE1.

Finally, some other router connects to CE1 and is elected DF for CE1.  PE1 is not the DF for CE1 any more so it needs to send another flush for all MAC addresses.  But it has already advertised its VE NLRI with F bit 0 so how can it do this?

Note that I am not talking about a MAC-list flush here.  The requirement I see is for PE1 to be able to flush all MAC addresses _each time_ it loses a DF election.  This works fine if the F bit is associated with the CE NLRI.  How does it work if the F bit is associated with the VE NLRI?
[/JEH]
 
<snip>