[CCAMP] AD review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-04

[Adrian Farrel <[e-mail]>]

Hi,

Don't panic!

I have done my AD review of your document. I have quite a large number of 
fairly minor editorial gripes, and a couple of technical questions that I 
think you should address before we move the document forward. This will 
result in a better document and a smoother course through IETF and IESG 
review.

All my issues are open for discussion - nothing is mandatory.

I will move the document into "Revised I-D needed" state in the data 
tracker.

Thanks,
Adrian

---

Please remove citations from the Abstract.
It is OK to mention the documents by name (e.g. "RFC 5828") but not to give 
references. (The Abstract is standalone information.)

---

Section 3

   GMPLS is being defined here to establish ESPs and TESIs. As it can be
   seen from the above this requires configuration of both the I and B
   components of the IB-BEBs connected by the ESPs.

 Perhaps an overstatement? :-)
I think either:
  This document defines the applicability of GMPLS to establish...
or
  This document defines extensions to GMPLS to establish...

 ---

 Figure 2

 The word "ports" seems to be aligned wrong

 ---

 Section 3.1

 s/Path Computation Server/Path Computation Element/

 ---

 Section 3.2

 Please capitalise the seciton heading

 ---

 Section 3.2

   The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding
   identifier or label consisting of some number of P2P connections
   distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- MAC SA
   tuple. This is analogous to an LDP label merge but in the shared
   forwarding case the original ESP header still identifies the complete
   path.  Resources can continue to be allocated per LSP with Shared
   forwarding.

 Isn't this a bad choice of the word "path" since this (expecially in 
association with "complete" tends to imply a route. And "original" in what 
context?

 I think you might use...
 ...case the ESP header contians sufficient information to identify the flow 
to which a packet belongs.

---

 Section 3.2

   It is a local decision of how
   this is performed but the best choice is a path that maximizes the
   shared forwarding.

 Does "local decision" mean "implementation decision" or is it supposed to 
be a configurable thing or policy driven?

What is meant by "maximize shared forwarding". Actually, isn't the objective 
to reduce forwarding table entries. So any shared entry is good enough.

You seem to be introducing a new requirement to get as much traffic as 
possible through the same forwarding entry.

Can you add some text or modify what you have to clarify these points

---

 Section 3.2

   The concept of bandwidth management still applies equally well with
   shared forwarding. As an example consider a PBB-TE edge switch that
   terminates an Ethernet LSP with the following attributes: bandwidth
   B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an
   additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D,
   ESP-MAC SA S2, ESP-VID V) can be accepted provided there is
   sufficient link capacity remaining.

 I find this example quite hard to follow.

 My suggestion is to either remove the example, or to fill it out with a 
figure.

Why do you use an edge switch in your example? That seems to add to my 
confusion.

---

 Section 4.1.1

   Where individual paths in a protection group are modified, signaling
   procedures MAY be combined with Protection Switching (PS)
   coordination to administratively force PS switching operations such
   that modification is only ever performed on the protection path.

 I think you need a reference for PS.

 ---

 Section 4.5

 I think you are missing a chunk of text. I think I can see how the 
CALL_ATTRIBUTES are used in accordance with RFC4974, but there really is 
nothing more than a reference to RFC4974 in step 6) or Seciotn 4.1.

I can't find any explanation of the use of LSP_ATTRIBUTES. No reference to 
RFC5420, and no mention of how the object might be used.

How do the authors propose for these objects to be used, and how did the WG 
assess the protocol extensions?

Can one LSP be associated with multiple I-SIDs?
What does it mean for a Call to be associated with multiple I-SIDs?

 The inclusion of a field for flags with none defined might be excusable, if 
you had some spare bits, but you don't. Why don't you strike this and 
include an options sub-TLV is necessary in the future?

Presumably if Action == range then excatly two I-SIDs must be present in the 
sub-TLV.

This section worries me a fair bit. It feels like the absence of an 
implementation is a bit telling. I find myself wondering whether the I-D 
should actually be published as Informational or Experimental "as a basis 
for future standards track work" I would feel a lot more comfortable if this 
section was more robust.

---

 Figures 4 and 5

 There seem to be some minor alignment problems with vertical pipes. Someone 
been using tab stops?

---

 Section 5.1.1 is a bit woolly!

 Starting with Seciton 5.1

   The network operator administratively selects a
    set of VLAN Identifiers that can be used to setup ESPs.
   Consequently, any VID outside the allocated range is invalid and an
   error MUST be generated where the mismatch is discovered.

 It is unclear is this is a data plane, management plane, or control plane 
error.

In 5.1.1: which message might give rise to the error? which message is used 
to carry the error?

---

 Section 5.1.2

 What was wrong with using an existing sub-code such as 9?
BTW, 35 is already allocated.

 ---

 Section 6

 This section is not going to get past the Security Directorate!

 - It will help to refer to 
draft-ietf-mpls-mpls-and-gmpls-security-framework

- "The commonly known techniques..." will need references

- The statement that all devices in the domain are trusted will raise 
eyebrows especially give the pug and play nature of Ehternet and the 
relative ease of packet insertion via the data plane.

 - "Care is required to ensure untrusted access to the trusted domain does 
not occur" needs at least some guidance on what care might be  taken

 - It seems to me that you are allowing the control plane to set up a 
different forwarding paradigm from the one we are used to. Since  the 
forwarding plane is more easily (differently) subverted than the management 
plane, surely you are introducing risks that have never even been thought 
about.

---

 Section 8.1

 Please include file name (draft-ietf-ccamp-gmpls-mln-extensions) for 
[MLN-EXT] to remove downref warning.

---

 Section 8.2

 Please fix up the references to
 [IEEE 802.1ay] should be [IEEE 802.1Qay]
 [IEEE 802.1ah] should be [IEEE 802.1Qah]

 Please remove unreferenced items.
 [IEEE 802.1ag]
 [Y.1731]

---