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

From: Himanshu Shah <[email-masked]>
Date: Mon, 3 May 2010 15:26:56 -0700

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: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 10 May 2010 05:31:15 +0530

Hi Himanshu,
                       Thanks for clarifying further. I agree with the fact that RFC 4447 doesn't specify about
p2mp, mp2mp and mp2mp PWs, so IPLS doesn't fall back under the purview of RFC 4447. The question
I had raised since RFC 4447 is a normative reference in the I-D (which definitely we need for Interface
Parameters).  IMO, IPLS signaling model can be seen as similar to the approach in RFC 4364 - distribution
of labeled routes (CE Addresses) with VPN-ID (Pw-Id) rather than as PWs.

Thanks,
Pranjal

________________________________
From: Himanshu Shah [mailto:[email-masked]]
Sent: Monday, May 03, 2010 3:27 PM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

Thanks,
Pranjal

<Comment>

</Comment>

regards,
himanshu

Thanks,
Pranjal