RE: draft-kompella-l2vpn-vpls-multihoming-01

["BALUS Florin" <[e-mail]>]

Hi Bhupesh,

I think there is no way to guarantee that make before break for PWs with
MAC learning + MAC Flushing on top is hitless - i.e. synchronization of
different processes at the 2 PEs (label installation + switching between
old and new PWs, MAC Flush, MAC learning) depends on network condition,
PE load, traffic profile. 

So I think there is a good chance that the scope of failure does extend
to non-affected CEs even with the make before break scheme. 
There might be a need to look for an alternative to tearing down the
VPLS infrastructure every time something happens with one site. 

But of course we should hear from people running networks on this one
before spending additional cycles...

Thanks for the detailed answers.
Florin

> -----Original Message-----
> From: Bhupesh Kothari [mailto:[e-mail]]
> Sent: Wednesday, August 06, 2008 2:54 PM
> To: BALUS Florin
> Cc: [e-mail]
> Subject: Re: draft-kompella-l2vpn-vpls-multihoming-01
> 
> Hi Florin,
> 
> BALUS Florin <[e-mail]> wrote:
> >
> > Hi Bhupesh,
> > Thanks for the answers.
> >
> > From what you explain below the failure of the CE1-PE1 access link
> > affects the PW infrastructure and implicitly the communication
> between
> > all the other CEs connected to the same VPLS on PE1. I do not think
> this
> > is a good approach as it extends the scope of the failure.
> 
> The scope of the failure is not extended to other CEs.  See below for
> more details.
> 
> 
> >
> > More in-line for technicalities...
> >
> > > -----Original Message-----
> > > From: Bhupesh Kothari [mailto:[e-mail]]
> > > Sent: Monday, August 04, 2008 5:30 PM
> > > To: BALUS Florin
> > > Cc: [e-mail]
> > > Subject: Re: draft-kompella-l2vpn-vpls-multihoming-01
> > >
> > > Hi Florin,
> > >
> > > > > >
> > > > > > -          I think the case of a single homed CE mixed with
> the
> > > dual-
> > > > > homed ones seems even more problematic: i.e. the
> > > > > > single-homed CE could be left hanging, isolated from the
> other
> > > VPLS
> > > > > sites.
> > > > > >
> > > > >
> > > > > A single homed customer site is expected to be assigned a
> > different
> > > VE
> > > > > ID than a multi-homed site on the same PE.
> > > > >
> > > >
> > > > [[FB]] Then it means that for each "active/preferred" PE and for
> > > > each VPLS instance there will be at least two set of PWs: one
for
> > > > the VE ID assigned for the Single-Homed sites, another one for
> the
> > > > dual-homed CE1, even if they are part of the same customer VPLS
> > > > service.  Otherwise the failure of CE1-PE1 link will bring down
> all
> > > > the PWs to that VPLS switching instance on PE1, isolating all
the
> > > > single-homed CEs.
> > >
> > >
> > > No, there is only one PW between a pair of PEs and so only one PW
> is
> > > created even though two customer sites are connected to PE1.  When
> the
> > > CE1-PE1 link goes down and if the PW goes down (depends on the VE
> ID),
> > > then another PW will be reestablished, for the single homed site
as
> it
> > > has a unique VE ID in the VPLS instance, and hence, the site will
> > > never be isolated from the VPLS domain.
> >
> > [[FB]] From what you are saying here it looks like the dual-homed
CE1
> > and the single-homed CEs on PE1 share initially the same PW. Then if
> > CE1-PE1 link fails the initial PW will be torn down and a new PW
will
> be
> > re-established towards PE2 in order to reach CE1.
> 
> Correct.
> 
> 
> > Also another PW to the site corresponding to the single-homed CEs on
> > PE1 will be reestablished/activated.
> >
> > This results in a service interruption for single-homed sites due to
> > failure of CE1-PE1 access link. I think this is not acceptable as it
> > increases the scope of the failure unnecessarily.
> 
> 
> Your understanding is correct about the PW activation, but this does
> not necessarily mean traffic disruption for single-homed site.  See
> below for details.
> 
> 
> >
> > >The remote peers already know
> > > the label to use to reach that single homed site.
> > >
> > [[FB]] From what you are saying the service labels/PWs assigned for
> the
> > dual-homed site/VE ID are used for all the other sites/VE IDs in the
> > VPLS on PE1?
> 
> Yes.
> 
> > In other words the remote PE peers do not instantiate in the data
> > path the service labels for the single-homed site/VE ID from PE1?
> >
> 
> Yes.
> 
> 
> > What if there are multiple dual-homed sites on the same PEs, in the
> same
> > VPLS? Which VE ID's PW is chosen and based on what? (I am talking
> about
> > the case of different sites/VE IDs in the same VPLS)
> 
> Irrespective of whether multiple sites are all multi-homed or only
> some are multi-homed and others single-homed, ONLY one site is
> "selected" for PW establishment that will carry traffic.  The site
> with the lowest site ID is selected for this purpose.  So, if the
> multi-homed site ID is 1 and single-homed site ID is 2, just for the
> PW establishment, ID 1 is picked by all remote PEs.
> 
> Its an implementation detail, but here is a general explanation of why
> there shouldn't be any traffic loss.  For clarity, consider:
> 
> 
>               CE4 -------    ...............
>                          \  .               .    ___ CE2
>                       ___ PE1                .  /
>                      /    :                  PE3
>                   __/    :       Service      :
>               CE1 __     :       Provider    PE4
>                     \     :                   : \___ CE3
>                      \___ PE2                .
>                             .               .
>                              ...............
> 
> 
> PE1 has two sites, one multi-homed and other single-homed.  Site IDs
> are 1 (for CE1) and 4 (for CE4).
> 
> On PE2, there is just one site, with ID 1 for CE1 (multi-homed).
> 
> On PE3, there is just one site, with ID 2 for CE2
> 
> For simplicity, lets just consider one remote PE, PE3, for
> explanation.  Also assume that PE1 has higher preference than PE2.
> 
> PE3 will establish just one PW to PE1.  For this PW, PE1 programs its
> FIB with labels it advertises for site ID 1.  For this PW, PE3 selects
> site ID 1 from the list of sites on PE1, and so the labels advertised
> by PE1 for site ID 1 are used.  In other words, there is one PW
> between PE1 and PE3, and just for the PW establishment, site 1 and 2
> are picked on PE1 and PE3 ends.  PE3 will send traffic for both CE1
> and CE4 over this PW.
> 
> Note that PE3 also has NLRIs for site ID 4 from PE1.  PE3 simply keeps
> those in its control plane state and only programs its FIB with labels
> for site ID 1.
> 
> When a failure occurs, all PEs should do "make-before-break" as the
> labels are already known.
> 
> If CE1-PE1 link goes, PE1 has to advertise the NLRI for site 1 with D
> bit set.  Before it advertises this, it programs its FIB with labels
> it advertises for site ID 4 (for CE4).  It also does NOT tear down
> it's end of the old PW (which used site 1 labels).  When PE3 learns
> about the D bit for site 1, it knows that there is additional site,
> site 4, on PE1, and so it should not simply tear down the old PW.  It
> should program the labels that it received from site 4, then it should
> switch traffic to the new PW and only then it should tear down it's
> end of the old PW.  The question of when PE1 tears down it's end of
> the old PW is again an implementationd detail, but it could be dumb
> timer based or better heuristic based.
> 
> Also note that the path selection that PE3 does on receiving the D bit
> for site 1 from PE1 is independent of what is explained above.  The
> path selection will elect PE2 as the forwarder for site 1 and so a new
> PW to PE2 will be set up.
> 
> 
> > Thanks,
> > Florin
> 
> Hope it helps.
> 
> Thanks,
> Bhupesh