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

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 13 May 2009 19:35:50 +0800

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

2. The length of the FEC-128 specific PE-ID element is given as 2 octets, 
should the correct length be 8?

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. 

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.

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

Thanks

Yuanlong Jiang

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 26 May 2009 11:21:15 +0530

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,

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

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

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

[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?

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

Thanks

Yuanlong Jiang

---

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 27 May 2009 09:54:43 +0800

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,

  Thanks,

  Pranjal

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

  Hi Dutta,

  [Pranjal]

   

  [Pranjal]

   

  instance. 

  [Pranjal]

[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? 

  Thanks

  Yuanlong Jiang

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sat, 30 May 2009 05:06:09 +0530

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,

 Best regards

Yuanlong Jiang

----- Original Message -----
From: Dutta, Pranjal K (Pranjal)<mailto:[email-masked]>
To: Jiang Yuan-long<mailto:[email-masked]> ; Dutta, Pranjal K (Pranjal)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Tuesday, May 26, 2009 1:51 PM
Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

Hi,

Thanks,
Pranjal

________________________________
From: [email-masked]<mailto:[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]<mailto:[email-masked]>
Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

Hi Dutta,

[Pranjal]

[Pranjal]

[Pranjal]

Thanks

Yuanlong Jiang