Hi,
Just a few thoughts.
Cheers,
Adrian
===
Obviously, you'll need to use the new IPR boilerplate.
===
Abstract
This document
supports the types of switching required to implied by the Ethernet
services
Too many words?
===
Abstract
in the context of the Metro Ethernet
Forum (MEF) and International Telecommunication Union (ITU) G.8011.
This reads like the MEF wrote G.8011 together with the ITU.
Do you mean this?
Perhaps the Abstract should mention MEF6
===
Section 1
Paragraph 1 doesn't seem sure how many frameworks there are.
Perhaps
OLD
[MEF6] and [G.8011] provide parallel frameworks
NEW
[MEF6] and [G.8011] provide parallel views of a framework
===
Figure 1
Are the arrows at the bottom of the figure (<----->) supposed to be
associated with the text "UNI" at the top of the figure? Maybe put them
together?
===
Section 1.2
Capitalise section heading, please.
===
Section 2
I think you should add RFC4974 to your list of procedures that must be
followed unless specifically modified.
===
Section 2.2.1
If the object or TLV
are not present, the node MUST discard the message. In this case, a
Message ID Acknowledgment MUST NOT be sent for the Notify message.
I'm worried about this.
Most implementations handle the Message ID Ack before checking the
validity of the message.
Further, simply discarding the message may result in the sender using a
rapid retry.
Why can't you do the Ack and then send a Call Failed response?
===
Section 2.2.1
It looks to me that your solution only works with a single domain if the
source UNI-C does not know the destination UNI-C IP address.
When the Endpoint ID TLV is located, the node MUST map the Endpoint
ID into an IP address associated with the egress edge-node.
Does "egress edge-node" mean UNI-N?
I think so, and given that you have been talking about UNI-C, it may help
to put...
When the Endpoint ID TLV is located, the node MUST map the Endpoint
ID into an IP address associated with the egress edge-node (destination
UNI-N).
In fact, however, in a multi-domain situation, the source UNI-N needs only
map to an E-NNI address, and so on across the network until the final
E-NNI maps to the UNI-N. Would you also allow a zero destination address
within the core network?
===
Section 6
I think you have copied this from somewhere else!
I don't see any "new message object formats" in the document.
Do you need to say why the use of a zero destination address is not a
security problem? You might also observe that a certain element of access
control is devolved to the UNI-N, and that this is consistent with the
operation of GMPLS calls.