From: Eric Gray <eric.gray@ericsson.com>
To: Loa Andersson <loa@pi.nu>,
 "draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org"
 <draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org>
Date: Fri, 8 Jun 2012 17:16:14 -0400
Thread-Topic: [mpls] wg last call  on gach-adv and ethernet-addressing drafts
Thread-Index: Ac0+EExyzMXIBzMZQPmWsrlacY8pgwHpazyw
Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F123BB1E9CAA@EUSAACMS0701.eamcs.ericsson.se>
References: <4FC58D13.6050803@pi.nu>
In-Reply-To: <4FC58D13.6050803@pi.nu>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>,
 MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts
Precedence: list

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=20
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: 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)

--=20


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