Subject: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt

From: Olen Stokes <[email-masked]>
Date: Fri, 5 Jun 2009 07:02:51 -0700

I have the following questions on draft-martini-pwe3-iccp-01.txt:

1)      In Section 4.1, it states that "the redundancy mechanism employed towards the access node/network can be one of a multitude of technologies".  Are there any restrictions on the access network?  In particular, are there any restrictions about a given packet reaching both PE1 and PE2 from the access network in Figure 1?  If not, is it true that a packet received on a PW at PE1 and sent toward the access network may reach PE2 via the access network?

2)      In Section 5.2, it states, "The RG will not become operational until the corresponding RG Connect Message has been received."  If a single node comes up and does not receive any ICCP capable announcements, does it become operational?  What if it has been configured that a second node is supposed to be present?  If so, what happens when a second node later advertises that it is ICCP capable?  Is the RG operational between the second capability announcement and the subsequent connect message?

3)      In Section 6, it states the following:

- BFD
       Run a BFD session [BFD] between the PEs that are members of a
       given RG, and use that to detect PE node failure. This assumes
       that resiliency mechanisms are in place to protect connectivity
       to the remote PE nodes, and hence loss of BFD periodic messages
       from a given PE node can only mean that the node itself has
       failed.

How is this guaranteed?  There can be n-links between two interconnected PEs in a Redundancy Group.  If the BFD session between the two PEs goes down, all that is really known is that the two PEs cannot communicate over those n-links.  How does this guarantee that the remote PE is not forwarding access network data to the core network over other links?

Take a Redundancy Group as shown in Figure 1 where PE1 and PE2 are H-VPLS MTU-s switches with connections to the core.  Assume that they have dedicated interconnection with n-links.  If somehow all n-interconnect links fail, then will not both nodes assume that the remote node has failed?  If so, then it appears that a loop is very possible.  Losing connection to the core after a large number of failures would seem to be a better alternative than any risk of a loop.

4)      Section 8.1.5 - It states that a PW Id TLV is "used to communicate the configuration of PWs for VPWS."  Is there some reason that this cannot be used with a (H)VPLS?  For example, there could be redundant MTUs that are connecting to a core group of PEs as discussed above.

5)      Section 8.1.5 - There is a Peer ID field included in the TLV.  What is the intent of the Peer ID?

6)      Are there any provisions for when an access network might segment with part of the access network still having connectivity to one PE while the remainder of the network has connectivity to the other PE?  I realize that how this condition is recognized may be out of the scope of this document, but how the PEs communicate this condition could potentially be included.

Thanks for your attention.

Cheers,
Olen