Subject: Re: L2vpn Digest, Vol 72, Issue 3

From: [email-masked]
Date: Tue, 4 May 2010 20:59:29 +0800

Yes, support.

Lizhong

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

Message: 2
Date: Mon, 3 May 2010 21:49:02 -0600
From: Shane Amante <[email-masked]>
Subject: Merge MAC Withdraw Drafts?
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hi Everyone,

At the last IETF meeting in Anaheim, there was good consensus in the room 
to merge the following two drafts in order to have a single specification 
that covered all LDP-based MAC Withdraw procedures in a single place. Here 
are the two drafts:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-01
http://tools.ietf.org/html/draft-balus-l2vpn-pbb-ldp-ext-02

We would like to reaffirm consensus on the mailing list that it is 
acceptable to merge draft-balus-l2vpn-pbb-ldp-ext-02 into the existing WG 
draft: draft-ietf-l2vpn-vpls-ldp-mac-opt-01.  Please indicate whether or 
not you support merging the two drafts. 

We will close this call in 2 weeks on Friday, May 14, at COB.

Giles & Shane

P.S. -- Here is a snippet of the notes related to this draft that I sent 
out to the WG mailing list back on 4/4/2010:
http://www.ietf.org/mail-archive/web/l2vpn/current/msg02280.html
---snip---
4)  Extensions to LDP MAC Withdraw for PBB-VPLS:
   - draft-balus-l2vpn-pbb-ldp-ext-02
     + Addressed previous comments on existing draft.
     + Co-authors suggested merging the above draft with
     draft-ietf-l2vpn-vpls-ldp-mac-opt-01 (LDP Extensions for Optimized 
MAC
     Withdrawl in H-VPLS), in order to have a single consolidated document
     that covers all optimized LDP Extensions for Optimized MAC withdrawl
     for all underlying Ethernet technologies.
     + There were 10 people @ WG meeting that agreed to merge the two 
drafts,
     and 1 objection.
     + Co-chairs to follow-up with call on WG mailing list to merge
     the two drafts together before next IETF.
---snip---

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

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

---

From: Jiang Yuanlong <[email-masked]>
Date: Wed, 05 May 2010 14:59:33 +0800

Support.

Regards
Yuanlong

> that covered all LDP-based MAC Withdraw procedures in a single place. 
> Here are the two drafts:
>     draft-ietf-l2vpn-vpls-ldp-mac-opt-01 (LDP Extensions for Optimized MAC

---

From: [email-masked]
Date: Wed, 5 May 2010 16:19:06 +0800

Hi Himanshu,
For the last comments in below email, I don't think MP2P PW can simply 
follow the FEC128/129 defined in RFC4447. There are some other issues, for 
example, because of unidirectional nature of MP2P PW, it is unable to 
negotiate PW status as P2P PW, then how to advertise the PW status for 
MP2P PW? How about the C-bit negotiation?

BR
Lizhong

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

Message: 1
Date: Mon, 3 May 2010 15:26:56 -0700
From: Himanshu Shah <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>,
                 Shane           Amante <[email-masked]>, 
"[email-masked]"
                 <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Thanks again Pranjal for your comments in blue..

I am removing older text to shorten the email.

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

Hi Himanshu,
                          Please refer my responses inline in blue.

Thanks,
Pranjal

________________________________

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

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

[Himanshu] I understand. That is why I used "if label TLV is used".
I think the larger point is that 'double-release-coordination', if it is
a real problem, needs to be fixed in base LDP rather than each use 
application.
But for now, as mathew suggested, we will address it in next rev.

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>

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

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

[Himanshu] I disagree with your point here. Let me tell you why -
1)  Simply by augmenting the MAC address to the FEC 128 does not change 
the fact
    that portion of the FEC (PW-Id field) does uniquely identify IPLS 
instance which
    serve as anchor for all the PWs in that IPLS instance. One may not 
want to
    use FEC 128, but certainly at the time of initial write up, FEC 128 
usage
    was more popular than FEC 129.
2)  As for implementing to co-exist in the current PW architecture, the 
extended
    identification criteria (MAC address), one can utilize 'user exit' 
