Re: [mpls-tp] WK Last Call on draft-ietf-mpls-tp-oam-requirements-02.txt

Hi all,
In draft-ietf-mpls-tp-oam-requirements-02.txt,
1. In section 2.1.3, two requirements are presented, the first says:
  "...IP routing and forwarding capabilities are inherently present in
  the forwarding  plane..."
the second says:
  "...IP routing and forwarding capabilities may not necessarily be
  present in the user plane. In this case, it MUST be possible to
  operate the OAM functions without relying on IP routing and
  forwarding capabilities..."
AFAIS, user plane is only used for user traffic forwarding, so no IP 
capabilities in user
plane does not necessarily preclude OAM (which is logically different from 
user traffic) with IP.
Therefore, "user plane" should be replaced with the same "forwarding plane", 
IMO.

2. In section 2.1.4, it says:
"...It is also REQUIRED that
   the two first requirements of Section 2.1.3 still hold..."
Maybe "first" should be deleted?

   Thanks
Jiang Yuanlong

----- Original Message ----- 
From: "Loa Andersson" <loa <at> pi.nu>
To: <mpls <at> ietf.org>; <mpls-tp <at> ietf.org>; <ccamp <at> ietf.org>; <pwe3 <at> ietf.org>; 
"Ross Callon" <rcallon <at> juniper.net>; "Adrian Farrel" <adrian <at> olddog.co.uk>
Sent: Monday, June 29, 2009 9:37 PM

Ethernet PW congestion control draft

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

Re: Ethernet PW congestion control draft

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

Re: Ethernet PW congestion control draft

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

Re: poll to make draft-andersson-mpls-tp-process-03.txt a working group document

Support. Ben

On 30/06/2009 15:19, "Loa Andersson" <loa <at> pi.nu> wrote:

> All,
> 
> we have an individual draft, draft-andersson-mpls-tp-process-03.txt,
> that describes additions to the mpls working group process to allow
> ITU-T to give input on MPLS-TP Internet Drafts.
> 
> It pretty much captures current practice, and from the start we had no
> intention to ever progress, but recently there has been comments that
> it would have a better and clearer sttus if it were a working group
> document.
> 
> We have had no plans to ever make it an RFC, but it has been pointed
> out that it would be possible to publish as an Historical RFC. Whether
> we execute on that or not is not yet decided.
> 
> Therefore, is is to start at two week poll on making
> draft-andersson-mpls-tp-process-03.txt an MPLS working group document.
> 
> The poll ends on July 14.
> 
> Please send your comments to the mpls-tp list.
> 
> Please
> 
> 
> 
> 

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document

	Support.

> Support. Ben
>
>
>
> On 30/06/2009 15:19, "Loa Andersson" <loa <at> pi.nu> wrote:
>
>> All,
>>
>> we have an individual draft, draft-andersson-mpls-tp-process-03.txt,
>> that describes additions to the mpls working group process to allow
>> ITU-T to give input on MPLS-TP Internet Drafts.
>>
>> It pretty much captures current practice, and from the start we had  
>> no
>> intention to ever progress, but recently there has been comments that
>> it would have a better and clearer sttus if it were a working group
>> document.
>>
>> We have had no plans to ever make it an RFC, but it has been pointed
>> out that it would be possible to publish as an Historical RFC.  
>> Whether
>> we execute on that or not is not yet decided.
>>
>> Therefore, is is to start at two week poll on making
>> draft-andersson-mpls-tp-process-03.txt an MPLS working group  
>> document.
>>
>> The poll ends on July 14.
>>
>> Please send your comments to the mpls-tp list.
>>
>> Please
>>
>>
>>
>>
>
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

I-D Action:draft-ietf-pwe3-fat-pw-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.

	Title           : Flow Aware Transport of Pseudowires over an MPLS PSN
	Author(s)       : S. Bryant, et al.
	Filename        : draft-ietf-pwe3-fat-pw-00.txt
	Pages           : 18
	Date            : 2009-07-01

