[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
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" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
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