routine to identify
    and hence accord label operations such as send, receive, etc.
3)  RFC 4447 clearly states that it does not define p2mp, mp2p or mp2mp 
PWs. It is OK
    for a PW use case (which IPLS is) to extend the scope.
4) As for FEC 129, AGI is indeed an IPLS instance, VPN ID, as is true for 
VPLS.
    However, SAII+TAII, which are commonly AC identifier at source & 
destination for
    a bi-directional p2p PW does not apply to IPLS, as you correctly point 
out,
    because of its use as mp2p unidirectional nature of the PW for IPLS. 
Again, proper
    use of exit routines would facilitate leveraging the existing code 
with minor
    modifications.

regards,
himanshu

Thanks,
Pranjal

---

From: David Allan I <[email-masked]>
Date: Wed, 5 May 2010 17:35:40 -0400

I'm a bit confused....

802.1Qbe MIRP appears to be addressing the major headwound implied in the PBB draft (which is an I-SID specific flush)...this is with a modifcation to the existing MVRP/MMRP protocols for 802.1a

It has the virtue that it can extend beyond a co-located PE/BEB for the scenarios where there is a subtending PBBN and thus is a much more general solution to the problem than what is confined to the LDP control plane....

I'm not sure that without better reason I would endorse pursuing a solution largely limited to the complete absence of ethernet networking. The subtending PBBN case should be considered.

Cheers
D

> At the last IETF meeting in Anaheim, there was good consensus in the 
> room to merge the following two drafts in order to have a single 
> specification that covered all LDP-based MAC Withdraw procedures in a single place.
> Here are the two drafts:
> draft: draft-ietf-l2vpn-vpls-ldp-mac-opt-01.  Please indicate whether 
> or not you support merging the two drafts.
>
> P.S. -- Here is a snippet of the notes related to this draft that I 
> sent out to the WG mailing list back on 4/4/2010:

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 5 May 2010 17:42:38 -0500

David,

We have a number of LDP VPLS deployments that are using/are interested to use PBB-VPLS in an MPLS only environment. These deployments already use LDP MAC Flush for VPLS and prefer to keep using it for PBB-VPLS. There is no subtending native PBB domain so no issue with the proposed solution.

The LDP MAC Flush extensions proposed in draft-balus are designed to address the above scenarios. Whoever deploys a native PBB domain and whenever MIRP specification passes sponsor ballot in IEEE and gets implemented, one can choose to use it. 

Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Allan I
> Sent: Wednesday, May 05, 2010 2:36 PM
> To: Jiang Yuanlong; [email-masked]
> Cc: Shane Amante
> Subject: RE: Merge MAC Withdraw Drafts?
> 
> I'm a bit confused....
> 
> 802.1Qbe MIRP appears to be addressing the major headwound implied in
> the PBB draft (which is an I-SID specific flush)...this is with a
> modifcation to the existing MVRP/MMRP protocols for 802.1a
> 
> It has the virtue that it can extend beyond a co-located PE/BEB for the
> scenarios where there is a subtending PBBN and thus is a much more
> general solution to the problem than what is confined to the LDP
> control plane....
> 
> I'm not sure that without better reason I would endorse pursuing a
> solution largely limited to the complete absence of ethernet
> networking. The subtending PBBN case should be considered.
> 
> Cheers
> D
> 
> > acceptable to merge draft-balus-l2vpn-pbb-ldp-ext-02 into the
> existing
> > WG

---

From: David Allan I <[email-masked]>
Date: Wed, 5 May 2010 19:05:18 -0400

Hi Florin:

I appreciate that is your situation today. What you have is a specialized solution that in the future will require you to negotiate what is the appropriate notification mechanism ....as it will be subtending topology dependent and hence the optimal flush mechanism will need to be agreed between individual pairs of Pes on the basis of failure type. Meanwhile if .1Qbe is considered you can establish a framework that covers the landscape now...as it will be independent of where the BEB functionality is placed in the network...

As yours is an individual draft not likely to hit standards track any time sooner than .1Qbe, what is the hurry?

