Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

From: [email-masked]
Date: Fri, 23 Apr 2010 09:23:45 +0800

Hi,
I also agree with Pranjal's two comments. We should solve the two 
problems: capability negotiation and PW setup.

BR
Lizhong

------------------------------------------------------------
Date: Thu, 22 Apr 2010 21:38:55 +0530
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09
To: Shane Amante <[email-masked]>, "[email-masked]"
                 <[email-masked]>
Message-ID:
 
<[email-masked]>
 
Content-Type: text/plain; charset="us-ascii"

Hello Authors and WG,

    Here are some of my review comments on this version of the I-D.
 
Section 7.2 IPV6 Capability advertisement.
   ....
   A PE that supports IPv6 on an IP PW MUST signal the stack capability
   sub-TLV in the initial label mapping message for the PW. The PE
   nodes compare the value advertised by the remote PE with the local
   configuration and only use a capability which is advertised by both.
   If a PE that supports IPv6 does not receive a 'stack capability'
   sub-TLV from the far-end PE in the initial label mapping message, or
   one is received but it is set to a reserved value, the PE MUST send
   an unsolicited release for the PW label with the LDP status code
   meaning ''IP Address type mismatch'' (Status Code 0x0000004A).
   ....
<Comment>

There is a need to consider the following case on IPV6 Capability 
negotiation.

Let's take some sequence of events in IP L2 PW setup between A and B.

     A---------------------B

A is configured with IPV4 only initially.
B supports both IPV6 + IPv4.

1. A sends initial label mapping L1 for IPV4 PW setup to B.
   L1 is waiting in B to get processed.
2. Now we configured ipv6 capability in A. So A needs 
   to do re-mapping. A sends label withdraw W1 first and 
   then awaits for label release from B to re-advertise
   with IPV4 + IPV6 capability. So label withdraw W1 is 
   in queue after the initial label Map L1 at B.
3. Now B processes the initial label map L1 from A. It 
   responds with unsolicited "release" R1 to A with status 
   code S1 = "IP Address Type Mismatch" since B supports 
   IPV4 + IPV6.
4. Now A processes R1 and thinks it's the Release to withdraw 
   W1 that A is waiting for. So it advertises L2 to B - the 
   new Label mapping with IPV4 + IPV6.
5. B processes W1 now and responds back with regular Release R2.
6. A thinks that its label map L2 is being released by R2 - 
   unsolicited release. 
7. B processes L2 and is happy with it.

At the end of this re-negotiation, the PW would never be operationally up 
at 
A but would be fine at B. Both ends are out of sync due to race 
conditions.

So we can't overlap releases R1 and R2 from B. The solution is for A to 
send 
withdraw W1 with a new status code S2 = "Wrong IP Address Type" (e.g) when 

it changes from IPV4 to IPV6 (but not vice versa). When B processes label
withdraw with status Code S2, no release should be sent as response and B 
should continue to wait for next control message from A.

We do similar procedures with cBit re-negotiation. Please refer to section 

6.2 in RFC 4447 on usage of "Wrong C-bit".

Note that the same applies to Section 7 in 
draft-ietf-l2vpn-arp-mediation-13
as well.

</Comment>

Section 7.3 Signaling Advertisement Processing

A PE should process a received [PWE3-CONTROL] advertisement with PW- type 
of IP Layer2 transport for IPLS as follows,

        - Verify the IPLS VPN membership by matching the VPN-Id
          signaled in the AGI field or the PW-ID field with all the
          VPN-Ids configured in the PE. Discard and release the PW
          label if VPN-Id is not found.
        - Program the Forwarding Information Base (FIB) such that when
          a unicast IP packet is received from an AC with its
          destination MAC address matching the advertised MAC address,
          the packet is forwarded out over the tunnel to the
          advertising PE with the advertised PW-label as the inner
          label.
 
<Comment>

In section 6.1 we have described that there would be one PW (either P2MP 
or
MP2MP) associated exclusively with one CE in an IPLS site. Let's say that 
we
are signaling P2P PW per CE with FEC128 to receive unicast traffic and 
there
are multiple local CEs in a site. [PWE-CONTROL] method would match IPLS 
membership with FEC128 Pwid. If we need to advertise multiple CEs from 
same site over same LDP signaling session, each with different labels then 
PWid
(VPN-ID) is not unique differentiator at receiver. It needs to be 
explained
in detail on how the PW setup would take place per CE using FEC128. For 
FEC129 different AC-ID can be used for each CE but with common AGI (= 
VPN-ID) to associate them to same IPLS instance at receivers.

</Comment>
 
Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Shane Amante
Sent: Monday, April 05, 2010 6:58 PM
To: [email-masked]
Subject: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Everyone,

This is to begin a (final) WG Last Call on:
http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-09

If you have substantial technical comments or concerns, please share them 
with the list.  If you have editorial comments, please share them directly 
with the authors and co-chairs.

So far, we have the following folks signed up for a thorough review and 
comments:
- Andy Malis
- Nick DelRegno
- Pranjal Dutta
However, we could use more people to conduct a review.  If you have the 
time and/or inclination, please let the chairs know if you'll be 
conducting a review.

The Last Call on this draft will also end on April 23.

Thanks,

Giles & Shane

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

_______________________________________________
L2vpn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 71, Issue 11
*************************************

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.