[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] Comments on draft-ietf-pwe3-segmented-pw-11.txt
Thanks Stewart.
Comments Below.
Luca
Stewart Bryant wrote:
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.
I would like to keep this here, since it makes the document readable.
- 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
I will fix this omission.
- 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:
changed to:
The PWE3 Architecture [rfc3985],
SB>RFC editor will definately change "come into play"
ok changed to "are most useful"
-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
yes , this is a side effect of the terminology changes, i will do a
search for all " ultimate" occurrences
fixed.
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.
yes. Fixed.
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
fixed everywhere.
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?
yes. This is really an introduction, as we have on all pwe3 documents.
I'm open to remove it, but it is nice to read one document , and
understand the technology without constantly going back to the
architecture document.
<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.
I made some minor changes to this paragraph. However it seems to be
mostly fine.
here is the current text:
"The general approach taken for MS-PWs 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 by the S-PE, and immediately used to form the PW setup messages for
the next SS-PW of the MS-PW. If one of the S-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 only when
all the constituent SS-PWs are UP."
does this work ?
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"
PW domain . Fixed.
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?
I take impairments as a negative , so we add impairments to a network ,
it makes it worse ...
which is the point here.
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
Fixed.
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?
no, ttl=255 is the maximum allowed amount, which is the usual default
policy.
I do not understand your comment on QoS ... there is no mention of QoS
in the above text.
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?
there is no such thing as a PW TTL. the text above is correct.
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.
fixed text as follows:
"
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 local policy on the originating
PE, but SHOULD be set to 255. However if the PW PDU contains an OAM packet
then the TTL can be set to the required value as explained later in this
document.
"
The control plane set what the TTL should be , so this is a good place
as any to discuss this.
I'm open to suggestions. The data plane discussion could be split, but
there is so little to say that we do not have a section on it.
So we put this text in the general MPLS-MPLS 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?
i meant "appropriate" .. fixed.
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"
active/passive is defined elsewhere in this document. It means that the
S-PE will send a PW label mapping immediately.
see previous section "FEC 129 Active/Passive T-PE Election Procedure"
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
changed to "when"
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
fixed.
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.
fixed.
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.
This seems pretty clear to me , and is very similar to the text in rfc5036.
Can you suggest something better ?
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?
It does not. The operator is supposed to manually configure the other
S-PE to be passive.
I would really like to to remove this option, but some operators asked
for it.
I cannot quantify the advantage of defeating the automatic algorithm.
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>
???
it proceeds the previous section already .....
where do you ant to put this ?
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
I Put 3 in , but i think the RFC editor will make it pretty anyhow. :-)
[note] LDP TLV type is pending IANA approval.
SB> Has this TLV request been approved by MPLS WG yet?
No it must have been missed... the allocation is available , and we have
other already allocated but not this one.
Can you please send a request ?
<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
Good catch , i cleaned up the mess resulting in :
Sending the PW switching Point TLV ( S-PE TLV ) is OPTIONAL, however the PE
or S-PE MUST process the TLV upon reception. The "U" bit MUST be set for
backward compatibility with T-PEs that do not support the MS-PW extensions
described in the document. The S-PE TLV MAY appear only once for each
switching point traversed. The S-PE TLV is appended to the PW FEC at each
switching point, and the order of the S-PE TLVs in the LDP message 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.
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?
I have a comment above, which is more accurate then what we had before.
I added :
It should also be noted that because there are no S-PE TLVs describing
the path beyond the S-PE that removed them, VCCV will only work as far
as that S-PE .
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
added:
The S-PE TLV contains sub-TLVs that describe various characteristics of
the S-PE traversed.
Below are the definitions of PW Switching Point Sub-TLVs defined in
this document:
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.
i also fixed this formatting error.
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?
fixed as follows:
A switching point PE SHOULD inspect the PW switching Point TLV, to
verify that it's own IP address does not appears in it.
If the PE's IP address appears in a received PW switching Point TLV, the PE
SHOULD break the loop, and send a label release message with the following
error code:
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
changed to appropriate
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?
that mode does not exist, and is undefined.
We do not support dynamic interworking of the two protocols.
<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?
Carlos is the expert on this topic, but I believe that there is no
support for the "ack" you mention in L2TPV3.
<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?
Yes I missed this.
I removed the text.
it is now :
"Other interface parameter mappings are unsupported when switching
between LDP/MPLS and L2TPv3 PWs."
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.
Sorry , I do not understand this comment.
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 formatting had a bug in this title - i fixed it.
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'm going to add the picture from rfc3985.
-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?
Similarly to SS-PW
<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.
fixed.
<snip>
9.5.2.5. MS-PW Path Trace
SB> This looks the same as MS-PW Path Verification
SB> What is the difference?
This is to accommodate existing deployments , and is optional. Otherwise
the result is the same, there is no functional difference.
MS-PW Path Verification takes control plane information received at PW
signaling time and verifies that the dataplane agrees.
Path trace ask the control plane in turn , at each ms-pw hop for the
information of the next hop and does the same.
<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.
This is not a standard stile , if you take, for example , the IDR WG ,
they almost never use numbers , and the diagrams are very difficult to read.
I did not assign a figure number to this picture because I do not want
it quoted elsewhere , as it is a very specific example, and future
extensions can change it.
the more generic figures have numbers assigned to them.
<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"
Can you suggest one ?
<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>
this list has no corresponding figure.
What figure do you wan here ?
12. Security Considerations
This document specifies the LDP and L2TPv3 extensions that are needed
SB> and VCCV extensions
fixed.
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.
we do not really address the security , as we offer no solution in some
cases.
I could say "discuss" ?
<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 :)
??? that was certainly not the intention.
i'll reword it as follows:
Obviously -> Note that
<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.
Ok, first the quote is obsolete , i'll update it to rfc5036.
then i removed the MD5 part. We really can only do what LDP supports in
this case.
<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
yes.
Fixed.
<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
fixed.
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
fixed.
let's get this assigned ASAP !
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
clearly I cut and pasted this text ;-)
maintains a registry of name "L2TPv3 Result Codes" defined by
RFCxxxx. The following value is suggested for assignment:
SB> ... you need the RFC number
it is unclear what rfc defines these , so i'll remove the mention of an RFC.
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
indeed, fixed.
<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>
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www.ietf.org/mailman/listinfo/pwe3