Where the payload carried over a pseudowire carries a number of
identifiable flows it can in some circumstances be desirable to carry
those flows over the equal cost multiple paths (ECMPs) that exist in
the packet switched network.  Most forwarding engines are able to
hash based on label stacks and use this to balance flows over ECMPs.
This draft describes a method of identifying the flows, or flow
groups, to the label switched routers by including an additional
label in the label stack.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

[Fwd: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch]

From: Adrian Farrel <adrian.farrel <at> huawei.com>
Subject: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch
Date: 2009-07-02 11:31:20 GMT

Discuss:
I appreciate the work that has gone into this document, but I believe it needs some more polish.

===
Section 1.1

It is not clear to me that the first motivation (which seems the 
most realistic of the motivations) naturally leads to multisegment
PWs when the PSN tunnels can themselves be aggregated and tunneled
using standard features of MPLS-TE.

The other motivations require some form of planning/routing decisions
in what we might call the PW layer. These techniques do not yet
exist and would need to be invented and developed. However, inter-
domain MPLS-TE already exists and is proven in deployments. Why 
would you not continue to use single segment PWs while making the
multi-domain and aggregation decisions within the MPLS-TE LSPs?

(The same argument applies to IP-in-IP tunnelling.)

The only argument I can see in favor of your technique to address
these motivations is that you can support different PSN tunneling
techniques in different domains. Obviously, this does not apply
for the first of your three motivations as there is only one
domain. In the other two cases, I suggest that the arrangement in
figure 2 would normally allow tunnelling of the access technology
tunnels over the core technology tunnel. That leaves only the 
case of peer domains with different tunnelling technologies.

You seem to be inventing a lot or architecture for a small set of 
deployments
===
I am concerned that you are not separating two distinct cases.
Where the PSN technology is the same, and the PW encapsulation is
the same, you are truly switching. You have just two layers to
worry about.

Where the PSN technology chnages and there is a change in 
encapsulation there is a bigger question. You are not switching PW
segments, but you are ending one encapsulation and begining a new 
one. This is the "translation" you describe in Section 3.2.
Translation or gateway functions are neither elegant nor scalable
with an increase in tunneling technologies, and I note that you
have hidden/ignored this problem in Figure 7.
Architecturally, there are only two ways to handle this:
1. You emerge from the first encapsulation into the client (i.e.
   payload) layer, swtich in that layer, and re-encapsulate for
   the next PW segment.
   I suspect you don;t want to do this as it requires you to
   install L2-capable switching equipment at the switching points.
2. You insert a thin transport-agnostic PW layer between the client
   layer and the PW encapsulation layer.
===
Section 1.3

It seems that the terminology is tied in some knots!
An S-PE would be the perfect term except that in motivation 1 you
have stitching within a domain, and in motivation 2 you may be
stitching at ABRs (which are not PEs). 
So, in the middle of the terminology section you use "PW Switching
Point" without any definition.
Indeed, the convolutions are such that you have...
      A S-PE can exist anywhere 
      where a PW must be processed or policy applied. It is therefore 
      not limited to the edge of a provider network.
That is: "A provider edge is not limited to the edge of a provider
network." Clearly a problem!

You need to introduce the term "PW Switching Point" and recast the
whole document in terms of PW Switching Points and not S-PEs.
===
Section 3 is very important.
It is good to see that you have made the architectural separation
between the PW layer and the PSN layer.
You introduce a concept "The design of PW routing domains..." which
is very significant, but you don't discuss it at all in the rest of
the document (you vaguely touch on it in Section 9.1).
Since you have introduced the concept of a PW routing domain, you 
must discuss its architecture and operation.
Saying in Section 3.1 that:
   The selection of which set of S-PEs to use 
   to reach a given T-PE is considered to be within the scope of MS-PW 
   solutions.
