[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: l2vpn-bounces at ietf.org [l2vpn-bounces at ietf.org] On Behalf Of Jiang Yuan-long [yljiang at huawei.com]
Sent: Friday, May 22, 2009 10:06 PM
To: Shane Amante; vach.kompella at alcatel-lucent.com; mlasserre at alcatel-lucent.com
Cc: l2vpn at ietf.org
Subject: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"
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