Cheers
D

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 6:43 PM
To: David Allan I; [email-masked]
Cc: Shane Amante
Subject: RE: Merge MAC Withdraw Drafts?

David,

Florin

> It has the virtue that it can extend beyond a co-located PE/BEB for 
> the scenarios where there is a subtending PBBN and thus is a much more 
> > specification that covered all LDP-based MAC Withdraw procedures in 
> > a
> single place.
> > Here are the two drafts:
> > draft: draft-ietf-l2vpn-vpls-ldp-mac-opt-01.  Please indicate 
> > whether or not you support merging the two drafts.
> >

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 10 May 2010 05:38:48 +0530

Hi Lizhong,
                    I agree that MP2P PW can't simply follow RFC 4447. In absence of two way signaling,
there can't be full-fledged negotiation of certain parameters like cBit, PW status etc. However, the
receiving end can do unsolicited release of PW same way as in RFC 4447 based on local configurations
on cBit etc. Same applies to IPV6 capability negotiations in IPLS as well. For example, if receiving PE1
supports a capability and sender PE2 doesn't then PE1 can release label received from PE2 with the
 respective status code (Illegal cBit, IP type mismatch etc).

Thanks,
Pranjal

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 05, 2010 1:19 AM
To: [email-masked]; [email-masked]; Dutta, Pranjal K (Pranjal); [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Himanshu,
For the last comments in below email, I don't think MP2P PW can simply follow the FEC128/129 defined in RFC4447. There are some other issues, for example, because of unidirectional nature of MP2P PW, it is unable to negotiate PW status as P2P PW, then how to advertise the PW status for MP2P PW? How about the C-bit negotiation?

BR
Lizhong

Message: 1
                Shane                 Amante <[email-masked]>, "[email-masked]"

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

Hi Himanshu,

Thanks,
Pranjal

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

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

[Himanshu] I understand. That is why I used "if label TLV is used".
I think the larger point is that 'double-release-coordination', if it is
a real problem, needs to be fixed in base LDP rather than each use application.
But for now, as mathew suggested, we will address it in next rev.

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

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

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

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

[Himanshu] I disagree with your point here. Let me tell you why -
1)  Simply by augmenting the MAC address to the FEC 128 does not change the fact
   that portion of the FEC (PW-Id field) does uniquely identify IPLS instance which
   serve as anchor for all the PWs in that IPLS instance. One may not want to
   use FEC 128, but certainly at the time of initial write up, FEC 128 usage
   was more popular than FEC 129.
2)  As for implementing to co-exist in the current PW architecture, the extended
   identification criteria (MAC address), one can utilize 'user exit' routine to identify
   and hence accord label operations such as send, receive, etc.
3)  RFC 4447 clearly states that it does not define p2mp, mp2p or mp2mp PWs. It is OK
   for a PW use case (which IPLS is) to extend the scope.
4) As for FEC 129, AGI is indeed an IPLS instance, VPN ID, as is true for VPLS.
   However, SAII+TAII, which are commonly AC identifier at source & destination for
   a bi-directional p2p PW does not apply to IPLS, as you correctly point out,
   because of its use as mp2p unidirectional nature of the PW for IPLS. Again, proper
   use of exit routines would facilitate leveraging the existing code with minor
   modifications.

regards,
himanshu

Thanks,
Pranjal

---

From: [email-masked]
Date: Mon, 10 May 2010 09:04:04 +0800

Hi Pranjal,
Thank you for your comments. Unsolicited release will not always work 
properly. And this mechanism voliates the label liberal retention mode 
sometimes. For example, if IP type mismatch happened, and receiver PE1 
release the PW, then when PE1 reconfigure the PW type to "IP", sender PE2 
will not advertise the label again except also reconfiguring PE2. Anyway, 
we can have other ways to solve these problems, e.g, no negotiation for 
Cbit, PW status or PW type.

I only try to point out the problems we need to solve for MP2P PW setup:
1. FEC definition and processing, whether it is suitable be shared with 
FEC128/129.
2. Negotiation, e.g, PW status, Cbit. Whatever solution we use, it should 
be clarified in the draft.