...is dodging the issue too much. In an architecture you must say 
what functions you require for operation and on parameters you 
expect these functions to act.

Tucked away in the text of Section 3 is an assumption that IP
reachability and tunnel reachability (e.g. MPLS-TE reachability) are
synonymous. They are not.
===
An "interesting" wrinkle.
In RFC 3985, the PW segment is considered to run from the input 
interface of the ingress PE to the output interface of the egress PE.
This clearly continues to apply for the T-PEs, but it is not clear in
your figures what happens at S-PEs. For example, in Figure 4, it is
unclear where the PW segments start and end.
Obviously, this is intended to be at "the switcing point" but you
don't make this clear, and extrapolation from 3985 would lead someone
to assume that the first segment ended at the outgoing interface of 
the first S-PE.
===
Section 6 says

   Where the encapsulation format is different e.g. MPLS and L2TPv3, the 
   payload encapsulation may be transparently translated at the S-PE. 
But 8.2 says that an S-PE may introduce fragmentation.
This is good, but is not a transparent translation of encapsulation.
===
Section 9.1 is confused about "dynamically chosen" and "signaled".

Possibly,
   For the signaled case, there are two options for selecting the path 
   of the MS-PW: 
should read
   For the case of dynamic choice of PW switching points, there are two
   options for selecting the path of the MS-PW: 

===
In Section 9.2

   Since a multi-segment PW consists of a number of concatenated PW 
   segments, the emulated service can only be considered as being up 
   when all of the constituting PW segments and PSN tunnels (if used) 
   are functional and operational along the entire path of the MS-PW. 

I think this is the first time you have suggested that PSN tunnels
might not be used.
===

Comment:
Introduction
   The PW passes through a maximum 
   of one PSN tunnel between the originating and terminating PEs.
I'm not sure that this limitation is made in RFC 3985. I don't
believe that there is anything that prohibits LSP stitching to make
a "multi-segment LSP tunnel" that carries a single segment PW.
===
Section 1.1

You suggest that the solution helps to reduce the scaling issues
at PEs and P nodes. But doesn't the stitching PE have a signficant
scaling problem?
===
Section 2

   As well as supporting traditional L2VPNs, an MS-PW is applicable to 
   providing connectivity within a transport network based on packet 
   switching technology e.g. MPLS Transport profile (MPLS-TP) [6].

s/within/across/

I don't think [6] is the best reference for MPLS-TP. You would do
better to point at draft-ietf-mpls-tp-requirements and 
draft-ietf-mpls-tp-framework
===
Section 4

   Note that 
   although the S-PE path is therefore reciprocal, the path taken by the 
   PSN tunnels between the T-PEs and S-PEs may not be reciprocal due to 
   choices made by the PSN routing protocol. 
s/may/might/ !!!
But this is an odd thing to say. Why do you require the S-PEs to be 
reciprocal, but not the tunnels? Are you sure your architecture is not
being driven by your solutions?
===
Section 9.2

   RFC 3985 describes the need for failure and other status notification 
   mechanisms for PWs. These considerations also apply to multi-segment 
   pseudowires. In addition, if a failure notification mechanism is 
   provided for consecutive segments of the same PW, the S-PE must be 
   able to propagate such notifications between the consecutive 
   concatenated segments.   
This looks like a requirement hiding in the wrong document! Is it?
===
idnits says
 ** You're using the IETF Trust Provisions Section 6.b License Notice
    from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, 
    which is required now. (See http://trustee.ietf.org/license-info/)
===
Nits

Abstract
s/same providers PSN/same provider's PSN/
---
Section 8.1
Expand NSP on first use.
---
Section 11
   Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk
   01.txt, or its successor, prior to publication. 
Ready to be fixed now?
---
Section 11
s/However, this may not effective/However, this may not be effective/
---
I would prefer the references section to be named "Normative References
if they really are all normative.
---
Your references are out of date.

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

Re: [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

a question of draft-ietf-pwe3-fat-pw-00

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3