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

----- Original Message -----
From: "Stewart Bryant" <stbryant@cisco.com>
To: "Eric Gray" <eric.gray@ericsson.com>
Cc: <draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org>;
<mpls@ietf.org>; "MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>
Sent: Monday, October 22, 2012 6:02 PM
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing
drafts

Hi Eric

Early allocation is a well known process and IANA annotate the
registry entry accordingly.

In particular they set a death date for the allocation and
this is visible in the registry.

<tp>

All as decribed in RFC4020.  Interestingly, that specifies that
" IANA makes an allocation from the appropriate registry, marking it
      as "temporary", valid for a period of one year from the date of
      allocation.  The date of allocation should also be recorded in the
      registry and made visible to the public."
and
"   In particular, it is not IANA's responsibility to track the status
of
   allocations, their expiration, or when they may be re-allocated.
"

What you can see, in, for example, the MPLS registries, is
"TEMPORARY - expires 2012-01-20"
so IANA have not exactly put in the date of allocation, but equally, it
is not up to them to take any further action.

Tom Petch

Stewart

On 22/10/2012 17:08, Eric Gray wrote:
>
> Stewart,
>
> On the IANA allocation, this is a subtle issue, but is unlikely to be
> a problem.
>
> As you know, IANA is occasionally asked to pre-allocate code points.
This
>
> process – as I understand it – is different from an actual allocation
> in that (AFAIK)
>
> the allocation is not actually made in the registry but is reserved in
> IANA's notes
>
> somewhere.
>
> Should it be made clear which case this allocation is? I suspect that
IANA
>
> can figure that out, though, so it is not a big deal…
>
> --
>
> Eric
>
> *From:*Stewart Bryant [mailto:stbryant@cisco.com]
> *Sent:* Monday, October 22, 2012 11:17 AM
> *To:* Eric Gray
> *Cc:* Loa Andersson;
> draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mpls@ietf.org;
> MPLS-TP ad hoc team
> *Subject:* Re: [mpls] wg last call on gach-adv and ethernet-addressing
> drafts
> *Importance:* High
>
> On 08/06/2012 22:16, Eric Gray wrote:
>
>
>
>
>
>     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.
>
> Well, there may be pt-pt Ethernet switches, but there should
> never be an Ethernet bridge in an MPLS-TP path, since
> MPLS-TP is defined to be non-merging.
>
> MTU may be useful on a PT-PT direct link, but I am not sure
> what can be done in the other case other than to use the MTU
> field as an upper bound in an MTU discovery process.
>
> We could define an MTU discovery/verification application
> at a later date if this was needed.
>
>
>
>
> 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)?
>
> That is the design we have proposed - one registry per application.
> Note the T size is 256, and thus we would need sub-TLVs if we
> did not do that, and the sub-TLVs would need their own registries
> so this is awash.
>
>
>
> 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?
>
> I think IANA will be fine with this. They will comment at IETF LC
> if there is a problem, but I don't anticipate any issue.
>
>
>
> 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.
>
> It provides traceability back to this RFC.
>
> It says " IANA has allocated..." so IANA will see they have no
actions.
>
> - Stewart
>
>
>
> --
> Eric Gray
>
>
>
> -----Original Message-----
> From:mpls-bounces@ietf.org  <mailto: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  <mailto: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)
>
>
>
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>

--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls