Subject: Comments on [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-00.txt

From: David McDysan <[email-masked]>
Date: Tue, 26 Jul 2005 08:48:42 -0400

I propose the following changes to make certain points in the requirements
draft clearer and more precise. Also, some discussion on the list was not
reflected in this version and I make some specific suggestions on how to
include these points in this WG document. I have grouped my comments below
into major/technical and minor/editorial sections.

I suggest that if you wish to start a thread on a particular topic that you
change the subject line so that it will be easier for the editors to track
and document WG consensus.

Thanks,

Dave

Major/Technical comments
========================
4. Terminology

5. Use Cases

vi Pseudo-Wires in Access and Metro Networks

On 2/9/05, I suggested adding a sentence stating that the topology that
connects a U-PE access metro device to an S-PE metro aggregation may be
simple (e.g., single homed from a packet routing perspective) and that
restoration may be handled at lower layers (e.g., SONET/SDH protection).
Nabil agreed, but pointed out that the case where a U-PE is dual homed to
two S-PEs using a primary/backup MS-PW is also possible in this use case. I
request that the editors add these two cases of U-PE to S-PE resiliency to
this use case.

6.1 Architecture

          i S-PEs MAY only support switching PWs of the same PW type. In
            this case, the PW type is transparent to the S-PE in the
            forwarding plane, except for functions needed to provide for
            interworking between different PSN technologies.

The above is inconsistent with the description below Figure 2 "This document
requires support for MS-PWs with segments of the same type." In my opinion,
protocol support for switching PW segements of the same type is mandatory
and switching between different PW types is optional. Suggest changing "MAY"
to "MUST" in the above to address this comment. Requirement v describes
interworking of PW types.

Are the following requirements different ways of stating the same thing? I
think that the wording of iii is clearer and suggest deletion of ii, or at
least further clarification of ii is needed.

       -ii. If MS-PWs are tunneled, using a PSN tunnel overlay, across a
            PSN that only supports SS-PWs, then only the requirements of
            [PWE3-REQ] apply to that PSN.  The fact that the overlay is
            carrying MS-PWs MUST be transparent to the routers in the
            PSN.

      -iii. The PWs MUST remain transparent to the P-routers. A P-router
            is not an S-PE or an U-PE from the MS-PW architecture
            viewpoint. P-routers provide transparent PSN transport for
            PWs and MUST not have any knowledge of PW traversing them.

I raised the following point on 3/9/05 on the list as well as in the
Minneapolis meeting regarding the following requirement:

     -vii. MS-PWs are composed of SS-PW, and SS-PW are bi-directional,
            therefore both directions of a PW segment MUST terminate on
            the same S-PE/U-PE."

This requirement can be read in at least the following two ways:
	1) both directions of every PW segment must terminate on the same
S-PE to S-PE AND on the same S-PE connected to a U-PE at each end of the
pseudowire
	2) both directions of a PW segment must terminate on the same S-PE
connected to a U-PE at each end of the set of PW segements that comprise the
MS-PW.

I propose that the requirement be clarified to state that the first case is
mandatory, since this is what several people have told me is the intent.
Also, several people indicated that there are OAM advantages to this
approach (e.g., having a return channel that traverses the same set of
S-PEs), which I suggest should be mentioned in the document. I had described
on 3/9/05, cases where the above scenarios would be suboptimal than an
approach that did not impose such restrictions and would like to get
feedback from the list as to whether an option for routing that does not
force traversal of the same set of S-PEs in each direction such that higher
utilization results is of interest. 

It does open the door to a more general architectural discussion that I
recall at least Neil Harrison and Yakov Stein have mentioned where making
protocols stackable with functions useable in an recursive manner is
possible. There is an asymmetry in the current PW and MPLS protocol design
in that MPLS LSPs are simplex, while PWs are duplex. A symmetric
architecture would require duplex MPLS LSPs and simplex PWs. In my opinion,
such a discussion is relevant to PWE3, but also relevant to at least MPLS.

6.2 Resiliency

	 -i. The ability to configure an end-end backup PW path for a
            primary PW path MUST be supported. The backup and primary
            paths should have the ability to traverse separate S-PEs.
            The backup path MAY be signaled at configuration time or
            after failure detection.

The last sentence is not optional, as use of the word MAY implies. I believe
what is intended is     "The backup path SHALL be signaled at configuration
time or after failure detection."  Also, an additional clarification is that
at configuration time the backup path cannot be selected before the primary
path has been selected. I think there is also a requiremnent for the case
where if a S-PE diverse backup path cannot be found at configuration time,
then the protocol shall provide a means to indicate this to the configuring
entity.

      -iii. When a MS-PW segment is tunneled over PSN tunnels with fast
            reroute capability fast re-route events SHOULD be
            transparent to the MS-PW.

I'm not clear as to what "transparent" means in this context. I expect there
would be momentary loss as well as a potential change in latency in response
to an (MPLS?) fast re-route event. Also, if the (MPLS or IP)PSN tunnel
changed or re-optimized, momentary loss and a change in latency could
result. Certainly these phenomena are not transparent to the PW. If some
other behavior(s) is to be transparent, then this should be clarified.

       -iv. Automatic Mechanisms to perform a fast switchover from a
            primary PW to a backup PW upon failure detection SHOULD be
            provided to minimize packet loss.

I think this works only if the backup path is pre-established, and suggest
adding this condition to the requirement. Note that requirement i allows the
backup path to be signaled after failure detection.

6.3 Quality of Service and Class of Service

There was a fair amount of discussion on this topic on the list in January
through April, but the only change was made to requirement ii, unrelated to
that discussion. 

       -ii. A method to select per PW/QoS class setup/holding priority
            should be provided.

I suggest that the editors expand the above text and give an example, since
I can interpret the above text in more than one way (e.g., is the
setup/holding priority per PW, or per QoS class, or both?)

Following is a summary of the points discussed and a proposed resolution
based upon the proposal from Richard Spencer with my comments from 4/28/05:

Replace 6.3 i with the following

- The MS-PW signalling protocol must support the option to carry traffic
parameters that allow an S-PE or U-PE perform admission control and/or
dynamically configure per MS-PW traffic conditioning mechanisms (e.g.,
policers, shapers). The parameters controlling admission control decisions
or dynamic configuration of traffic conditioning mechanisms MUST be
configurable.

Replace 6.3.1 i with the following:

- The MS-PW signalling protocol MUST carry enough information for a S-PEs to
be able to select the appropriate PSN tunnel, (e.g., EXP field for MPLS,
DSCP for IP) corresponding to the requested QoS class. S-PEs SHOULD ensure
that only packets with the signaled markings are forwarded.

I think that 6.3.1 ii is redundant with the proposed rewording of 6.3.1 i
and recommend that it be deleted.
 
Section 6.3 iii. Suggest splitting this into two requirements as follows:

	iii. In case the PSN tunnel lacks the resources necessary to
            accommodate the new PW, a PW setup failure message MUST be
            returned and the PW MUST fail to setup.  

	iiia  In case the PSN tunnel lacks the resources necessary to
            accommodate the new PW, an S-PE or U-PE SHOULD attempt to signal
an new PSN
            tunnel, or increase the capacity of the existing PSN tunnel. If
the expanded PSN   
            tunnels fails to setup the PW MUST fail to setup.

The current wording is inconsistent in that the fail if no resource is
available and the alternative of attempt to increase tunnel capacity are
both "MUST."

I think that a proposal that Eric Rosen made on 4/7/05 should be added to
section 6.3, with my rewording to requirements style language proposed
below:

- The QoS processing at an S-PE SHOULD be done  using standard PSN tunnel
(e.g., MPLS) switching, queuing and traffic conditioning procedures, which
have no knowledge that they are functioning in an S-PE context.

Section 6.4 MS-PW Setup Mechanism

There has been a lot of discussion on the list of four protocols. Suggest
adding a statement that the addition of one or more other protocols for
MS-PW setup is not precluded to address this comment, otherwise the
requirements document is dictating the set of possible solutions.

There was a fair amount of discussion on the list regarding the need for the
protocol to support IP addresses as well as some other identifier. Suggest
breaking v into two parts to state these requirements more clearly.

		v. The MS-PW signaling protocol MUST support addressing
U-PEs and S-PEs 
               using IP addresses. This applies to use cases where
reachability to the IP 
               address of the U-PEs and S-PEs are known across potential
domains of the MS-PW.

		v'. In cases where the IP addresses of the U-PE and S-PE are
no known across 
                potential domains of the MS-PW (e.g., security and
confidentiality policies 
                prevent advertising IP reachability), procedures MUST be
provided to allow 
                dynamic setup of MS-PWs using some other identifier.

I am not clear as to what is intended by the following requirement:

       -vi. Addressing of MS-PW end point at the U-PE MUST be
            independent of the IP address of the U-PEs themselves.

If it means precluding the SS-PW use of IP address and PWid/GFEC for MS-PW
signaling, then I disagree with this requirement. I think that reworded
requirement v' handles this case for using non-IP identifiers to identify
(U-PE) endpoints.

Section 6.4.1 Routing

There was some discussion on the list in Jan/Feb 2005 regarding automatic
discovery of the S-PEs that are candidates for an MS-PW. Suggest that there
should be a requirement that states that automatic discovery of S-PEs is
desirable.

Section 8. Security Considerations

This appears to be completely new text, not yet reviewed by the working
group. Below are some initial comments.

I think that MS-PW also creates some additional security considerations for
intra-provider use cases, with details listed below. If these detailed
comments are accepted, then the summary statement that MS-PW intra-provider
security is equivalent to SS-PW security needs to be changed.

I note that these control protocol security requirements appear to apply
only to IP addressing.

8.1. Data-plane Security Requirements

First paragraph. Suggest stating that an S-PE is the point of an MS-PW
"crossconnect" (this is the first use of this undefined term in the
document) and that this is where injection (also suggest adding intercept)
could occur. Note that this case of S-PE injection/intercept can occur in
both intra- or inter-provider use case. 

