Subject: [PWE3] Optimized MAC Address Operations in VPLS with Redundancy

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 26 Jun 2008 10:34:52 +0800

Hi, all:

In VPLS with redundancy scenarios such as defined in draft-ietf-pwe3-redundancy-00.txt 
or in draft-pdutta-l2vpn-vpls-ldp-mac-opt-03.txt, MAC address withdrawal mechanism 
is introduced in RFC 4762 for faster convergence. 

In progress work of draft-pdutta-l2vpn-vpls-ldp-mac-opt-03.txt enhances the mechanism 
by flushing only the affected MAC addresses. This method may greatly restrict the scope
of MAC flushing under some circumstances. That's really a good job.

But in VPLS with redundancy, as the relation of the working PW and the protection PW is
determined in advance, flushing is not the best choice. So this draft provides two 
mechanisms: MAC address switching and MAC address notification. With these two 
mechanisms  MAC address flushing can be removed completely.

->
A New Internet-Draft is available from the on-line Internet-Drafts 
directories. 

        Title : Optimized MAC Address Operations in VPLS with Redundancy 
        Author(s) : Y. Jiang, Y. Yang 
        Filename : draft-jiang-l2vpn-vpls-mac-operation-00.txt 
        Pages : 16 
        Date : 2008-6-24 
        
   The Virtual Private LAN Service (VPLS) Using Label Distribution     
   Protocol (LDP) Signaling is described in RFC 4762. That document   
   describes a mechanism called MAC Address Withdrawal to remove or     
   unlearn MAC addresses which have been dynamically learned in a VPLS   
   instance. Further work in progress defines an extension to MAC 
   Address Withdrawal procedure which can greatly restrict the scope of 
   MAC flushing. This document provides two mechanisms which completely 
   remove the need for MAC address flushing in VPLS instances. The 
   mechanisms are MAC address switching and MAC address notification.     

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-vpls-mac-operation-00.txt

Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/ 
->

Please comment on the idea.

Regards,

Y.L. Jiang
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Shane Amante <[email-masked]>
Date: Sun, 29 Jun 2008 10:56:27 -0600

Hi Jiang,

I have a few questions about this draft.

First, "MAC Address Switching" (first explained in Section 3.1).   
Please see the following diagram where I've added CE-5 as a single- 
homed device behind PE-1:

                             PE-1                       PE-3
                           +--------+                +--------+
               CE-5--------|        |                |        |
                           |   --   |           PW1  |   --   | CE-3
                           |  /  \  |----------------|  /  \  |--->
CE-1               /------|  \ s/  |           PW2  |  \S /  |
   \     primary spoke PW  |   --   |         /------|   --   |
    \             /        +--------+        /       +--------+
     \    (MTU-s)/              |    \      /             |
      +--------+/               |     \    /              |
      |        |                |      \  /               |
      |   --   |                |       \/                |
      |  /  \  |             PW5|   H-VPLS Full Mesh Core |
      |  \S /  |                |      /  \               |
      |   --   |                |     /    \              |
     /+--------+\               |    /      \             |
    /     backup spoke PW       |   /        \   PW3      |
   /              \        +--------+         \------+--------+
  CE-2             \       |        |                |        |
                    \------|  --    |            PW4 |  --    | CE-4
                           | /  \   |----------------| /  \   |--->
                           | \s /   |                | \S /   |
                           |  --    |                |  --    |
                           +--------+                +--------+
                             PE-2                       PE-4

Section 3.1 states the following:
---snip---
    ... PE-1 or PE-2 sends out a ''MAC Address Switching'' message to  
PE-3,
    and accordingly PE-3 changes its MAC table items with PW1 as the  
outgoing
    PW, to show PW2 as the outgoing PW. In this way, remote VPLS peer
    node PE-3 needs no MAC flushing and re- learning, and faster  
convergence
    is realized.
---snip---

