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

From: Shane Amante <[email-masked]>
Date: Mon, 5 Apr 2010 19:58:01 -0600

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

---

From: "PAULING JOEL" <[email-masked]>
Date: Tue, 6 Apr 2010 10:40:03 +0800

Looks good. 

One comment: 

Re fallback protocol (proposed to be IPv4) should be a tuneable option. While the V6 compatibility flag currently signals v6 stack compatibility on the tunnel end point, I would prefer from a future proofing perspective if the fallback protocol was definable. 

Especially in MPLS PE-PE scenarios, it is preferable to run either IPV4 + MPLS OR IPV6 + MPLS, rather than both through a MS core network (reducing admin overhead by having to maintain two stacks). Having fallback protocol be a tuneable option will cater to this scenario better than current proposed draft.

Kind regards

Joel W Pauling

Network Capability Engineer
Alcatel-Lucent New Zealand
+64 4 803 7639
+64 21 171 8049
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Tuesday, 6 April 2010 1:58 p.m.
To: [email-masked]
Subject: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Everyone,

Thanks,

Giles & Shane

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 19 Apr 2010 12:43:36 -0700

Hi Joel -
Thanks for your comment.

While you make a good a point, here is what my thinking behind it.

IPLS was designed originally for IPv4 and existed for a long time before
support of IPv6 added. If there is any implementation out there, they
have IPv4 support for it and would like to see a newer implementation
be compatible with existing.

Secondly, it is always desirable that an RFC provide 'a base version' that is
at minimum be compatible and interoperable with other implementations.

Nonetheless, you make a good point and would like to hear from other
members of the WG that entertain a possibility of IPv6 only IPLS (a possibility, with
a fallback tunable option).

