Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts

[Stewart Bryant <[e-mail]>]

Eric,

Thank you for your review. To move the draft along
I have addressed the points you make as shown in line.

If my co-authors wish to amend this text, we will
do so during IETF LC and copy you on these amendments.


On 08/06/2012 21:28, Eric Gray wrote:
>
> My Last call review comments on draft-ietf-mpls-gach-adv-02:
>
> In general, this is a very well written draft that is nearly
> ready to publish.  There is one major issue that needs to be
> addressed.
>
> Major Issue:
>
> There is an important point that does not appear to have been
> made sufficiently clear in the IANA Considerations section.
>
> For the TLV types, I assume that the TLV type numbers (section
> 9.4) are intended to be allocated within the context of an
> application ID (allocated according to section 9.3).
>
> This is very much not clear.  In fact, reading section 9.4 as
> it now stands, it looks as if there is a single context for
> TLV IDs, that there are a maximum number of TLV IDs available
> of 255, and that five of these are used by the application in
> this draft.
>
> This seems odd, given that the number space for application IDs
> is from 0x000 to 0xFFFF.  It would seem that we anticipate we
> will have a lot of applications for this protocol, but not too
> many will actually need to say anything.
>
> Hence my assumption about the intent of the TLV type number
> space.
>
> Please clarify what you are really expecting from this TLV Type
> Registry.
In section 3 it says:
The Type field identifies the TLV Object and is scoped to a specific 
application; each application creates an IANA registry to track its Type 
values.

and in Section 4 it says:
The GAP supports several TLV objects related to its own operation via 
the Application ID 0x0000.

I have clarified that 9.4 refers to the GAP itself by amending
the registry title to be

"G-ACh Advertisement Protocol:  GAP TLV Objects (Application ID 0)"

>
> Minor Issue:
>
> In the second pargraph on page 4, I believe one can also use
> LLDP to discover the MAC address of an adjacent Ethernet peer.
> The authors mention this proposed GAP protocol standard can
> be used to exchange information similar to the use of LLDP,
> and then follows this immediately with a special case to find
> out an adjacent peer's MAC address in the case where IP isn't
> supported - using GAP.
>
> Have the authors given any thought to the possibility that the
> fact that IP is not supported may be attributable to the fact
> that Ethernet _is_ supported for L2 peer-to-peer exchanges,
> including LLDP?  IMO, this makes the "special case" not so
> much so.
>
> I think - given that there are a few things we know about this
> case (e.g. - both Ethernet and MPLS are presumed to apply), it
> would be useful to be clear about when it would be the case that:
>
> 1) IP is not present,
> 2) Ethernet is present,
> 3) Knowing the MAC address of an adjacent Ethernet entity is
>     needed, and
> 4) LLDP is not already used.
The GAP protocol can be used over a datalink other than
Ethernet (see section 1.1), including over an MPLS-TP
segment that is itself running over an MPLS-TP segment.

Whilst one use is to learn the MAC address, it has a number of purposes 
including announcing the configuration of the adverting node. Using a 
single protocol to announce the
MAC address along with other configuration information
seems to be a simplification compared to implementing
LLDP just for the MAC addresses.

The paragraph now says:

In networks based on the MPLS Transport Profile (MPLS-TP)
[RFC5921] that do not also support IP, the normal  protocols used to 
determine the Ethernet address of an adjacent MPLS node, such as the 
Address Resolution Protocol [RFC0826]
and IP version 6 Neighbor Discovery [RFC4861] are not
available. The G-ACh advertisement protocol can be used to discover the 
Ethernet MAC addresses of MPLS-TP nodes lacking IP capability 
[I-D.ietf-mpls-tp-ethernet-addressing]. Where it is anticipated that the 
sole purpose of the GAP will be to provide Ethernet MAC address 
learning, the use of LLDP SHOULD be considered.

>
> NIT:
>
> I find the phrase "a primary purpose" somewhat jarring in the
> Introduction.  Is there more than one "primary" purpose?
> Perhaps "One key" as opposed to "A primary"?
s/A primary purpose/ An important use/

- Stewart