[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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). 
===