Subject: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"

From: Jiang Yuan-long <[email-masked]>
Date: Sat, 23 May 2009 10:06:29 +0800

Hi all,
After going through RFC 4762, I think there might be some improvements 
on the texts, as follows:

1. Section 6.1.1, the 1st paragraph, on page 8, it says:
|   [RFC4447] describes a generalized FEC structure that is be used for 
    VPLS signaling in the following manner.  We describe the assignment 
    of the Generalized PWid FEC Element fields in the context of VPLS 
    signaling. 
It should say:
|   [RFC4447] describes a generalized PWid FEC structure that can be used for 
    VPLS signaling in the following manner. We describe the assignment 
    of the Generalized PWid FEC Element fields in the context of VPLS 
    signaling. [...]

2. Section 6.1.1, the last paragraph at the bottom of page 8, it says:
   Target Attachment Individual Identifier (TAII), Source Attachment
   Individual Identifier (SAII): These are null because the mesh of PWs
|  in a VPLS terminates on MAC learning tables, rather than on  
   individual attachment circuits. [...]

   I think "MAC learning table" is confused with "VSI with a MAC 
   learning table" here. BTW, this confusion between VSI and MAC table 
   first appears in RFC 4664, which states in Section 3.4:
   "[...]. Conceptually, the PE bridge module's forwarding table and
   the VPLS Forwarder's VSI are distinct entities.  (Of course,
   particular implementations might combine these into a single table,
   but that is beyond the scope of this document.)" 
   In fact, as the definition of VSI in RFC 4664 shows "the forwarder in 
   a VPLS-PE is a Virtual Switching Instance (VSI)" (on page 9)

   so it should better say: 
   Target Attachment Individual Identifier (TAII), Source Attachment
   Individual Identifier (SAII): These are null because the mesh of PWs
|  in a VPLS terminate on VSIs each with a MAC learning tables, rather than on  
   individual attachment circuits. [...]

3. Section 6.1.1, on page 8, it says:
   PW type: The allowed PW types are Ethernet (0x0005) and Ethernet
   tagged mode (0x004), as specified in [RFC4446].  

   where value '0x004' should be '0x0004', as defined in RFC 4446.
   The meaning for the latter is that PW type is a 15-bit value.

4. Section 6.2.2, near the top of page 11, it says:
|  -  Remove the association between the MAC address and the AC or PW
|     over which this message is received.
 
      As no LDP message can be sent on the AC or PW, and the AC or PW has
      no meaning with regard to this removal, so it should better say:
      
|  - Remove the item corresponding to this MAC address in the forwarding 
|    table of this VPLS instance, whichever AC or PW this MAC address is 
|    associated with. 

5. Section 8.1, at the bottom of page 13, it says:
|  In a VPLS, a customer Ethernet frame without preamble is encapsulated 
   with a header as defined in [RFC4448].
   
   it should better say:
|  In a VPLS, a customer Ethernet frame without the preamble is encapsulated 
   with a header as defined in [RFC4448].

6. The last paragraph before Section 10.1, on page 16, it says:   
|  For rest of this discussion we refer to a bridging capable access
   device as MTU-s and a non-bridging capable PE as PE-r.  We refer to a
   routing and bridging capable device as PE-rs.

It should say:
|  For the rest of this discussion we refer to a bridging capable access
   device as MTU-s and a non-bridging capable PE as PE-r.  We refer to a
   routing and bridging capable device as PE-rs.
   
7. Section 10.1, the 1st paragraph, it says:
   This section describes the hub and spoke connectivity model and
|  describes the requirements of the bridging capable and non-bridging
|  MTU-s devices for supporting the spoke connections. 

As the prior paragraph defines MTU-s and PE-r to be distinct entities, 
so it should better say:

   This section describes the hub and spoke connectivity model and
|  describes the requirements of the MTU-s and the PE-r for supporting 
|  the spoke connections.

8. section 10.2, the 2nd paragraph, on page 21, it says:
   In this section, we describe how the redundant connections can be
   provided to avoid total loss of connectivity from the MTU-s.  The
|  mechanism described is identical for both, MTU-s and PE-r devices.
   
The comma in the last sentence should be deleted, so it should say:

   In this section, we describe how the redundant connections can be
   provided to avoid total loss of connectivity from the MTU-s.  The
|  mechanism described is identical for both MTU-s and PE-r devices.

9. Section 10.2.2, the 1st paragraph, on page 22, it says:
                                                                        [...]. The use
|  of other mechanisms that could provide faster detection failures is
   outside the scope of this document.
   
   It should say:
                                                                        [...]. The use
|  of other mechanisms that could provide faster detection of failures is
   outside the scope of this document.
   
10. Section 10.2.2, the 2nd paragraph, on page 22 and 23, it says:  
                                                 [...]. To enable faster
   convergence, the PE3-rs where the secondary PW got activated may send
   out a flush message (as explained in Section 6.2), using the MAC List
|  TLV, as defined in Section 6, to all PE-rs nodes. [...]
   
   For more clarity, it should better say:
                                                 [...]. To enable faster
   convergence, the PE3-rs where the secondary PW got activated may send
   out a flush message (as explained in Section 6.2), using the MAC List
|  TLV, as defined in Section 6, to all the other PE-rs nodes. [...]

11. Two abbreviations of 'SP' appear in this document with no introduction, 
but they have different meanings, and the second is a typo:

