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

From: Luca Martini <[email-masked]>
Date: Fri, 24 Jul 2009 06:57:30 -0600

Olen,
Sorry for the delay in response , somehow i missed this e-mail.

More below.

Olen Stokes wrote:
> 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?
>
>   
How the packet is sent to the PE on the AC is not dependent on ICCP. THe
protocol used i nthe access network will dictate how we choose the
active link, and how we forward the packet.

> 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?
>
>   
ok, It takes at least 2 nodes to have an RG become operational. So if
one node comes up and there are no other PEs advertising that particular
RG, the RG never becomes operational.
The capability in LDP is only used to for an LSR to be allowed to send
an RG connect message. The RG becomes operational only when both PEs
have sent the RG connect messages. Sec 4.2 in
draft-ietf-pwe3-iccp-01.txt is quite clear on the procedures.

> 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?
>
>   
There are no guarantees against multiple failure events. We are
protecting against a single failure , and all we are saying here is that
the PEs MUST have really good connectivity between each other to almost
exclude the possibility to loose communication between the PEs.
> 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.
>
>   
yes. the split brain problem cannot be completely avoided.  This is why
it is very important that only if all possible connectivity is lost, the
ICCP/BFD session goes down. If a PE is isolated , no looping is
possible, however the service might no longer work.
In a typical application the two PEs are directly connected and co-located.
> 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.
>
>   
no - this is only terminology. We meant to say "For PW" . Of course
H-VPLS with PW access is a valid application.
> 5)      Section 8.1.5 - There is a Peer ID field included in the TLV.  What is the intent of the Peer ID?
>   
this is defined as "Four octet LDP Router ID of the peer at the far end
of the PW"
This is necessary to uniquely identify the PW when using FEC 128.

> 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.
>
>   
this would have to be handled by the access network protocol. It is out
of scope of ICCP.

Thanks.
Luca

> Thanks for your attention.
>
> Cheers,
> Olen
>
>
>
>
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Olen Stokes <[email-masked]>
Date: Thu, 30 Jul 2009 02:50:40 -0700

Please consider the following network based on Figure 1 in the draft:

                            +===============+        +======================
                            |               |        |
                            |  +-----+      |        |    +-----+
                            |  | PE1 ||<----|---PW---|-->|| PE3 ||<-- PW -->
                           -|--|     |      |        |    |     ||<-- PW -->
                          / |  +-----+      |        |    +-----+
                         /  |     ||        |        |       ^
                        /   |     || ICCP   |        |       | PW
          +---------+  /    |     ||        |        |       V
 +----+   |         | /     |  +-----+      |        |    +-----+
 | CE |   | Access  |/      |  | PE2 ||<----|---PW---|-->|| PE4 ||<-- PW -->
 |    +---+ Network |-------|--|     |      |        |    |     ||<-- PW -->
 +----+   |         |       |  +-----+      |        |    +-----+
          |         |       |               |        |
          +---------+       |   Redundancy  |        |     H-VPLS
            ^               |     Group     |        | Full-Mesh Core
            |               +===============+        +======================
            |
     Multi-homed Network

PE1 and PE2 provide redundant access to an H-VPLS network.  They effectively combine to provide the function of a MTU-s as shown in Figure 3 of RFC 4762.  They attach to different PEs to avoid a single point of failure in the H-VPLS core.

The access network is a generic Ethernet L2 network.  A packet destined to an unknown unicast MAC address sent from the CE will be delivered to both PE1 and PE2.

ICCP is used between PE1 and PE2 to determine the active PW to the H-VPLS core.

>From the responses below, the above network configuration seems to be a valid use of ICCP.

While it may be typical that PE1 and PE2 are directly connected and co-located, this is not always the case.  It is definitely possible in some customer installations that the links between them may fail without PE1 or PE2 getting a "loss of signal".

Given the above type of network, the question becomes what happens when all of the links between PE1 and PE2 fail?  Will PE1 and PE2 both assume that the other node has failed since the BFD session between them will go down?  If so, is there not a loop when the PWs from PE1 and PE2 are both active at the same time?

I apologize, but I did not completely understand the statement:

"yes. the split brain problem cannot be completely avoided.  This is why it is very important that only if all possible connectivity is lost, the ICCP/BFD session goes down. If a PE is isolated , no looping is possible, however the service might no longer work."

In the above scenario, the two PEs are isolated from each other, but they are not isolated from the network.

I apologize again, but I do not see how to distinguish with complete certainty in all network environments between:

1)  The node with the active PW has crashed and therefore the secondary PW should be activated, and

2)  All of the links between the RG nodes have failed and therefore the secondary PW should not be activated

My concern is that in order to apply ICCP as it is defined today to generic Ethernet access in an H-VPLS network, it has to be guaranteed that the ICCP session cannot go down due to link failure while the RG nodes (MTU-s) still have connectivity to the H-VPLS core network.  I am not sure how to make that guarantee in the networks in which some customers want to deploy H-VPLS.

I understand that the Ethernet section of the draft has not completed and that more insight into this discussion may appear at that time.

Cheers,
Olen

From: Luca Martini [mailto:[email-masked]]
Sent: Friday, July 24, 2009 8:58 AM
To: Olen Stokes
Cc: [email-masked]
Subject: Re: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt

Olen,

More below.

Olen Stokes wrote:

How the packet is sent to the PE on the AC is not dependent on ICCP. THe protocol used i nthe access network will dictate how we choose the active link, and how we forward the packet.