BR
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> 
2010-05-10 08:08

To
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>
cc

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

Hi Lizhong,
                    I agree that MP2P PW can’t simply follow RFC 4447. In 
absence of two way signaling,
there can’t be full-fledged negotiation of certain parameters like cBit, 
PW status etc. However, the 
receiving end can do unsolicited release of PW same way as in RFC 4447 
based on local configurations 
on cBit etc. Same applies to IPV6 capability negotiations in IPLS as well. 
For example, if receiving PE1 
supports a capability and sender PE2 doesn’t then PE1 can release label 
received from PE2 with the
 respective status code (Illegal cBit, IP type mismatch etc).
 
Thanks,
Pranjal

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 1:19 AM
To: [email-masked]; [email-masked]; Dutta, Pranjal K (Pranjal); 
[email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Himanshu, 

BR 
Lizhong

Message: 1

Hi Himanshu,

Thanks,
Pranjal

<Comment>

</Comment>

         implementations would consider one label from a peer against a PW 
(which

         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.

   serve as anchor for all the PWs in that IPLS instance. One may not want 
to
   use of exit routines would facilitate leveraging the existing code with 
minor
   modifications.

regards,
himanshu

Thanks,
Pranjal

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

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 10 May 2010 07:05:36 +0530

Hi Lizhong,
                   Please refer inline. Curtailed the rest of the thread due to size issue.
Thanks,
Pranjal

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, May 09, 2010 6:04 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Pranjal,
Thank you for your comments. Unsolicited release will not always work properly. And this mechanism voliates the label liberal retention mode sometimes. For example, if IP type mismatch happened, and receiver PE1 release the PW, then when PE1 reconfigure the PW type to "IP", sender PE2 will not advertise the label again except also reconfiguring PE2. Anyway, we can have other ways to solve these problems, e.g, no negotiation for Cbit, PW status or PW type.
[Pranjal] Yes I agree. We can use existing proven mechanisms to solve this problem.
I only try to point out the problems we need to solve for MP2P PW setup:
1. FEC definition and processing, whether it is suitable be shared with FEC128/129.
2. Negotiation, e.g, PW status, Cbit. Whatever solution we use, it should be clarified in the draft.
[Pranjal]  I agree, but I am not sure if IPLS needs to address the complete spec of MP2P PW setup since
              this is a specific application unless it has the need for control word etc. However, I see that need
              to address IPV6 capability exchange for IPLS.

BR
Lizhong

2010-05-10 08:08

To

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

cc

Subject

Hi Lizhong,

Thanks,
Pranjal

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 10 May 2010 13:51:02 -0700

Re-sent with shorter message as the previous send exceeds 40K limit.

From: Himanshu Shah
Sent: Monday, May 10, 2010 4:41 PM
To: [email-masked]'; Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Lizhong/Pranjal -

Sorry for delayed responses and thanks for your (and Pranjal's) comments.

I take your point that more text needs to be added to clarify few things that you point out below.

A couple of comments on your points -

1)    C-bit negotiation - IPLS does not use control word for Ethernet and IP PW

2)    PW status - The traditional label-withdraw suffices given the nature of PW that is MP2P and unidirectional

3)    The label release for IPv6 capability mismatch works in following way. The "multicast" PW is the principle PW which

in effect, represents the IPLS instance on that PE. A label release by the receiver on any of the component PW

(i.e. IP PW), should be followed by release of the label for all other component and withdraw/release principle PW

(i.e. 'multicast' Ethernet PW) in order to avoid black holing due to partial mesh.  This in effect disconnects

the complaining PE from the IPLS instance from the rest of the PEs. This applies to any label release due to

config mismatch. However, this is not true for label withdraw when a CE 'gone away' is detected. When config

is changed on the complaining PE, entry procedure to IPLS instance should be re-applied.

Again, agree, more text is needed to explain the points you have raised.

Regards,
himanshu

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, May 09, 2010 9:04 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Himanshu Shah; [email-masked]; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Pranjal,

BR
Lizhong

2010-05-10 08:08

To

cc

Subject

Hi Lizhong,

Thanks,
Pranjal