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

["Attila Takacs" <Attila.Takacs@ericsson.com>]

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: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Wednesday, October 29, 2008 8:48 PM
> To: ccamp@ops.ietf.org
> 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 
> 
> 
>