Re: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Hi,

I support this work as an attempt to address the requirements set out in 
references [1] and [2]. I believe that it is *a* way to achieve a solution 
to the requirements using existing building blocks without needing to 
develop any new data plane or control plane features.

It is not clear to me why the insertion of an additional Ethernet header is 
required. But as portrayed in the figure, with the downstream interface of 
CE1 being an Ethernet interface *and* the client and server layer MPLS 
networks not coexisting on the same box, there is apparently no option. I 
would, however, draw your attention to the border peer model described in 
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt. in this model there 
would be no requirement to insert an additional Ethernet header into the 
flow.

I have a few comments on the text...

Adrian

===
Section 1
  "MPLS [RFC3031] is based on the ability to arbitrarily stack label
   switched paths (LSPs)."
Of course, it is clear to me what you mean, but this is not the language of 
RFC 3031. In 3031 it is the labels that are "stacked" (section 3.9). The 
LSPs are arranged as a hierarchy (section 3.27.4).
Can you clean up the language, please.
===
Section 1
   "Such stacked LSPs all belong to the same MPLS
    layer network."
Well, now!
Setting aside whether I agree or not (and I don't!) I don't think we have a 
definition of "layer network" conveniently to hand. Can you either reference 
it, or explain it.
===
Section 1
   "The limited isolation provided by this mechanism
   means that it is not possible to directly carry an LSP belonging to
   the MPLS network of party A over an LSP belonging to the MPLS network
   of party B in a truly transparent, functionally decoupled manner.  In
   other words, stacked LSPs do not intrinsically provide a client-
   server layer network relationship."
"Truly transparent" and "functionally decoupled" would be better replaced by 
a description of the problem that is seen. in other words, what is it that 
you cannot do because of this aledged issue?
What value does "intrinsically" add to this text? It seems to me to suggest 
that a client/server layer network relationship can be created using some 
technique and can use hierarchical LSPs, but that the use of heirarchical 
LSPs does not create the relationship. That would be just fine, wouldn't it?
===
Section 1
   "Several operators have identified this as a problem that requires
    urgent attention."
I think we can do without this assertion. It is the type of text brought in 
to justify the existence of an I-D, but adoption as a WG draft is enough 
proof of the acceptance of the problem, and this assertion jars.
On the other hand, if you were to explain why this is a problem (i.e. what 
the problem is) and why it needs urgent attention, then I think that would 
be a great help in reviewing this document.
===
Section 1 para 2
   "One solution to the problem..."
I don't think you have explained the problem.
===
Section 1 para 2
   "However, in
   this document we restrict our solution to using an Ethernet PW as
   defined in RFC4448 [RFC4448] ."
This is fine as an approach, and no-one can possibly object. But please be 
clear that you are not carrying MPLS over an MPLS network. You are carrying 
Ethernet over an MPLS network. That is, as in your figure, there is an AC, 
and that AC is an 802.3 conneciton, and the PW is an Ethernet PW that knows 
nothing about its payload.
So, as an applicability statement for solving a specific problem, your draft 
is fine, but maybe 10 pages too long?
===
Section 1 para 2
s/[RFC4448] ./[RFC4448]./
===
Section 1 final para
   "An IP or an MPLS Label Switched Path (LSP) must be established
   between CE1 and CE2."
Does this read "An IP Label Switched Path"? I don't think so. An IP *what* 
must be established between CE1 and CE2?
===
Seciton 1 final para
   "This MPLS PSN may utilize Penultimate-Hop
   Popping (PHP)."
Which PSN? You have not talked about a PSN so far; just an IP or an MPLS 
LSP.
===
Section 1 final para
   "This MPLS PSN may utilize Penultimate-Hop
   Popping (PHP).  This LSP is to be carried over Ethernet.  An Ethernet
   PW is provisioned between PE1 and PE2 and used to carry the Ethernet
   from PE1 to PE2.  The Ethernet PW is carried over an MPLS PSN, but
   this PSN MUST NOT be configured with PHP."

There are too many requirements and allowances wrt PHP without any 
explanations. The only other references to PHP in the I-D are in sections 
4.1 and 4.2 and are raw statements of procedural requirement without any 
derivation from funcitonal requirements.

So you need two things:
1. You need to explain the consequences of allowing PHP in the IP/MPLS PSN. 
That is, since in the example the penultimate hop is CE1, the MPLS packet 
sent from CE1 to CE2 may have no MPLS labels.
2. What are the functional requirements in the server MPLS PSN that lead you 
to state that PHP MUST NOT be configured. You should be able to do this with 
reference to specific requirements stated in [1] and [2].
(Hint: I am not disputing the deconfiguration of PHP, merely trying to get 
you to say why.)
===
Figure 1
s/<--MPLS PSN (no PHP)->/<--MPLS LSP (no PHP)->/
===
Section 2

This section defines a profile and so in a sense it is fine. But since you 
are making decisions about what features are allowed and what are not, it 
behoves you to say why. I suspect the reason is largely "because we have 
limited our scope to a particular problem space" (e.g. static 
configuration), but this problem space is not defined anywhere in the 
document.
===
Section 3
At what level is the OAM described operating?
Is this CE-CE OAM on the MPLS LSP, CE-CE OAM on the Ethernet, or PE-PE OAM 
on the MPLS LSP tunnel?
>From the references to PW, I assume that this is actually operating PE-PE on 
the PW.
Please clarify the text.
===
Section 4

"4.  MPLS Layer

   This section describes the profile of the MPLS RFC3031 [RFC3031] PSN
   .  The profile considers two cases:"

As clear as mud :-)
The figure describes two MPLS PSNs.
===
Section 4.1
Suffers the same problem as section 2.
The profile is fine, but the reasons for cuting this profile are absent.
Again, references to specifc requirements in [1] and [2] would be fine.
===
Section 4.2
Why is bidirecitonality not a requirement when it is required in section 
4.1?
===
Section 4.2
Why is P2MP not a requirement when it is required in section 4.1?
===
Section 4.2
   "o  Penultimate hop popping by the LSRs MUST be disabled on LSPs
      providing PWE3 transport network functionality."
In practice, what does this mean for the signaling protocols?
Or is this, in fact, an instruction to the egress LSR. If so, how does the 
egress LSR distinguish "LSPs providing PWE3 transport network functionality" 
from other LSPs?
===
Section 5
s/is applicable/are applicable/
===
Section 6
If this I-D is a profile of PW, it is also a profile of the security 
mechanisms for PW. So you must make some statement about which PW security 
mechanisms are applicable, and which must be used.
===

===
Section 8.1
VCCV is not at revision 14
===

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3