Re: Chair review of draft-ietf-ccamp-gmpls-mef-uni-01.txt

[Lou Berger <lberger@labn.net>]

See in-line responses below.

On 2/18/2009 7:36 AM, Adrian Farrel wrote:
> Hi,
>
> Just a few thoughts.
>
> Cheers,
> Adrian
>
> ===
>
> Obviously, you'll need to use the new IPR boilerplate.

yes, but which!
> ===
>
> Abstract
>
> This document
> supports the types of switching required to implied by the Ethernet
> services
>
> Too many words?

thanks.
> ===
>
> 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

The scope of MEF is a bit less than ITU, so I think it's not needed...

> ===
>
> 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

humm, I think the original phrasing is more accurate.

> ===
>
> 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?

sure.

> ===
>
> 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.

okay

> ===
>
> 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?
just trying to conform to RFC2961:
   Note that MESSAGE_ID objects received in
   messages containing errors, i.e., are not syntactically valid,  MUST
   NOT be acknowledged.

> ===
>
> 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.

Why do you say this?  The scope is only limited by the scope of a call.

> 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?

no as mentioned earlier in the document, an edge-node = the UNI-C. Not 
that it says an address address associated with the egress edge-node, 
which may not be the node itself. (consider the case of Call Segments 
per RFC 4974.

> 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?

Just trying to be consistent with Section 7 of RFC 4974 in this section.

> ===
>
> 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.
How about:

   This document makes use of the mechanisms defined in [GMPLS-ESVCS]
   and [RFC4974].  It does not in itself change the security models
   offered in each.  (Note that the address resolution discussed in
   Section 2.2 above, parallels the replacement of information that
   takes occurs per Section 7.2 of [RFC4974].)  See [GMPLS-ESVCS] and
   [RFC4974] for the security considerations that are relevant to and
   introduced by the base mechanisms used by this document.


Much thanks for the comments.

Lou