Subject: Thoughts on draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 27 Apr 2008 13:24:35 +0100

Hi,

Here are some thoughts on your draft.

Cheers,
Adrian

===
Title/document name
You have the broad title "GMPLS control of Ethernet" yet the document is 
named draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt.
I think that, as per the Abstract, you are limiting yourselves to 802.1Qay, 
and that is fine.
So you should retitle the document "GMPLS Control of 802.1Qay Ethernet 
Networks" or something like that.
===
Author list
Before this goes to become an RFC you will have to reduse the front page 
listing to no more than 4 names.
I suggest that you do this by placing only the editors on the front page, 
but continuing to list all of the authors in the "Authors' Addresses" 
section.
===
Abstract
s/the standard IEEE data/the standard IEEE data plane/
===
Document History
I think you could delete this now.
Or move it to an Appendix if it is important to you.
===
Section 1
s/by a another/by another/
s/aligned with GMPLS/aligned with the GMPLS/
s/plane and the PBB-TE forwarding/plane and PBB-TE forwarding/
===
You might add a sentence or two to the Introduction explaining why GMPLS is 
relevant. Something like...

Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols 
designed to operate in connection oriented and traffic engineering transport 
networks. GMPLS is applicable to a range of network technologies including 
Layer 2 Switching capable networks (L2SC).
===
Section 1
You have:
   Appendix A summarized the rational for this data plane
   technology until the IEEE specification is more mature.
It is your intention that Appendix A will be removed becuase 802.1Qay 
explains the facts in enough detail? I would support that. We do not need to 
redocument IEEE work.
Do you think that the work in IEEE is there yet?
===
Section 2
s/Ethernet Label switched Path/Ethernet Label Switched Path/
===
Section 2.1
ESP:
You have "between two or more CBPs" People will understand "between two 
CBPs" but may need help to understand "more".
s/Ports(CBPs)/Ports (CBPs)/
s/(MSTI)(A set/(MSTI). (A set/
s/of MSTIs)./of MSTIs.)/
s/an GMPLS/a GMPLS/
===
Section 2.1
PBB-TE Region
Not sure I like this term. RFC 3945, RFC 4206, and the MLN Requirements I-D 
have a definition of region.
Is "PBB-TE Region" an IEEE term?
Does it map to layer or domain in GMPLS?
===
Section 2.1
Point-to-Multipoint PBB-TE service instance
s/multipoint ESP/point-to-multipoint ESP/

s/leaves/branches/ ... or ...
You might prefer to say that the n P2P ESPs are co-routed but in the oposite 
direction from the source-to-leaf sub-ESPs comprising the P2MP ESP.

There is no such thing as a P2MP GMPLS bidirectional tree until you define 
one later. So this terminology at least needs a forward pointer.
===
Section 3
Please capitalise the section heading
===
Section 3
Suggest you replace "[see Appendix A]" with "see [IEEE 802.1Qay]". You could 
also retain a reference to Appendix A, but see the previous discussion.
===
Section 4.1
s/Ip_Source_Sddr/Ip_Source_Addr/

  "From a GMPLS control plane point of view
   an Ethernet LSP MAY also be identified as any other LSP"
What do you mean "MAY"? Surely this is "is".
===
Section 5.1
"This may be any switch along the path."
This may be *originated by* any switch along the path?
===
Section 5.2
s/then node/the node/
Don't you need to be able to distinguish whether it is a source or dest 
address that has caused the problem?
===
Section 5.3 and 5.4
s/discontinuities/discrepencies/   ???
I'm not sure about these error cases, and I don't find a description in the 
body of the text (did I look ahard enough?).
The error codes sounds like you are suggesting that an LSR (i.e. switch) 
that receives a Path message will check the information in the ERO against 
the informaiton in the Upstream-Label and Label-Set objects. But...
- the hop information is stipped from the ERO before the Path is sent
- we shouldn't have duplicate information in our data elements
- the LSR should not "look ahead" in the ERO in any way different from the 
process described in RFC3209.
===
Section 7
I think a good deal of work is needed on this section.
Possibly some more work is needed in 
draft-ietf-ccamp-gmpls-ethernet-arch-01.txt as well.
All you have done here is lift the text from the architecture document.
You need to consider...
- I don't find any reference in the rest of your document to UNI ports
- "Commonly known techniques" should have references
- You should reference draft-ietf-mpls-mpls-and-gmpls-security-framework
- What care should be taken to protect the trusted domain from untrusted 
access?
- What happens if legacy Ethernet control plane techniques are enabled in 
the GMPLS controlled network?
- What happens if Ethernet frames are injected into the network? It would 
appear that PBB-TE has many of the same vulnerabilities in this regard as 
Ethernet and IP. How does the network protect against this? Does GMPLS 
contribute to the protection?
- Do the error codes described in section 5 provide a way to use GMPLS to 
probe the network and discover the configuration of core nodes?
===
Manageability
With the introduction of a new technology to the GMPLS family, I think it 
would be worth your draft discussing the manageability of a GMPLS controlled 
PBB-TE network. What features do you require from GMPLS? How do you debug 
GMPLS established ESPs, and how do you debug the GMPLS control plane itself? 
Some of this may be by reference to existing or soon-to-be-created 
documents. (Notwithstanding section 4.5).
===