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

["PAPADIMITRIOU Dimitri" <[e-mail]>]

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.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Friday, November 14, 2008 12:34 PM
> To: [e-mail]
> Subject: 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" <[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-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
> >
> > 
> 
> 
>