Re: [PWE3] Comments on draft-ietf-pwe3-segmented-pw-11.txt

[Luca Martini <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3