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

From: Eric Gray <[email-masked]>
Date: Fri, 8 Jun 2012 16:28:53 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 11:00 PM
To: [email-masked]; 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: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Eric Gray <[email-masked]>
Date: Fri, 8 Jun 2012 17:16:14 -0400

My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01

In general, this draft is nearly ready for publishing as an RFC.
There are issues the working group and authors should consider.

Major Issue:

This is listed here because I am uncertain of the degree to which
this may be a major or minor issue.

The issue is with the inclusion of MTU as a discoverable parameter
(Section 4).

One reason for using a protocol other than LLDP to discover the
Ethernet MAC address of an adjacent LSR, is where a physical link
may include one or more intermediate bridges.

If this is the case, and LLDP is not in use, then the MTU of the
Ethernet end-stations (the peer/adjacent LSRs) may not be useful,
since the intervening bridges could conceivably have a lower MTU.

Minor Issues:

IANA Considerations -

Why do the authors create yet another registry for IANA to maintain,
instead of using TLVs (with type numbers taken from the regitry that
was created in the GAP specification - from which this draft already
takes a new application identifier)?

This appears to set a very nasty precedent: each new application ID
specified from an IANA registry may establish a new registry.  Does
IANA have the head-room for this?

NITs:

IANA Considerations -

Not sure why section 6.1 is included.  There is no action required 
of IANA here, AFAICT.  Minimally, the authors should explicitly
state that no further action is required from IANA by this section.

--
Eric Gray

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

Working Group,

Thanks, Loa

(as MPLS WG co-chair)

--

---

From: Loa Andersson <[email-masked]>
Date: Sun, 17 Jun 2012 19:35:43 +0200

Working Group,

this working group last call is closed. We have comments, can the
authors please working with the commenters, verify the comment
resolutions on the working group mailing list and republish the draft.

/Loa

(as working group chair)

--