Section 11.1, the 1st paragraph, on page 24, it says: 
|                      [...]. The SP network consists of a
   core MPLS/IP network that connects many Ethernet islands. [...]

It might better say:
|                    [...]. The service provider network consists of a
   core MPLS/IP network that connects many Ethernet islands. [...]

Section 11.2, the 1st paragraph, at the top of page 25, it says:
                               [...]. If an island has more than one
|  PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs
|  devices for carrying the SP BPDU packets for that island. [...]

It should say:   
                               [...]. If an island has more than one
|  PE-rs, then a dedicated full-mesh of PWs are used among these PE-rs
|  devices for carrying the STP BPDU packets for that island. [...]

12. Appendix A, on page 29, in the diagram of PWid FEC TLV, it might be 
better for all the fields' name to be consistent with RFC 4447, so:
   "PW TLV" should be "PWid FEC"
   "PWID" should be "PW ID"

    Appendix A, the last paragraph, on page 29, it says:
|  In a VPLS, we use a VCID (which, when using the PWid FEC, has been
   substituted with a more general identifier (AGI), to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
|  Note that the VCID as specified in [RFC4447] is a service identifier,  
   identifying a service emulating a point-to-point virtual circuit. [...]
   
  Note: 'VCID' last appeared in draft-ietf-pwe3-control-protocol-00.txt, 
  but this field was renamed as 'PW ID' in draft-ietf-pwe3-control-protocol-01.txt,
  which finally evolved into RFC 4447.  AGI is a field in the Generalized 
  PWid FEC, not in the PWid FEC.  So it should say:

|  In a VPLS, we use a VCID (which, when using the Generalized PWid FEC, has been
   substituted with a more general identifier (AGI), to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
|  Note that the VCID, which is later renamed as 'PW ID' in [RFC4447], is a service identifier,  
   identifying a service emulating a point-to-point virtual circuit. [...]

  Thanks,

-Yuanlong Jiang

---

From: Peng He <[email-masked]>
Date: Sun, 24 May 2009 14:26:57 -0400

Interesting.   I have the same confusion as Yuan-long on item 12th in his below e-mail.

Regards,
Peng
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jiang Yuan-long [[email-masked]]
Sent: Friday, May 22, 2009 10:06 PM
To: Shane Amante; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Comments on RFC 4762   "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"

Hi all,

   so it should better say:

   it should better say:

It should say:

   It should say:
                                                                        [...]. The use

It might better say:

It should say:

  Thanks,

-Yuanlong Jiang

---

From: Jiang Yuan-long <[email-masked]>
Date: Mon, 25 May 2009 11:30:06 +0800

Another misleading sentence in RFC 4762, near the bottom of page 10:

   [...]. Note that if a PE receives a MAC Address Withdraw Message
   and does not understand it, it MUST ignore the message. [...]

As MAC Address Withdraw Message is extended based on Address
Withdraw Message defined in RFC 3036 and uses the same message type,
I believe that every PE with LDP support should understand this type
of message.

So, maybe it should be:
   [...]. Note that if a PE receives a MAC Address Withdraw Message
   and does not understand the MAC List TLV in the message, it MUST
   ignore the whole message. [...]
or:
   [...]. Note that if a PE receives a MAC Address Withdraw Message
   and does not understand the MAC List TLV in the message, it MUST
   ignore this TLV. [...]

Not sure which is the intention of the text, any comments?

      Thanks
Yuanlong Jiang

----- Original Message ----- 
From: "Peng He" <[email-masked]>
To: "Jiang Yuan-long" <[email-masked]>; "Shane Amante" 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 25, 2009 2:26 AM
Subject: RE: Comments on RFC 4762"Pseudowire Setup and Maintenance Using the 
Label Distribution Protocol (LDP)"

Interesting.   I have the same confusion as Yuan-long on item 12th in his 
below e-mail.

Regards,
Peng
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jiang 
Yuan-long [[email-masked]]
Sent: Friday, May 22, 2009 10:06 PM
To: Shane Amante; [email-masked]; 
[email-masked]
Cc: [email-masked]
Subject: Comments on RFC 4762   "Pseudowire Setup and Maintenance Using the 
Label Distribution Protocol (LDP)"

Hi all,

|   [RFC4447] describes a generalized PWid FEC structure that can be used 
for

   so it should better say:
   Target Attachment Individual Identifier (TAII), Source Attachment
   Individual Identifier (SAII): These are null because the mesh of PWs
|  in a VPLS terminate on VSIs each with a MAC learning tables, rather than 
on
   individual attachment circuits. [...]

   it should better say:

It should say:

                                                                        [...]. 
The use

   It should say:
                                                                        [...]. 
The use

It might better say:

It should say:

  Note: 'VCID' last appeared in draft-ietf-pwe3-control-protocol-00.txt,
  but this field was renamed as 'PW ID' in 
draft-ietf-pwe3-control-protocol-01.txt,
  which finally evolved into RFC 4447.  AGI is a field in the Generalized
  PWid FEC, not in the PWid FEC.  So it should say:

|  In a VPLS, we use a VCID (which, when using the Generalized PWid FEC, has 
been
   substituted with a more general identifier (AGI), to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
|  Note that the VCID, which is later renamed as 'PW ID' in [RFC4447], is a 
service identifier,
   identifying a service emulating a point-to-point virtual circuit. [...]

  Thanks,

-Yuanlong Jiang