Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 04 Jun 2009 17:52:03 +0800

Hi, Pranjal,

IMHO, I think this sentence is unnecessary as it is not explicit in RFC 4762. 
Furthermore, as you pointed out, for the first case, PE3-rs can generate 
the message. Even in the second case, MTU-s sending flush message may not be 
the best method.

As I know, some disadvantages in this mechanism:
1) PE3-rs must pre-bind the LDP sessions associated with spoke PW and hub 
   PWs together, so that it knows how to forward these messages in the 
   control plane;
2) PE3-rs must forward the withdraw message by PE-rs, which may loop arround 
   other PEs in the VPLS as noted in draft-pkwok-l2vpn-vpls-macflush-ld-00.

IMO, though PE3-rs may not know it is hosting a backup path, it should be
aware of the fact that the spoke PW becomes active, so activity of the spoke 
PW can be used as a trigger for PE3-rs to send out the flush message. So in 
both cases, PE3-rs can be the sole source of the message, thus the above two 
disadvantages are avoided.
Any comments?

  Thanks

Yuanlong Jiang

  ----- Original Message ----- 
  From: Dutta, Pranjal K (Pranjal) 
  To: Jiang Yuan-long 
  Cc: [email-masked] 
  Sent: Saturday, May 30, 2009 7:36 AM
  Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

  Hi,

           Both the interpretations are correct and desired flushing affect is same. PE3-rs can generate 

  mac flush if it is H-VPLS aware (means it knows that it is hosting a backup path) in case of which 

  It is not necessary for MTU to trigger mac flush. That is possible if PW standby/active status signaling

  In implemented between MTU and PE3-rs. If PE3-rs is H-VPLS agnostic then the control is in MTU alone

  and so MTU needs to trigger mac flush towards PE3-rs.

  Thanks,

  Pranjal

------------------------------------------------------------------------------

  From: Jiang Yuan-long [mailto:[email-masked]] 
  Sent: Tuesday, May 26, 2009 6:55 PM
  To: Dutta, Pranjal K (Pranjal)
  Cc: [email-masked]
  Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

  Pranjal,

  Thank you for the explanation on the PE-ID, it helps me to understand what is 

  beyond the texts, I sincerely appreciate it:)

  Another question, section 5.2, at the bottom of page 12, it says:

     By default, MTU-2 should still trigger MAC flush as currently  
     defined in [RFC4762] after the backup PW is made active by RSTP.  

  The same text is also found in draft-ietf-pwe3-redundancy-bit.

  But in RFC 4762, it is not the MTU-s but the PE that should send out the flush msg.

  As the only description on this mechanism is at the bottom of page 22:

                                                    [...]. To enable faster
     convergence, the PE3-rs where the secondary PW got activated may send
     out a flush message (as explained in Section 6.2), [...]

  I wonder is there anything I missed?

   Best regards

  Yuanlong Jiang

    ----- Original Message ----- 

    From: Dutta, Pranjal K (Pranjal) 

    To: Jiang Yuan-long ; Dutta, Pranjal K (Pranjal) 

    Cc: [email-masked] 

    Sent: Tuesday, May 26, 2009 1:51 PM

    Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

    Hi,

           Please refer to my answer inline to your comments.

    Thanks,

    Pranjal

----------------------------------------------------------------------------

    From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
    Sent: Wednesday, May 13, 2009 4:36 AM
    To: Dutta, Pranjal K (Pranjal)
    Cc: [email-masked]
    Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

    Hi Dutta,

    I have a few comments on this draft:

    1. From the description in the draft, it seems only one PE-ID is needed 

    for your mechanism. But in the definition of PE-ID TLV in section 4, 

    a list of one or more PE-ID may be included, but do we really need more 

    than one PE-ID element? Can you give some clues on its usage?
    IMO, this definition is also in contradiction to the prior sentence 

    "The PE-ID TLV carries the unique identifier of a generic PW endpoint".  

    [Pranjal]

          Yes, that's correct. PE-ID TLV can accommodate a LIST of PE-ID Elements. Today implementations 

           can send a list of FEC Elements within a FEC TLV sent in the MAC flush message. A common network

           event may trigger failure of primary PWs for a set of VPLS instances together, which requires to send mac flush 

           for all those instances. Sending an individual LDP MAC flush message per VPLS instance is sub-optimal and

           so MAC flush for a set of VPLS instances are bundled in a  single message. Same applies to optimized

           MAC flush with PE-ID as well.

    2. The length of the FEC-128 specific PE-ID element is given as 2 octets, 

    should the correct length be 8?

    [Pranjal]

          That's right. It's a typo. It should have been 8 octets. We will correct it in the next revision.

    3. Maybe the FEC-129 specific PE-ID Element needs another extra field 

    for PE address, as AII TLVs can only be null according to RFC 4762 in 

    section 6.1.1, while AGI TLV can only give you information on VPLS 

    instance. 

    [Pranjal]

         RFC 4762 also specifies that use of non-null SAII and TAII would be addressed in future revision.

         Today, FEC 129 is used in VPLS provisioned with BGP-AD where SAII/TAII always carry valid 

         end-point identifiers (VS-ID) as per l2vpn signaling draft below.

         http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt

         RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non BGP-AD deployments to replace FEC 128. 

         But if you see AGI definition in RFC 4446 (that carries vpls-id as per RFC 4762), only one type is allocated to be used 

         in BGP-AD provisioned VPLS from  L2 VPN signaling draft. 

    4. I think this mechanism only works properly in a scenario where the 

    MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends 

    out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing 

    msg with PE-ID, then other PEs in the VPLS will process both msgs and 

    the result is flushing all MACs. So maybe this should be pointed out in 

    the applicability section.

[Pranjal]  Following is stated in the section  5. Application of PE-ID TLV in Optimized MAC Flush  

   However the inclusion of the FEC-TLV should be     based on what would be the desired effect should the PE-ID not be     understood by the receiver.  In cases where the desired action when     the PE-ID is not understood would be to behave as described in     [RFC4762], then the FEC TLV SHOULD be included.  In cases where the     desired action when the PE-ID is not understood is to take no     action, then the FEC TLV SHOULD NOT be included.  Are you suggesting for more explanation in that section? 

    5. Some random corrections:
    s/ignored/ignored by/

    page 6, "...So the MAC addresses that require flushing and relearning at 

    PE-2 are only the MAC addresses those have been learned on the PW 

    connected to PE-1." is redundant, maybe it is better to say "...So the MAC 

    addresses that require flushing and relearning at PE-2 are only those 

    MAC addresses learned on the PW connected to PE-1.".

    [Pranjal] Sure, we would address this in the next revision.

    Thanks

    Yuanlong Jiang