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

From: "Attila Takacs" <[email-masked]>
Date: Tue, 11 Nov 2008 09:41:39 +0100

Hi all,
Some comments on the draft, mostly editorial.
Best regards,
Attila

-Move the abbreviation section (2.3.2) in the beginning of the document.
I would consider moving the whole terminology section (2.3) forward.

-Page 3, delete "Document History"

-Page 3, Introduction, last sentence of second paragraph, change "but
not an explicitly" ->"but not on explicitly"

-Page 3, Introduction, 5th paragraph: add a new reference to 802.1ad and
reword the first sentence

-Page 4, last paragraph change: "This document introduces and explains
the concept of an Ethernet
   Label Switched Path (Eth-LSP)." -> "This document introduces and
explains GMPLS control plane deployment for Ethernet and the concept of
the Ethernet Label Switched Path (Eth-LSP)."

-Page 5, Background, second paragraph, first sentence change: "this
section is based on the on-going work" -> "this section is based on both
finished and on-going work"

-Page 7, bullet on I-tagged interfaces, change second sentence: "An
I-Tag contains a service identifier (24 bit I-SID) and priority
     markings as well as some other flags." -> "An I-Tag contains a
service identifier (24 bit I-SID) and priority
     markings as well as some other fields."

-Page 7, first paragraph after the bullet list, change: "In general, the
different switching type determines" -> "In general, the switching type
determines" and "The type may also" -> "The switching type may also"

-Page 7, last paragraph, delete: "For the Eth-LSP unicast mode of
behavior, the hardware performs unicast packet forwarding of known MAC
addresses leveraging existing Ethernet forwarding."

-Page 8, OAM, last paragraph, reword to: "Both Y.1731 & 802.1ag assumes
that bidirectional transactions (e.g., LBM/LBR) use the same VID in both
directions. However in some scenarios, especially with explicitly routed
paths [802.1Qay], it is possible that different VIDs are used upstream
and downstream. In the context of [802.1Qay] work is ongoing to update
[802.1ag] to support such scenarios." 

-Page 8, Bi-directional Congruent LSP, typo, "LSP shared" ->  "LSP
shares"

-Page 8, Shared forwarding: add at the end: "In contrast to merging
where control plane states as well as forwarding entries are merged,
with shared forwarding dedicated states for all Eth-LSP are maintained
regardless of shared forwarding entries."

-Page 8, add the definition of Eth-LSPs: "Eth-LSP: This term refers to
Ethernet service paths that are controlled via GMPLS."

-Page 10, Framework, first sentence: remove parenthesis around GMPLS

-Page 12, first paragraph reorder to read: "...This valid MAC checking
and broadcast supports Ethernet learning. A special case is when a VID
is
   defined for only two ports on one bridge, effectively resulting in a
p2p forwarwading constraint, in this case all frames
   tagged with that VID received over one of these ports are forward
over the
   other port without address learning. <new paragraph> [802.1Qay]
allows for turning off learning and hence the broadcast mechanism
providing means to create explicitly routed Ethernet connections."

-Page 16, section 8, delete last sentence "More detail will be added to
the section in a later revision." and/or add further details :-)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, October 29, 2008 8:48 PM
> To: [email-masked]
> 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-eth
> ernet-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 
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Nov 2008 11:34:09 -0000

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" <[email-masked]>
To: <[email-masked]>
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
>
> Please send your comments to the list by 12 noon GMT Friday 14th November.
>
> Thanks,
> Adrian and Deborah
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Nov 2008 20:59:16 -0000

Authors,

You received some comments.
Mainly editorial.

The sooner you post a revision, the sooner it will go forward.

Thanks,
Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 17 Nov 2008 00:09:21 +0100

hi adrian

reading this doc. the section 2

 2      Background  ................................................   5
 2.1    Ethernet Switching  ........................................   5
 2.2    Operations, Administration, and Maintenance (OAM)  .........   7
 2.3    Terminology  ...............................................   8
 2.3.1  Concepts  ..................................................   8
 2.3.2  Abbreviations and Acronyms  ................................   9
 2.4    Ethernet and MPLS similarities and differences  ............  10

as it names indicates provides Ethernet background info while i thought
the doc. was meant to deal with protocol architecture issues. of course
there is a relationship but these sections should better be included in
an appendix or so. The sentence "Ethernet is similar to MPLS in that
there is a default payload type." i missed the def. of a payload type in
RFC3031.

Section 2.3 should also be made separate from this background
information on Ethernet techno itself. 

Section 6 reads as a recommendation on protocol usage not on
architecture e.g. "It is RECOMMENDED that LMP not be used for Fault
management and instead the native Ethernet methods be used." I am not
sure to see why an IETF document shall preclude usage of its own
protocols except if there is a good reason for (use of LMP on shared
medium is tedious since on CC shall be setup between each node).

Other comments:

" Extensions to support non-IP based LSP identification in signaling,
i.e., replacement of the IP address in the RSVP SESSION or SENDER_TSPEC
objects, are not permitted under this framework."

-> Well i would phrase this in the other way around "Support of Ethernet
MUST strictly comply to the GMPLS protocol suite addressing as specific
in RFC3471, RFC3473 and related."

"This document allows for the support the signaling of Ethernet
   parameters across multiple domains"

-> How do you define the term domain in the present context ? is it
related to the Ethernet partitioning and/or segmentation in
client/provider MAC address space ?

thanks,
-d.

> Sent: Friday, November 14, 2008 12:34 PM
> To: [email-masked]
> Subject: Re: Two week last call on 
> "GMPLS Ethernet