Re: [mpls-tp] Early version of revised ITU-T Recommendation G.7712 including MPLS-TP

["Adrian Farrel" <[e-mail]>]

Hi Dieter,

Thanks for sharing this.

Comments below are intended to help the drafting process and reach 
consesnsus more smoothly.

Thanks,
Adrian

---

It looks like you've found and flagged nearly all the points where T-MPLS 
needs to be changed to MPLS-TP.
I think it is as simple as, for example,

OLD
This 2008 revision of the Recommendation adds the requirements of the OTN 
ECC data-link layer termination function and the transport MPLS (T-MPLS) SCC 
data link layer termination function.
NEW
This 2010 revision of the Recommendation adds the requirements of the OTN 
ECC data-link layer termination function and the MPLS transport profile 
(MPLS-TP) SCC data link layer termination function.

---

G.8121 is also listed in the References and will need to be updated.

---

[IETF gach-dcn] can now be updated as:
OLD
[IETF gach-dcn] IETF Internet Draft draft-ietf-mpls-tp-gach-dcn-05.txt, An 
Inband Data Communication Network For the MPLS Transport Profile 
<draft-ietf-mpls-tp-gach-dcn-05.txt>
NEW
[IETF RFC 5718] IETF RFC 5718 (2009), An Inband Data Communication Network 
For the MPLS Transport Profile 
http://www.ietf.org/rfc/rfc4443.txt?number=5718.

---

[IETF tp-cp-frwk] doesn't seem to be referenced, which is in as expected. So 
you can probably remove it from the References section.

---

Section 7.1.1

> (e.g., [ITU-T G.783] (SDH), [ITU-T G.798] (OTH), [ITU-T G.8021]
> (Ethernet transport), and [ITU-T G.8121] (transport MPLS))

Since these are examples, it may be easiest to change:

OLD
(e.g., [ITU-T G.783] (SDH), [ITU-T G.798] (OTH), [ITU-T G.8021] (Ethernet 
transport),
and [ITU-T G.8121] (transport MPLS))
NEW
(e.g., [ITU-T G.783] (SDH), [ITU-T G.798] (OTH), [ITU-T G.8021] (Ethernet 
transport),
and MPLS-TP)

---

Section 7.1.2.3.1

> When a shared trail SCN link is used, MPLS-TP cannot run in parallel with
> an IP (or other network layer network) user data plane over the same non-
> MPLS server layer trail.

I don't agree with this.
If you are saying this because you believe it to be a technical "cannot" 
then I think it is perfectly fine to send SCN IP packets addressed to the 
(e.g.) signaling controller and use this to distinguish the packets from 
others that should be forwarded or locally terminated.
On the other hand, if you are saying that this is functional limitation, 
then you need "must not" and (of course) you need to provide a reference.

---

7.1.2.3.2

You have:
   This dedicated MPLS-TP trail cannot be used for user plane traffic

I think you need "must not" instead of "cannot".
If I recall OIF interop events, it is all too easy for user traffic to find 
its way onto the SCN!

---

7.1.2.5.1

You have:

   The layer-2 code-points (L2CPs, e.g., the EtherType field in case of an 
Ethernet
   PHY or the UPI field in case of GFP-F) are used to distinguish between 
the
   MPLS-TP LSPs, the MPLS-TP OAM forwarding including the MCC, and the
   packets destined for the SCC IP forwarding point or the SCC OSI 
forwarding
   point.

This doesn't look right to me. We *do* distinguish native IP, OSI, and MPLS 
packets using L2 code points. We do not distinguish the content/use of those 
packets (user data, OAM, MCC, SCC) using L2 code points.

And then:

   User traffic MPLS-TP LSPs (shown for the sake of completeness):

I understand the completeness motivation, but user traffic is clearly out of 
scope of this Recommendation. Including any definitions here risks creating 
a second normative definition. Since the material is covered elsewhere, I 
suggest either completely dropping it, or inserting a Bibliographic 
reference.

---

7.1.15

I believe that most (all?) of this section is out of scope. The document is 
supposed to define the scope for the DCN. This section seems to try to 
define the operation of control plane signaling protocols and functions. We 
have plenty of work in both the IETF and the ITU-T on the control plane, and 
the details of the control plane operation will be specified in MPLS-TP 
RFCs.

If it is necessary to set up MPLS-TP LSPs to establsh DCN connectivity, then 
this text should be generalized simply to say that the techniques used for 
LSP establishment may be used to set up such LSPs.

---

7.1.17

This looks very close to being out of scope. I guess that the DCN *might* 
require a path computation function.

---

7.1.19

This section is way out of scope!

---

7.3

This section looks rather empty!
Are there really no other security requirements for the DCN?
I thought SG17 had something to say on this topic.

---

Annexes

I know this material has been in 7712 for a while, but I am hugely worried 
by the fact that it is neither relevant to this document nor consistent with 
the IETF's copyright grants. I also believe that modifications to IETF 
protocol specifications should be conducted within the IETF.

Discussion of this point is probably *way* outside the MPLS-TP discussions 
and I would welcome a private discussion with your Rapporteur about how we 
can resolve this issue.