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

[Bhupesh Kothari <[e-mail]>]

Hi Jon,

Thanks for the detail review.  My comments are inline.

Bhupesh


Jonathan Hardwick <[e-mail]> 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.


> 
>  
> 
> 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.

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.


> 
>  
> 
> 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/

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