ok, It takes at least 2 nodes to have an RG become operational. So if one node comes up and there are no other PEs advertising that particular RG, the RG never becomes operational.
The capability in LDP is only used to for an LSR to be allowed to send an RG connect message. The RG becomes operational only when both PEs have sent the RG connect messages. Sec 4.2 in draft-ietf-pwe3-iccp-01.txt is quite clear on the procedures.

- BFD

       failed.

There are no guarantees against multiple failure events. We are protecting against a single failure , and all we are saying here is that the PEs MUST have really good connectivity between each other to almost exclude the possibility to loose communication between the PEs.

yes. the split brain problem cannot be completely avoided.  This is why it is very important that only if all possible connectivity is lost, the ICCP/BFD session goes down. If a PE is isolated , no looping is possible, however the service might no longer work.
In a typical application the two PEs are directly connected and co-located.

no - this is only terminology. We meant to say "For PW" . Of course H-VPLS with PW access is a valid application.

this is defined as "Four octet LDP Router ID of the peer at the far end of the PW"
This is necessary to uniquely identify the PW when using FEC 128.

this would have to be handled by the access network protocol. It is out of scope of ICCP.

Thanks.
Luca

Cheers,

Olen

________________________________

pwe3 mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jiang Yuan-long <[email-masked]>
Date: Fri, 31 Jul 2009 17:15:15 +0800

Hi Luca,

I have some comments on your draft-ietf-pwe3-segmented-pw-12.

Technical comments:
1. In Sec 7.4.1, the description of the 5th sub-TLV is not only "The 
FEC of last PW segment traversed", but also "The Attachment 
Identifier of the last PW segment traversed" in the same section. 
IMO, neither is the exact description.
As defined in RFC 4447, FEC element 129 consists of <AGI, 
SAII, TAII>, and AI consists of <AGI, AII>, so the first is closer 
to the actual format in this ID. But FEC element 129 also includes 
a sub-TLV header which is removed here, therefore I think a more 
accurate description is needed. How about "The neat content of the 
FEC of last PW segment traversed" or something new?
BTW, this description should also align with the sub-TLV type 5 
in Sec 13.5 (in the next to the last line):
"   0x05  variable AI of last PW segment traversed"

2. Also in Sec 7.4.1, the last sub-TLV is very confusing:
"    - L2 PW address of PW Switching Point (recommended format).

   This sub-TLV type contains a L2 PW address of PW Switching Point in
   the format described in [RFC5003]. This includes the AII type field ,
   and length, as well as the L2 PW address."
>From the above paragraph, it seems that 'L2 PW address' is defined in 
RFC 5003, but in fact there is no such a definition. And the actual 
components of L2 PW address is also misleading.
I think a more clear definition is needed, how about the following:
"    - L2 PW address of PW Switching Point (recommended format).

       This sub-TLV type contains a L2 PW address of PW Switching Point,
       which includes a Global ID field and a Prefix field as described 
       in the AII type 2 construct defined in [RFC5003]."

3. In Sec 13.5, in the last line, a sub-TLV type 6 is defined:
   0x06     10    L2 PW address of PW Switching Point 
But the length should be 8 rather than 10, as both Global ID and Prefix 
are 4 octets fields. This mismatch may root in the original ID of RFC 5003, 
which defined Global ID as 6 octets in length, but changes it to 4 in the 
final RFC.
BTW, the same problem also exists in draft-ietf-pwe3-dynamic-ms-pw-09.

Some editoral comments:    
In Sec 7.4,  s/the the/to the/
In Sec 8.1, in the 4th line, "VC Label" should be replaced with "PW label".

In Sec 9.3, in the first sentence, 
  s/interface parameter field/Interface Parameter sub-TLV field/
  s/sub-TLV interface parameter/Interface Parameters sub-TLV/

In Sec 9.4.2, in the first line, s/form/from/

More than one occurence of "no packets MUST be sent..." found in this ID, 
maybe it would be better to say "packets MUST NOT be sent..." 

In Sec 10.1, 
  s/an an/an/
  s/MH-PW/MS-PW/  
  s/more then/more than/

In Sec 13.1, s/ne/new/
In Sec 13.2, inserts 'uses' behind "This document"

In Sec 14 and 15, there are some minor copy & paste errors:
- The title of [RFC4447] should be "Pseudowire Setup and Maintenance 
Using the Label Distribution Protocol (LDP)", rather than "Transport of 
Layer 2 Frames Over MPLS". The latter is the title of a historic RFC 
(RFC 4906).

- The title of [RFC3438] should be "Layer Two Tunneling Protocol (L2TP)
 Internet Assigned Numbers Authority (IANA) Considerations Update"

- Both [RFC3985] and [RFC4379] appear twice in the list of References. 
Please delete one copy for each.

I find the following nomenclatures are used for the same TLV across this ID:
"Switching Point PE TLV,Switching Point TLV,S-PE TLV,
PW sw TLV, PW Switching Point TLV, Pseudowire Switching TLV" 
If we could simplify them to two (one full name and another abbreviation), 
it would be a little easier for us to read this document ^&^ 

Best Regards

Yuanlong Jiang

---

From: Luca Martini <[email-masked]>
Date: Fri, 31 Jul 2009 04:13:58 -0600

Jiang,

Unfortunately this document is past WG Last Call, so I cannot edit it now.
However Once the IETF LC is issued I will be able to correct the document.
I will respond in detail then.

Thanks.
Luca

---

From: Jiang Yuan-long <[email-masked]>
Date: Sat, 01 Aug 2009 10:03:08 +0800

Luca,

Sorry that I was not aware that this draft had past WG Last Call.
But I do appriciate if you can consider these comments in the next revision.

Best Regards
Yuanlong Jiang