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

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.

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.

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

--
Eric Gray

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 11:00 PM
To: mpls@ietf.org; MPLS-TP ad hoc team
Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts

Working Group,

This is to start a two week working group last call on two drafts:

- draft-ietf-mpls-gach-adv-02; and
- draft-ietf-mpls-tp-ethernet-addressing-01

Please send comments to the mpls working group list.

The working group last call ends June 15, 2012.

Thanks, Loa

(as MPLS WG co-chair)

-- 

Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls