Re: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt

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

Hi,

Some thoughts in addition to Attila's comments...

===
Abstract
Can you please expand acronyms (as will be required by the RFC Ed.)
I see...
SONET
SDH
TDM
ATM
GMPLS
===
Main body of the document.
Each acronym needs to be set out in full the first time it is used.
I see...
SONET
SDH
TDM
ATM
IEEE
ITU
MEF (transfer from later use)
GMPLS
VLAN (transfer from later use)
===
Please be consistent with the use of a space in either "IEEE 802" or 
"IEEE802"
The space looks better to me.
===
Section 1
OLD
procedures that will need to be changed is dependent
NEW
procedures that will need to be changed are dependent
===
Please be consistent "bidirectional" or "bi-directional"
I prefer "bidirectional" and you only use "unidirectional"
===
Section 2.3.1
OLD
     o Asymmetric Bandwidth

       This term refers to the property of a Bi-directional LSP may have
       differing bandwidth allocation in each direction.
NEW
     o Asymmetric Bandwidth

       This term refers to a property of a bidirectional LSP that may have
       differing bandwidth allocation in each direction.
===
Section 2.3.1
OLD
     o Bi-directional Congruent LSP

       This term refers to the property that an LSP shared the same
       nodes, ports and links. Ethernet data planes are normally bi-
       directional congruent.
NEW
     o Bidirectional Congruent LSP

       This term refers to the property of a bidirectional LSP that uses
       only the same nodes, ports, and links in both directions. Ethernet
       data planes are normally bidirectional congruent.
===
Section 2.3.1

     o Shared forwarding

       Shared forwarding is a property of a data path where a single
       forwarding entry (VID + DMAC) may be used for frames from
       multiple sources (SMAC). Shared forwarding does not change any
       data plane behavior it saves forwarding information base (FIB)
       entries only. From all other aspects it behaves as if there were
       multiple FIB entries.

I don't understand the last sentence. Since there is only one FIB entry, the 
behavior cannot be as if there were multiple FIB entries. I suggest you 
either strike this sentence or add an example of what you mean.
===
Section 2.3.1
     o Hierarchical Eth-LSP

       Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and
       tunneled, either individually or bundled, with other LSPs through
       a domain.

I don't like this definition of hierarchical! Normally, we refer to the 
hierarchical LSP as the LSP that is the tunnel, not the LSP that is 
encapsulated. I think it would be helpful to remain consistent with RFC4206.
===
Section 2.4 etc.
Please capitalise section headings
===
Section 2.4
   Ethernet is similar to MPLS in that there is a default payload type.
   In MPLS, the default payload is either another MPLS label or an IP
   packet. The IP packet may carry any type of service IP carries.
   Ethernet assumes an Ethernet frame as the default payload. The actual
   service can be anything that Ethernet carries.

I find this paragraph pretty weird!
- What do you mean by a "default payload". Try telling the PWE3
  working group that LSPs carry either another MPLS label or an
  IP packet!
- How can "the default" payload be either one thing or another?
- In what way does Ethernet assume that the default payload of
   Ethernet is also Ethernet? When would that assumption stop?
   It sounds arbitrarily recursive!
It might help if you explained what value there is to knowing the default 
payload type. If there is no value *to* the*work*we*are*doing* in this 
document, then why bother mentioning it?
===
Section 2.4
   Ethernet bridging is different from MPLS in that while the switching
   decision is taken on whatever is defined as the Ethernet label, that
   label is usually not swapped at each hop.

"Usually"?
Note that in MPLS you can use the same label on incoming and outgoing 
interfaces, but because the label could be swapped, we implement a swapping 
mechanism in all cases.
Now, "usually" implies that sometimes the label may be swapped. This has 
significant implications for implementation.

Perhaps you need to clarify this paragraph quite a bit. It might also help 
to discuss the context of the label. MPLS label contexts fall into three 
categories:
- node
- link
- upstream neighbor
What can you say about Ethernet?
===
Section 3
You list
   - priority level;
   - preemption characteristics;
How are these different?
===
Section 3
Remove spare blank line between last 2 paras
===
Section 1 and Section 4.1
Please add a reference where you name LMP
===
Section 5
I think you should reference RFC3473 alongside RFC3471
===
Section 5
OLD
   Signaling enables the ability to
   dynamically establish a path from one ingress or egress node.
NEW
   Signaling enables the ability to
   dynamically establish a path from an ingress node to an
   egress node.
===
Section 5
   Given this, Eth-
   LSPs MUST always use paths that share the same routes and fates.
I believe you have defined a term specially for this?
===
Section 5
   Eth-
   LSPs may be either P2P or P2MP (see [RFC4875]).
You should probably add that only unidirectional P2MP Eth-LSPs are 
supported.
===
Section 5
   Note that standard GMPLS does not support different bandwidth in each
   direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric
   bandwidth bidirectional LSPs are required.
Suggest you change to
   Note that GMPLS as originally defined in [RFC3471] and [RFC3473] does
   not support...
===
Section 8
   More detail will be added to the section in a later revision.
You are running out of time :-)
===
Section 9
OLD
   the ports over which a UNI is defined is trusted
NEW
   the ports over which a UNI are defined is trusted
===
Section 9
This section is a bit sparse.
You should add a reference to 
draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04)
You should describe why the change in data plane type does not impact the 
control plane security.
You should mention the difference between in-band and out-of-band control 
planes in the Ethernet network since in this case, the data plane type does 
impact security. In particular, the in-band control plane can be used to 
attack the data plane capacity, and access to the data plane can be used to 
attack the control plane.
===

Thanks,
Adrian

PS. When you submit the updates, please use the new boilerplate and use 
idnits to verify everything.

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, October 29, 2008 7:47 PM
Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt


> This email starts a two week working group last call on "GMPLS Ethernet 
> Label Switching Architecture and Framework"
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
>
> The I-D is marked as Informational.
>
> Please send your comments to the list by 12 noon GMT Friday 14th November.
>
> Thanks,
> Adrian and Deborah
>
>