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:yljiang at huawei.com]
Sent: Tuesday, May 26, 2009 6:55 PM
To: Dutta, Pranjal K (Pranjal)
Cc: l2vpn at ietf.org
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: l2vpn at ietf.org

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: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf Of Jiang Yuan-long
Sent: Wednesday, May 13, 2009 4:36 AM
To: Dutta, Pranjal K (Pranjal)
Cc: l2vpn at ietf.org
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