[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PWE3] Comments on draft-ietf-pwe3-segmented-pw-11.txt
I have done a line by line review of
draft-ietf-pwe3-segmented-pw-11.txt and have a
number of comments. The overwhelming majority
of these are editorial but there are a few
technical questions most of which are
clarification issues.
I think that we need to proceed a follows:
Please will the authors need to take a look
at my comments and address the text as necessary.
Then I think that we need to do three things
1) Ask MPLS WG if they are happy with the
LDP material.
2) Ask L2TPext WG if they are happy with the
L2TP text.
3) A couple of other members if PWE3 WG need
to volunteer to read the next version in case
there is anything else that has been missed.
- Stewart
=======================================================
Segmented Pseudowire
draft-ietf-pwe3-segmented-pw-11.txt
Abstract
This document describes how to connect pseudowires (PW) between two
distinct PW control planes or PSN domains. The PW control planes may
belong to independent autonomous systems, or the PSN technology is
SB> technolgy may be hetrogeneous
heterogeneous, or a PW might need to be aggregated at a specific PSN
point. The PW packet data units are simply switched from one PW to
another without changing the PW payload.
SB> That is true for MPLS but MPLS <> L2TPv3 involves a little
SB> more - for example the frame relay formats are different.
2. Terminology
SB> This needs a reference to draft-ietf-pwe3-ms-pw-arch-06.txt
SB> I wonder if we need it here at all since we are going to
SB> have to make sure it survives the various editing rounds
SB> to pub remaining word for word identical to the above
SB> draft.
- PW Terminating Provider Edge (T-PE). A PE where the customer-
facing attachment circuits (ACs) are bound to a PW forwarder. A
Terminating PE is present in the first and last segments of a
MS-PW. This incorporates the functionality of a PE as defined in
[RFC3985].
- Single-Segment Pseudowire (SS-PW). A PW setup directly between
two T-PE devices. Each PW in one direction of a SS-PW traverses
one PSN tunnel that connects the two T-PEs.
- Multi-Segment Pseudowire (MS-PW). A static or dynamically
configured set of two or more contiguous PW segments that behave
and function as a single point-to-point PW. Each end of a MS-PW
by definition MUST terminate on a T-PE.
SB> ... and to prove my point PW Segment, & S-PE have different
SB> definitions and PW Switching is not defined here but is defined
SB> in ms-pw-arch
- PW Segment. A part of a single-segment or multi-segment PW, which
is set up between two PE devices, T-PEs and/or S-PEs.
- Pw Switching Provider Edge (S-PE). A PE capable of switching the
control and data planes of the preceding and succeeding PW
segments in a MS-PW. The S-PE terminates the PSN tunnels of the
preceding and succeeding segments of the MS-PW.
3. Introduction
PWE3 defines the signaling and encapsulation techniques for
SB> Do you mean PWE3 here?
SB> Maybe you need to say PWE3 previously defined..., or
SB> maybe you should callup ms-pw requirements as a way of intro
establishing SS-PWs between a pair of terminating PEs and in the vast
majority of cases this will be sufficient. MS-PWs come into play in
two general cases:
SB>RFC editor will definately change "come into play"
-i. When it is not possible, desirable or feasible to establish
a PW control channel between the ultimate source and
destination PEs. At a minimum PW control channel
establishment requires knowledge of and reachability to the
remote (ultimate) PE IP address. The local (ultimate) PE may
SB> For consistency we should use the term T-PE (this applies
SB> in multiple places
not have access to this information related to topology,
operational or security constraints.
An example is the inter-AS L2VPN scenario where the ultimate
PEs reside in different provider networks (ASes) and it is
the practice to MD5-key all control traffic exchanged
SB> Is MD5 ok with SEC AD? Is the correct verb "MD5-key"?
SB> Maybe you should just use the term "cryptogtaphiclly sign"
SB> effects rest of para.
between two networks. Technically a SS-PW could be used but
this would require MD5-keying on ALL ultimate source and
destination PE nodes. An MS-PW allows the providers to
confine MD5 key administration to just the PW switching
points connecting the two domains.
<snip>
-ii. PWE3 signaling and encapsulation protocols are different.
The ultimate PEs are connected to networks employing
SB> Again use of undefined term ultimate
different PW signaling and encapsulation protocols. In this
case it is not possible to use a SS-PW. A MS-PW with the
appropriate interworking performed at the PW switching
points can enable PW connectivity between the ultimate PEs
in this scenario.
<snip>
4. General Description
A pseudowire (PW) is a tunnel established between two provider edge
(PE) nodes to transport L2 PDUs across a packet switched network
SB> Isn't it to interconnect attachement circuits.
SB> We also support TDM which is not L2 PDU
(PSN) as described in Figure 1 and in [RFC3985]. Many providers have
deployed PWs as a means of migrating existing (or building new) L2VPN
services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN.
<snip>
SB> There is a lot of overlap in this descriptive material with ms-pw arch
SB> I wonder how much of this overlap is useful?
<snip>
SB> There is something wrong with this next para. Did you snip
SB> out some preceeding text - it starts very abruptly and
SB> then strangely changes direction in the middle.
SB> I think that you need to take a look at rewording it.
SB> You might want to break it up into small bits.
In general the approach taken is to connect the individual control
planes by passing along any signaling information immediately upon
reception. First the S-PE is configured to switch a SS-PW from a
specific peer to another SS-PW destined for a different peer. No
control messages are exchanged yet as the S-PE PE does not have
enough information to actually initiate the PW setup messages.
However, if a session does not already exist, a control protocol
(LDP/L2TP) session MAY be setup. In this model the MS-PW setup is
starting from the T-PE devices. Next once the T-PE is configured it
sends the PW control setup messages. These messages are received, and
immediately used to form the PW setup messages for the next SS-PW of
the MS-PW. If one of the Switching PEs doesn't accept an LDP Label
Mapping message then a Label Release message may be sent back to the
originator T-PE depending on the cause of the error. LDP liberal
label retention mode still applies, hence if a PE is simply not
configured yet , the label mapping is stored for future use. A MS-PW
is declared UP when all the constituent SS-PWs are UP.
5. PW Switching and Attachment Circuit Type
The PWs in each PSN are established independently, with each PSN
being treated as a separate PWE3 domain. For example, in Figure 2 for
SB> Again do you mean PWE3 domain or PW domain or some other sort of domain?
SB> missed out the word "the"
case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP
targeted session as described in [RFC4447], and at the same time a
separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for
PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the
same PW type e.g. ATM VCC, Ethernet VLAN, etc.
6. Applicability
The general applicability of MS-PWs and their relationship to L2VPNs
is described in [MS-PW-ARCH]. The applicability of a PW type, as
specified in the relevant RFC for that encapsulation (e.g. [RFC4717]
for ATM), applies to each segment. This section describes further
applicability considerations.
In comon with SS-PWs, the performance of any segment of a MS-PW is
equal to the performance of the PSN plus any impairments Introduced
SB> performance of the PSN less any impairments?
by the PW layer itself. Therefore it is not possible for the MS-PW to
provide better performance than the PSN over which it is transported.
Furthermore, the overall performance of an MS-PW is no better than
the worst performing segment of that MS-PW.
<snip>
7. MPLS-PW to MPLS-PW Control Plane Switching
Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted
SB> set up PW1 (delete "a")
SB> In Fig 3 you use the term "PW Segment 1"
SB> There is no PE2 in Fig 3
session as described in [RFC4447], at the same time a separate
pseudowire PW3 is setup to PE3. Each PW is configured independently
on the PEs, but on PE2 pseudowire PW1 is connected to pseudowire PW3.
PDUs are then switched between the pseudowires at the PW label level.
Hence the data plane does not need any special knowledge of the
specific pseudowire type. A simple standard MPLS label swap operation
is sufficient to connect the two PWs, and in this case the PW
adaptation function is not used. However when pushing a new PSN label
the TTL SHOULD be set to 255, or some other locally configured fixed
value.
SB> The label text above is a bit clumsy you pull a number out of the
SB> hat. Do you need to call up the pipe model? Comment of QoS?
This process can be repeated as many times as necessary, the only
limitation to the number of S-PEs traversed is imposed by the TTL
field of the PW MPLS Label. The setting of the TTL is a matter of
SB> PW TTL?
local policy on the originating PE, but SHOULD be set to 255.
SB> Again do you need to say why 255?
SB> You are in control plane but then swap to TTL for
SB> a bit surely that should be in data plane?
SB> You make the raeder jump around in this section.
<snip>
7.1. Static Control plane switching
SB> It might be helpful to the reader to call out
SB> the case numbers from the list above.
In the case of two static control planes the S-PE MUST be configured
to direct the MPLS packets from one PW into the other. There is no
control protocol involved in this case. When one of the control
planes is a simple static PW configuration and the other control
plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static
control plane should be considered identical to an attachment circuit
(AC) in the reference model of Figure 1. The switching point PE
SHOULD signal the proper PW status if it detects a failure in sending
SB> What do you mean by proper?
or receiving packets over the static PW segment. Because the PW is
statically configured, the status communicated to the dynamic LDP PW
will be limited to local interface failures. In this case, the S-PE
PE behaves in a very similar manner to a T-PE, assuming an active
role.
SB> What do you mean by "assuming an active role"
This means that the S-PE will immediately send the LDP Label
Mapping message if the static PW is deemed to be UP.
7.2. Two LDP control planes using the same FEC type
As stated in a section above, the S-PE PE should assume an initial
SB> Which section above?
SB> Not sure "once" is the right word in the para below
passive role. This means that once independent PWs are configured on
the switching point, the LSR does not advertise the LDP PW FEC
mapping until it has received at least one of the two PW LDP FECs
from a remote PE. This is necessary because the switching point LSR
does not know a priori what the interface parameter field in the
initial FEC advertisement will contain.
SB> PWID comes out of another hat - you need to point to a definition
SB> The next para is perhaps a little too cryptic
The PWID is a unique number between each pair of PEs. Hence Each SS-
PW that forms an MS-PW may have a different PWID. In the case of The
Generalized PW FEC, the AGI/SAI/TAI may have to also be different for
some, or sometimes all, SS-PWs.
7.2.1. FEC 129 Active/Passive T-PE Election Procedure
When a MS-PW is signaled using FEC 129, each T-PE might independently
start signaling the MS-PW. If the MS-PW path is not statically
configured, in certain cases the signaling procedure could result in
an attempt to setup each direction of the MS-PW through different
paths.
SB> Maybe you need to clarify that you mean different S-PEs. You
SB> do not care about the PSN paths.
To avoid this situation one of the T-PE MUST start the PW
signaling (active role), while the other waits to receive the LDP
label mapping before sending the respective PW LDP label mapping
message. (passive role). When the MS-PW path not statically
configured, the Active T-PE (the ST-PE) and the passive T-PE (the
TT-PE) MUST be identified before signaling is initiated for a given
MS-PW.
The determination of which T-PE assume the active role SHOULD be done
as follows:
The SAII and TAII are compared as unsigned integers, if the SAII is
bigger then the T-PE assumes the active role.
SB> Do you mean that the T-PE with the larger xAII assumes the
SB> active roll? It took a couple of parses to get that.
The selection process to determine which T-PE assumes the active role
MAY be superseded by manual provisioning.
SB> If the T-PE with the smaller xAII is configured to be active
SB> how does the other T-PE know?
7.3. LDP FEC 128 to LDP using the generalized FEC 129
When a PE is using the generalized FEC 129, there are two distinct
roles that a PE can assume: active and passive. A PE that assumes the
active role will send the LDP PW setup message, while a passive role
PE will simply reply to an incoming LDP PW setup message. The S-PE
PE, will always remain passive until a PWID FEC 128 LDP message is
received, which will cause the corresponding generalized PW FEC LDP
message to be formed and sent. If a generalized FEC PW LDP message is
received while the switching point PE is in a passive role, the
corresponding PW FEC 128 LDP message will be formed and sent.
SB> It seems like the text about active passive should preceed
SB> the previous section as it seems less abrupt in nature.
SB>
PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice
versa. This can be accomplished by local S-PE configuration, or by
some other means, such as some form of auto discovery. Such other
means are outside the scope of this document.
7.4. LDP S-PE TLV
The edge to edge PW might traverse several switching points, in
separate administrative domains. For management and troubleshooting
reasons it is useful to record information about the switching points
that the PW traverses. This is accomplished by using a S-PE TLV.
Note that sending the S-PE TLV is OPTIONAL, however the PE or S-PE
MUST process the TLV upon reception. The S-PE TLV is appended to the
PW FEC at each switching point. Each S-PE can append a PW switching
point TLV, and the order of the S-PE TLVs MUST be preserved. The S-PE
TLV MUST be sent if VCCV operation is required beyond the first MS-PW
segment from a T-PE.
The S-PE TLV is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW sw TLV (0x096D) | PW sw TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SB> To be kind to people reading this in Emacs - it would be good
SB> to put in another " in the line above
[note] LDP TLV type is pending IANA approval.
SB> Has this TLV request been approved by MPLS WG yet?
<snip>
The PW switching Point TLV is an OPTIONAL TLV that should appear only
SB> First you should have given the TLV name when you introduced
SB> the term above.
SB> Second this repeats what you just said in para 2 of this
SB> section
once for each switching point traversed. If the S-PE TLV is not
present with the required sub-TLVs, VCCV operation will not function.
For local policy reasons, a particular S-PE can filter out all S-PE
TLVs in a label mapping message that traverses it and not include
it's own S-PE TLV. In this case, from any upstream PE, it will
appear as if this particular S-PE is the T-PE. This might be
necessary , depending on local policy if the S-PE is at the Service
provider administrative boundary.
SB> Do you need to comment on the VCCV implications?
7.4.1. PW Switching Point Sub-TLVs
SB> The next sentence does not read right
SB> Then it all gets very abrupt in the description that follows
SB> I am not sure how many readers will figure it out
Below are details specific to PW Switching Point Sub-TLVs described
in this document:
- PW ID of last PW segment traversed. This is only applicable if
the last PW segment traversed used LDP FEC 128 to signal the PW.
This sub-TLV type contains a PW ID in the format of the PWID
described in [RFC4447]. This is just a 32 bit unsigned integer
number.
- PW Switching Point description string.
An optional description string of text up to 80 characters long.
- Local IP address of PW Switching Point.
The Local IP V4 or V6 address of the PW Switching Point. This is
an OPTIONAL Sub-TLV. In most cases this will be the local LDP
session IP address of the S-PE.
- Remote IP address of the last PW Switching Point traversed or of
the T-PE
The IP V4 or V6 address of the last PW Switching Point traversed
or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this
will be the remote IP address of the LDP session. This Sub-TLV
SHOULD only be included if there are no other S-PE TLV present
from other S-PEs, or if the remote ip address of the LDP session
does not correspond to the "Local IP address of PW Switching
Point" TLV value contained in the last S-PE TLV.
- The FEC of last PW segment traversed.
This is only applicable if the last PW segment traversed used LDP
FEC 129 to signal the PW.
The Attachment Identifier of the last PW segment traversed. This
is encoded in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 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.
<snip>
7.6. PW Loop Detection
A switching point PE SHOULD check the OPTIONAL PW switching Point
TLV, to verify if it's own IP address appears in it. If it's IP
SB> Hopefully to determine or to check and not to verify?
SB> Or maybe to verify that it is not in it?
address appears in a received PW switching Point TLV, the PE SHOULD
break the loop, and send a label release message with the following
<snip>
8.2. Static MPLS PW and Dynamic L2TPv3 PW
When a statically configured MPLS PW is switched to a dynamic L2TPv3
PW, the static control plane should be considered identical to an
attachment circuit (AC) in the reference model of Figure 1. The
switching point PE SHOULD signal the proper PW status if it detects a
SB> Again proper?
SB> Same again in section 8.3
failure in sending or receiving packets over the static PW. Because
the PW is statically configured, the status communicated to the
dynamic L2TPv3 PW will be limited to local interface failures. In
this case, the S-PE PE behaves in a very similar manner to a T-PE,
assuming an active role.
<snip>
SB> In case I miss it - what happens about active/passive
SB> negotiation in mixed L2TPv3/MPLS dynamic?
<snip>
8.4.3. Session Tear Down
L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN
message translates to a Label Withdraw message in LDP. Following are
two example exchanges of messages between LDP and L2TPv3. The first
is a case where an L2TPv3 T-PE initiates the termination of an MS-PW,
the second is a case where an MPLS T-PE initiates the termination of
an MS-PW.
PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP)
AC "Down"
L2TPv3 CDN --->
LDP Label Withdraw --->
AC "Down"
<-- LDP Label Release
<--------------- MH PW Data Path Down ------------------>
SB> Is there no ack back in L2TP to say that the CDN has
SB> been actioned?
<snip>
Other interface parameter mappings will either be defined in a future
version of this document,
SB> Is "future version...." correct IETF speak when we are about
SB> to go to RFC?
8.7. L2TPv3 and MPLS PW Data Plane
When switching between an MPLS and L2TP PW, packets are sent in their
entirety from one PW to the other, replacing the MPLS label stack
with the L2TPv3 and IP header or vice versa. There are some
situations where an additional amount of interworking must be
provided between the two data planes at the PW switching node.
SB> You might want to note that these are described in the
SB> following sections. Note that 8.7.1 really should be part
SB> of the intro (8.7) which would fix that problem.
8.7.1. PWE3 Payload Convergence and Sequencing
Section 5.4 of [RFC3985] discusses the purpose of the various shim
headers necessary for enabling a pseudowire over an IP or MPLS PSN.
For L2TPv3, the Payload Convergence and Sequencing function is
carried out via the Default L2-Specific Sublayer defined in [L2TPv3].
For MPLS, these two functions (together with PSN Convergence) are
carried out via the MPLS Control Word. Since these functions are
different between MPLS and L2TPv3, interworking between the two may
be necessary.
The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers
which in some cases are not necessary to be present at all. For
example, an Ethernet PW with sequencing disabled will generally not
require an MPLS Control Word or L2TP Default L2-Specific Sublayer to
be present at all. In this case, Ethernet frames are simply sent from
one PW to the other without any modification beyond the MPLS and
L2TP/IP encapsulation and decapsulation.
The following section offers guidelines for how to interwork between
L2TP and MPLS for those cases where the Payload Convergence,
Sequencing, or PSN Convergence functions are necessary on one or both
sides of the switching node.
8.7.2. Mapping
The MPLS Control Word consists of (from left to right):
SB> Without a picture you can't say left to right, and even
SB> with one you mean from low order bits to high order bits.
SB> However it might be better to quote bit numbers in
SB> the text below.
SB> Maybe you need both headers in the draft to make it clear?
-i. These bits are always zero in MPLS are not necessary to be
mapped to L2TP.
<snip>
9.3. Signaling OAM Capabilities for Switched Pseudowires
Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV
SB> As in?
<snip>
9.5.1. VCCV Echo Message Processing
For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW1,
but it does not readily have the information required to compose the
FEC128 of the following segment, PW3, if a VCCV echo request to be
sent to T-PE2. This can be achieved by the methods described in the
following subsections.
SB> the naming here sort of matches fig 3, but not quite.
<snip>
9.5.2.5. MS-PW Path Trace
SB> This looks the same as MS-PW Path Verification
SB> What is the difference?
<snip>
10. Mapping Switched Pseudowire Status
In the PW switching with attachment circuits case (Figure 2), PW
status messages indicating PW or attachment circuit faults MUST be
mapped to fault indications or OAM messages on the connecting AC as
defined in [PW-MSG-MAP].
In the PW control plane switching case (Figure 3), there is no
attachment circuit at the S-PE, but the two PWs are connected
together. Similarly, the status of the PWs are forwarded unchanged
from one PW to the other by the control plane switching function.
However, it may sometimes be necessary to communicate fault status of
one of the locally attached SS-PW at a S-PE. For LDP this can be
accomplished by sending an LDP notification message containing the PW
status TLV, as well as an OPTIONAL PW switching point TLV as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Status Code=0x00000028 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type=0 | PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV | PWId FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| PWId FEC or Generalized ID FEC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW sw TLV (0x096D) | PW sw TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only one S-PE TLV can be present in this message. This message is
SB> This is a general comment, but I think that it would
SB> be a good idea to allocate figure numbers to the TLV and
SB> protocol exchanges.
SB> This not only allows the reader to point to these
SB> components more easily, but we might want to point to
SB> in another of our documents.
<snip>
The merging of the received LDP status and the local status for the
PW segments at an S-PE can be summarized as follows:
-i. When the local status for both PW segments is UP, the S-PE
SB> We kind of need a better name than "both PW segments"
<snip>
SB> You really ought to five the figure a number and point to it
SB> for the table below.
-i. PW2 Transmit direction fault
-ii. PW1 Transmit direction fault
-iii. PW2 Receive direction fault
-iv. PW1 Receive direction fault
<snip>
12. Security Considerations
This document specifies the LDP and L2TPv3 extensions that are needed
SB> and VCCV extensions
for setting up and maintaining pseudowires. The purpose of setting up
pseudowires is to enable layer 2 frames to be encapsulated and
transmitted from one end of a pseudowire to the other. Therefore we
treat the security considerations for both the data plane and the
SB> address the security?
control plane.
<snip>
12.2. Control Protocol Security
<snip>
A Pseudowire connects two attachment circuits. It is important to
make sure that LDP connections are not arbitrarily accepted from
anywhere, or else a local attachment circuit might get connected to
an arbitrary remote attachment circuit. Therefore an incoming session
request MUST NOT be accepted unless its IP source address is known to
be the source of an "eligible" peer. The set of eligible peers could
be pre-configured (either as a list of IP addresses, or as a list of
address/mask combinations), or it could be discovered dynamically via
an auto-discovery protocol which is itself trusted. (Obviously if the
auto-discovery protocol were not trusted, the set of "eligible peers"
it produces could not be trusted.)
SB> You might want to rephase the last sentence, because it
SB> treats the reader like an idiot :)
<snip>
For a greater degree of security, the LDP MD5 authentication key
option, as described in section 2.9 of RFC 3036, or the Control
Message Authentication option of [L2TPv3] MAY be used.
SB> I am worried that sec review will complain about MD5
SB> do we have to say MD5 rather than something just saying
SB> use the flavor of the month crypto authentication.
<snip>
This provides
integrity and authentication for the control messages, and eliminates
the possibility of source address spoofing. Use of the message
authentication option does not provide privacy, but privacy of
control messages are not usually considered to be highly urgent.
SB> urgent means "do now" I think you mean important
<snip>
13. IANA Considerations
13.1. L2TPv3 AVP
This document uses a ne L2TP parameter, IANA already maintains a
registry of name "Control Message Attribute Value Pair" defined by
[RFC3438]. The following new values are required:
SB> only one value
TBA-L2TP-AVP-1 - PW Switching Point AVP
13.2. LDP TLV TYPE
This document uses several new LDP TLV types, IANA already maintains
SB> But you only ask for one new TLV below
A registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The
following value is suggested for assignment:
TLV type Description
0x096D Pseudowire Switching TLV
13.3. LDP Status Codes
This document uses several new LDP status codes, IANA already
SB> But you only ask for one new status code below
maintains a registry of name "STATUS CODE NAME SPACE" defined by
RFC3036. The following value is suggested for assignment:
Assignment E Description
0x0000003A 0 "PW Loop Detected"
13.4. L2TPv3 Result Codes
This document uses several new L2TPv3 status codes, IANA already
SB> ... and I only see one request below
maintains a registry of name "L2TPv3 Result Codes" defined by
RFCxxxx. The following value is suggested for assignment:
SB> ... you need the RFC number
Assignment Description
17 "sequencing not supported"
13.5. New IANA Registries
IANA needs to set up a registry of "PW Switching Point TLV Type".
These are 8-bit values. Types value 1 through 3 are defined in this
document. Type values 4 through 64 are to be assigned by IANA using
SB> you define 1 through 6 below
<snip>
Type Length Description
0x01 4 PW ID of last PW segment traversed
0x02 variable PW Switching Point description string
0x03 4/16 Local IP address of PW Switching Point
0x04 4/16 Remote IP address of last PW Switching Point traversed
or of the T-PE
0x05 variable AI of last PW segment traversed
0x06 10 L2 PW address of PW Switching Point
<end>