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

Yes,

IANA record the death date and it is up to the WGC to extend that.
One extension is allowed and then the allocation is supposed
to expire.

My practical experience however is that the IETF "does the
right thing" when it comes to deployed expired early allocations.

Stewart

On 23/10/2012 13:05, t.petch wrote:
> ----- 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
>
>
> .
>

-- 
For corporate legal information go to:

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