Regards,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PAULING JOEL
Sent: Monday, April 05, 2010 10:40 PM
To: [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Looks good. 

One comment: 

Kind regards

Joel W Pauling

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Tuesday, 6 April 2010 1:58 p.m.
To: [email-masked]
Subject: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Everyone,

Thanks,

Giles & Shane

---

From: "PAULING, JOEL (JOEL)" <[email-masked]>
Date: Tue, 20 Apr 2010 11:16:10 +0800

Thanks, 

I understand your position but I can see ipls being a significant component in a V6 centric infrastructure as an alternative way to deliver v4 sans DS-lite etc. Because of this very likely scenario and also the push to MPLS-TP in the core (san's any IP layer involvement) I think this may be important to remove a v4 fallback as a default. 

-JoelW

-----Original Message-----
From: Himanshu Shah [mailto:[email-masked]] 
Sent: Tuesday, 20 April 2010 7:44 a.m.
To: PAULING, JOEL (JOEL); [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Joel -
Thanks for your comment.

IPLS was designed originally for IPv4 and existed for a long time before support of IPv6 added. If there is any implementation out there, they have IPv4 support for it and would like to see a newer implementation be compatible with existing.

Secondly, it is always desirable that an RFC provide 'a base version' that is at minimum be compatible and interoperable with other implementations.

Nonetheless, you make a good point and would like to hear from other members of the WG that entertain a possibility of IPv6 only IPLS (a possibility, with a fallback tunable option).

Regards,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PAULING JOEL
Sent: Monday, April 05, 2010 10:40 PM
To: [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Looks good. 

One comment: 

Kind regards

Joel W Pauling

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Tuesday, 6 April 2010 1:58 p.m.
To: [email-masked]
Subject: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Everyone,

Thanks,

Giles & Shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 22 Apr 2010 21:25:03 +0530

Hello Authors and WG,

    Here are some of my review comments on this version of the I-D. 

In Section 6.1 When to Signal an IPv4 address of a CE
     ....
     Similarly, if the PE detects that an IP address of a CE is no
     longer valid (by methods described above), the PE must re-
     advertise the PW FEC with null IP address to denote the
     withdrawal of IP address of the CE. The receiving PE then waits
     for notification of the remote IP address. During this period,
     propagation of unicast IPv4 traffic is suspended, but multicast
     IPv4 traffic can continue to flow between the AC and the
     pseudowire.
     ....
     <Comment> 
     I think we need to expand a bit on "PE must re-advertise the 
     PW FEC with null IP address". Section 6.2 also specifies LDP
     Notification message to reflect any change in CE address without 
     re-mapping/re-advertising if label has been advertised already.
     Otherwise it's a bit ambiguous on whether to use label withdraw 
     on moving from 'non-zero' CE address to 'zero' CE address or     
     reflect the change with CE address change Notification Message.
    </Comment>

Section 7. 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.2 in draft-ietf-l2vpn-ipls-09 as well.
</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,

Thanks,

Giles & Shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 22 Apr 2010 21:28:48 +0530

Sorry this was for arp-mediation draft. So please read it for other one
and NOT for ipls draft. 

Shane : I have changed your subject line :-) in this thread.

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) 
Sent: Thursday, April 22, 2010 8:55 AM
To: 'Shane Amante'; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hello Authors and WG,

<Comment>

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

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,

Thanks,

Giles & Shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 22 Apr 2010 21:38:55 +0530

Hello Authors and WG,

Section 7.2 IPV6 Capability advertisement.
   ....

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

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,

Thanks,

Giles & Shane

---

From: Shane Amante <[email-masked]>
Date: Sun, 25 Apr 2010 15:11:51 -0600

Thank you Joel, Lizhong and Pranjal for your reviews and comments.

The WG Last Call on IPLS is now closed.  

Would the authors please address the outstanding comments & questions, to the satisfaction of the reviewers, so that we can move forward with this document?

Giles & Shane

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 26 Apr 2010 19:10:25 -0700

Hi Pranjal,
Thanks for your comments.

Response in line..

Regards,
himanshu

On 4/22/10 12:08 PM, "Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote:

Hello Authors and WG,

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

</Comment>

[himanshu] I understand your scenario. It seems that if label TLV is used for
withdraw/release, label itself could be used to co-ordinate the release msg.
Anyway, the method you note as describe in 6.2 of 4447 can be used to avoid
the race condition. I would like Mathew Bocci to comment on this too. Could
you send him an internal mail to draw his attention.

<Comment>

</Comment>

[himanshu] This is a similar comment as LiZhong from ZTE. Hope you have followed that discussions.
In a nutshell, PE must augment MAC address to PW-FEC and treat it as a unique entity and apply
label operations (mapping/withdraw/FIB programming, etc) accordingly. Same comment applies to FEC129,
because note that multiple CEs can exist on a single AC.

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,

Thanks,

Giles & Shane

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 26 Apr 2010 19:20:50 -0700

OK. I suppose if you believe a lack of fallback configuration switch could be impediment
for a rollout, we should add it in.

Thanks,
himanshu

On 4/19/10 11:16 PM, "PAULING, JOEL (JOEL)" <[email-masked]> wrote:

Thanks,

-JoelW

-----Original Message-----
From: Himanshu Shah [mailto:[email-masked]]
Sent: Tuesday, 20 April 2010 7:44 a.m.
To: PAULING, JOEL (JOEL); [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Joel -
Thanks for your comment.

Regards,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PAULING JOEL
Sent: Monday, April 05, 2010 10:40 PM
To: [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Looks good.

One comment:

Kind regards

Joel W Pauling

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Tuesday, 6 April 2010 1:58 p.m.
To: [email-masked]
Subject: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Everyone,

Thanks,

Giles & Shane

---

From: Himanshu Shah <[email-masked]>
Date: Tue, 27 Apr 2010 11:17:28 -0700

Hi Pranjal - 
Thanks for the review and the comments.
Comments in line..

/himanshu

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) 
Sent: Thursday, April 22, 2010 8:55 AM
To: 'Shane Amante'; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hello Authors and WG,

[Himanshu>]  Section 5 discusses the how CE discovery and PW 
establishment procedures are decoupled. They need to be, 
especially for multicast traffic to flow, which in turn aids in CE
discovery. Hence the 'label withdraw' and 'address withdraw' are
kept separate. The label withdraw would apply only when the 
service is no longer configured or unfavorable to both parties.
The 'address withdraw' cases are described the draft.

<Comment>

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

[Himanshu>]  Cut & Paste below from the response on ipls comment (for those who may not have read IPLS mails)

[himanshu] "I understand your scenario. It seems that if label TLV is used for
withdraw/release, label itself could be used to co-ordinate the release msg.
Anyway, the method you note as describe in 6.2 of 4447 can be used to avoid
the race condition. I would like Mathew Bocci to comment on this too. Could
you send him an internal mail to draw his attention."

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,

Thanks,

Giles & Shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 28 Apr 2010 08:18:21 +0530

Hi Himanshu,
                           Please refer my responses inline in blue.

Thanks,
Pranjal
________________________________
From: Himanshu Shah [mailto:[email-masked]]
Sent: Monday, April 26, 2010 7:10 PM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Pranjal,

Response in line..

Regards,
himanshu

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

</Comment>

[Pranjal] No really. We can't use label TLV as reliable method for withdraw/
releases. If we refer to section 3.5.10 and 3.5.11 in RFC 5036, label TLV is
OPTIONAL in LDP label withdraw/release messages. Sure, I would bring this
into Mathew's attention.

<Comment>

</Comment>

[Pranjal] Yes, I am following your exchanges with Lizhong. But still I was not
          able to make it work from an implementation perspective. If we would
          want to augment the PW-FEC "as is" with MAC address and apply label
          operations then we need to define a new FEC type (e.g FEC128/129 + MAC).
          Here, IPLS VPN-ID is NOT the FEC, but the unidirectional PW used in IPLS
          is. Having a new FEC type makes existing PW/L2VPN much cleaner. Existing
          implementations would consider one label from a peer against a PW (which
          is a FEC as per RFC 4447).

          In IPLS, the intent is to have the ability to associate VPN membership
          (thru common FEC 128/FEC129) but also have unidirectional PWs per CE MAC
          address. As an example, we do the same with FEC129 based LDP VPLS with BGP
          Autodiscovery. The AGI (which is part of FEC129 but doesn't define a
          specific PW) matches the VPLS ID  (VPN membership) even though FEC(AGI +
          SAII + TAII) s of each PWs are different. In similar note IPLS is a service
          that needs to build undirectional PW (FEC) infrastructure using a common
          denominator as VPN-ID.

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,

Thanks,

Giles & Shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 28 Apr 2010 08:33:55 +0530

Hi Himanshu,

            Thanks for the clarification. Please refer inline

In blue.

Thanks,

Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Himanshu Shah
Sent: Tuesday, April 27, 2010 11:17 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-arp-mediation-13

Hi Pranjal -

Comments in line..

/himanshu

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

and NOT for ipls draft.

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

Hello Authors and WG,

     ....

     pseudowire.

     ....

     <Comment>

    </Comment>

[Pranjal] Yes, that's correctly explained in section 6.2. I was looking

          from an implementation angle and section 5 leaves some ambiguity.
          This was a minor editorial comment.

   ....

   ....

<Comment>

Capability negotiation.

A and B.

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

   IPV4 + IPV6.

   unsolicited release.

</Comment>

[Pranjal] Please refer to response in IPLS thread.

Thanks,

Pranjal

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

To: [email-masked]

Hi Everyone,

- Andy Malis

- Nick DelRegno

- Pranjal Dutta

Thanks,

Giles & Shane

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Fri, 30 Apr 2010 13:23:22 +0200

Himanshu, Pranjal,

I think it makes sense to use the same procedures that are described in Sec 6.2 of RFC4447. We would need to get a new LDP status code point for this.
I'll send some draft text for comment to the list in the next few days.

Thanks

Matthew

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dutta, Pranjal K (Pranjal)
Sent: 28 April 2010 03:48
To: Himanshu Shah; Shane Amante; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Himanshu,

Thanks,
Pranjal

Hi Pranjal,

Response in line..

Regards,
himanshu

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

</Comment>

<Comment>

</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,

Thanks,

Giles & Shane