Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

["Acee Lindem (acee)" <[e-mail]>]

Hi Alia,

From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 15, 2017 at 8:41 AM
To: Bruno Decraene <[e-mail]<mailto:[e-mail]>>
Cc: Acee Lindem <[e-mail]<mailto:[e-mail]>>, OSPF WG List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

Hi Bruno,

On Fri, Sep 15, 2017 at 7:59 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alia, Acee, WG

From: Acee Lindem (acee) [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Saturday, August 12, 2017 7:25 PM
To: Alia Atlas; [e-mail]<mailto:[e-mail]>; OSPF List
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

Hi Alia,

From: OSPF <[e-mail]<mailto:[e-mail]>> on behalf of Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Friday, August 11, 2017 at 10:42 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, OSPF WG List <[e-mail]<mailto:[e-mail]>>
Subject: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

As is customary, I have done another AD review of draft-ietf-ospf-encapsulation-cap-06.  First, I'd like to thank the authors for their work and the improvement.

I have one minor issue on the IANA section.

For the current FCFS space, I think it would be better to have "Specification Required" so that there's a place to look to understand what sub-TLVs are included.
If the WG is happy with FCFS, that is fine too.

I don’t have a strong opinion here. The goal is to be stingy for the code points that overlap the corresponding IS-IS registry (with a single octet type) and more liberal here. However, we’ve never gone all the way to FCFS before and “Specification Required” would seem more in line with other IGP registries.

[Bruno] Alia, I see your point that we need a stable specification to interop. On the other hand, in the IDR WG, there is a direction toward having code points easier to get, in order to allow quicker implementations and avoid squatting. I though the situation would be similar in OSPF, but may be not. “Specification Required” seem to me roughly as hard to get a code point from, than “Standard Action” with early allocation. Plus there is a need to find a designated expert.

What about changing the size of the ranges? e.g.
- the first half for STD action (1 – 31999)
- second half for FCFS         (32000-65499)

With 32k entries in each range, there seem to be “plenty” for everyone, even if the IETF gets creative with many tunnel encapsulations and many parameters for each.

The bar for Specification Required is much lower than Standard Action.  It just looks for something to be written down.  A web-page, an internet-draft, etc. all qualify.

I prefer to be able to have folks know how to implement using the code-point, but there are tons available and having a FCFS range is useful.

Acee has tracked better what the case is for OSPF - and I'm happy to have him make the call here.

I don’t have a strong opinion so we  could go with the larger STANDARDS ACTION range as suggested by Alia. In either ranges, if we even approach expiration in either range the capability is most likely being misused.

Thanks,
Acee


Regards,
Alia


Thanks,
Regards,
--Bruno



I'm asking for an IETF Last Call and will put this on the telechat on Aug 31.

Thanks – hope to clear some more of these “almost ready" documents prior to next IETF.
Acee


Regards,
Alia

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.