In no particular order, here are some questions & comments:
1)  First, just to be more clear, I think you likely need to point out  
that, because CE-5 is single-homed into PE-1, that the "MAC Address  
Switching" message (sent to the other PE's) must only contain MAC  
Addresses learned from the "primary spoke PW" going from PE-1 to the  
MTU-s, (not from other AC's attached to PE-1).
2)  Second, shouldn't PE-1 & PE-2 send a "MAC Address Switching"  
message to all other PE's in the H-VPLS instance?  In this case, PE-1  
& PE-2 should be required to send a "MAC Address Switching" message to  
PE-2, PE-3 & PE-4.  This way, PE-3 will switch from PW1 to PW2.  In  
addition, PE-4 will switch from PW3 to PW4.  Finally, PE-2 must also  
switch from PW5 to the "backup spoke PW" in order to reach the MTU-s.   
(Alternatively, PE-1 should at least tell PE-2 to no longer forward  
MAC addresses for the MTU-s down PW5).
3)  I'm not sure how PE-1 would signal to PE-2 the 'PW-ID' of the  
"backup spoke PW", from PE-2 to the MTU-s, in the MAC Address  
Switching Message you have in Section 5.2.  Perhaps I haven't studied  
draft-ietf-pw-redundancy enough, but from where does PE-1 learn/know  
the PW-ID of the "backup spoke PW" from PE-2 down to the MTU-s, in the  
first place?

Second, "MAC Address Notification" (first explained in Section 3.2).

Section 3.2 of this draft states the following:
---snip---
    To facilitate MAC table maintenance on PE-2, the MAC Address  
Notification messages
    should include the outgoing PWs to be associated with the notified  
MAC addresses.
    Multiple PWs and their associated MAC addresses may be carried in  
a single message
    or in separate messages.
---snip---

I'm not sure how you're intending to "include the outgoing PW's to be  
associated with the notified MAC addresses".  Specifically, in my  
understanding of a FEC 129 PW-ID element, both the SAII and TAII are  
null, according to RFC 4762, Section 7.1.1:
---snip---
    Target Attachment Individual Identifier (TAII), Source Attachment  
Individual
    Identifier (SAII): These are null because the mesh of PWs in a  
VPLS terminates
    on MAC learning tables, rather than on individual attachment  
circuits. The use
    of non-null TAII and SAII is reserved for future enhancements.
---snip---
Instead, you only have an AGI in FEC 129, which I don't believe is  
enough to indicate the specific PW over which the MAC addresses were  
learned from remote PE's.  But, perhaps I'm incorrect?

Thanks,

-shane

---

From: jiangyuanlong 59929 <[email-masked]>
Date: Mon, 30 Jun 2008 14:18:02 +0800

Shane: 
Thanks for your comments, please see my replies corresponding to the questions.

Best regards,
Jiang

----- Original Message -----
From: Shane Amante <[email-masked]>
Date: Monday, June 30, 2008 0:56 am
Subject: Re: [PWE3] Optimized MAC Address Operations in VPLS with Redundancy

> homed device behind PE-1:

Yes, you are right for this kind of mixed scenario, and that is the reason for the inclusion of MAC list.
I will clearly point it out in the next version.

> MAC addresses for the MTU-s down PW5).

Yes, you are right. I take PW1 as an example, but the same mechanism applies to the other working PWs effected by the topology change such as PW3. Perhaps I should add some more paraphrases in this section.
But for PW5, I think PE-1 & PE-2 should deal with it locally and no signaling of switching is needed. As for PE-1, PW5 is protecting the "primary spoke PW", and for PE-2, PW5 is protected by the "backup spoke PW". Therefore, PE-1 should switch from the "primary spoke PW" to PW5, while PE-2 should switch from PW5 to the "backup spoke PW". 

> the PW-ID of the "backup spoke PW" from PE-2 down to the MTU-s, in 

Please reference my comments in 2), there is no needs for PE-1 to signal to PE-2 the "PW-ID" of the "backup spoke PW".

> learned from remote PE's.  But, perhaps I'm incorrect?

This seems a problem, maybe we can send the IP address or the LSR-ID of the PW endpoint instead. Any other sugestions?
BTW, I'm not sure about the backgrouds of the decision on nulling the SAII and TAII fields,
but it seems to me this decision makes it a little difficult to implement end to end PW protection and muti-segment PW.

> > In VPLS with redundancy scenarios such as defined in draft-ietf-
> pwe3- 
> > redundancy-00.txt
> > by flushing only the affected MAC addresses. This method may 
> greatly  
> > restrict the scope
> > But in VPLS with redundancy, as the relation of the working PW 
> and  
> > the protection PW is
> > mechanisms: MAC address switching and MAC address notification. 
> With  
> > these two
> >    Address Withdrawal procedure which can greatly restrict the 
> scope  
> > of
> >    mechanisms are MAC address switching and MAC address 
> notification.>