Second paragraph. "Eavesdropping"  (suggest use of "intercept" instead) or
"hijacking" (suggest "redirecting" instead) could occur at an S-PE in both
intra- or inter-provider use cases. Also, an OAM continuity check style
mechanism may be able to detect redirection (hijacking) and suggest that
this possibility be added to the text. 

Third paragraph. I think that policing is already covered in the QoS
section. There is an issue of how to set the burst duration parameters of a
policer or implementing per-PW shaping such that packet clumping that could
occur does not result in some packets being declared non conformant at the
receiving S-PE that needs to be addressed in the document (but not in the
security section). Suggest that enabling policing (and shaping) be described
as a function that occurs via bialateral agreement in the inter-provider use
case. I believe that if the "security" concern is an interface overload DoS
style attack, then ingress policing on the S-PE at the inter-provider
boundary does not address this problem.

Fourth paragraph. I think that QoS treatment in terms of only allowing the
signaled QoS markings belongs in the QoS section, not the security section.
I believe that my proposed rewording of 6.3.1 i in the QoS section covers
this case.

Fifth paragraph. Defining label space does not seem to be a security
requirement. It would seem to fit better in section 6.4.

8.2. Control-plane Security Requirements

First paragraph. The problem being described here is unclear. Suggest that
the second sentence be reworded as follows: "It is important to make sure
that PW connections are not accepted only from an authenticated U-PEs,or
else a local attachment circuit might get connected to an incorrect remote
attachment circuit." 

Second paragraph. Suggest stating that the entities "peering" are U-PE and
S-PE. I can (mis?)interpret the text such that each U-PE and S-PE must be
configured with the list of all possible remote U-PE addresses (or
prefixes). I believe this is not a scalable solution. Another interpretation
is that such "peer" adress filtering is only for the signaling entities.
This would be more scalable. Suggest last sentence be reworded as follows:
"The S-PE and U-PE SHOULD drop any signaling messages that do not have an IP
address of a know MS-PW signaling peer to avoid a DoS attack on the control
plane." If routing is used for autodiscovery, then similar requirements
apply to routing protocol sessions.

Third paragraph. Suggest that scope is not only "connection request"
messages, but all control messages (signaling and routing). Suggest
clarification that source address filtering will block packets with
addresses of U-PE or S-PE from entering the target domain.

Fourth paragraph. Please clarify the following "Furthermore authentication
using a signature for each indifidual MS-PW setup messages MUST be
available, in addition to an overall control protocol session authentication
, and message validation." Does this apply to release and status messages as
well? Note that doing this level of authentication creates a DoS vector on
U-PE or S-PE processing resources such that an attacker can send a large
number of messages with invalid session as well as MS-PW authentication
values.

Fifth paragraph. I don't believe misconfiguration is a security issue (it
can also occur in an inter-provider context). If static manual configuration
protocols are not secured, then this would be less secure than a dynamically
signaled case where the signaling protocol exchanges are authenticated.
Suggest that the specific mechanism of a central server is not a
requirement. The means for end points being able to authenticate the
endpoints is an important security requirement. A requirement should not
state the form of a centralized solution, but should state the funciton
needed. A distributed mechanism could send a digest as part of a SAII/TAII
encoding.

Sixth paragraph. Good requirements. Suggest giving an example for the last
sentence (e.g., a TCP SYN attack if LDP is used).

Minor, Editorial Points
=======================
Suggest the title be "Multi-segment" instead of "Inter-Domain" Pseudo-wires
to align better with terminology in document. 

Text below Figure 2: Suggest using "PSN domain" instead of PSN to align with
earlier domain level terminology.

Section 6.2 Resiliency, requirement ii seems to be unecessary since the same
points are made in requirement i.

Section 6.2 Resiliency, requirement vii would seem to be better placed in
section 7, OAM. (It appears to be a duplicate of requirements vi and viii in
that section).

Section 6.3, delete "Class of Service" from section title - the term is
never used in the document. Suggest use of only "Quality of Service" and add
acronym "(QoS)" in section title.

Section 6.4.1, vi Suggest replacing "1:1" with primary/backup to have
consistent terminology.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> Sent: Thursday, June 16, 2005 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Pseudo Wire Emulation Edge to Edge 
> Working Group of the IETF.
> 
> 	Title		: Requirements for inter domain Pseudo-Wires
> 	Author(s)	: L. Martini, et al.
> 	Filename	: draft-ietf-pwe3-ms-pw-requirements-00.txt
> 	Pages		: 20
> 	Date		: 2005-6-16
> 	
>    This document describes the necessary requirements to allow a 
> service
>    provider to extend the reach of pseudo-wires across multiple 
> domains.
>    These domains can be autonomous systems under one provider
>    administrative control, IGP areas in one autonomous system, 
> different
>    autonomous systems under the administrative control of two or more
>    service providers, or administratively established pseudo-wire
>    domains.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-00.tx
t
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-pwe3-ms-pw-requirements-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE
> /internet-drafts/draft-ietf-pwe3-ms-pw-requirements-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3