Re: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06

[Alia Atlas <[e-mail]>]

Hi Acee,

On Sat, Aug 1, 2015 at 6:51 PM, Acee Lindem <[e-mail]> wrote:

> Hi Alia,
> See a couple inlines.
>
> On Aug 1, 2015, at 5:54 PM, Acee Lindem (acee) <[e-mail]> wrote:
>
> Hi Alia,
> Thanks for the review.
>
> From: Alia Atlas <[e-mail]>
> Date: Thursday, July 30, 2015 at 2:22 PM
> To: "[e-mail]" <
> [e-mail]>, OSPF WG List <[e-mail]>,
> shraddha <[e-mail]>
> Subject: AD review of draft-ietf-ospf-prefix-link-attr-06
>
> As is customary, I have done my AD review
> of draft-ietf-ospf-prefix-link-attr-06 before asking for IETF Last Call.
> First, thank you very much for your hard work on this draft.  It is lovely
> to see needed work move quickly and have numerous interoperable
> implementations.
>
> I do have a number of minor issues on the draft - but all on the level of
> clarifications.  Therefore, I have requested that IETF Last Call be
> started.  Assuming good responsiveness on the part of the authors, a
> revised version that addresses my concerns can be on the IESG telechat on
> August 20.
>
> I do note that there are 6 authors on this draft.  Please provide input -
> since I know that you all well aware that the limit is normally at most 5.
> One can identify a primary editor or two.  This isn't pure process; the
> more authors listed on a draft, the longer it takes to handle AUTH48 -
> particularly when some are not as involved and do not respond rapidly and
> with full context.  I make no judgement about the authors of this draft -
> who have clearly moved from pulling out the idea into a stand-alone draft
> and had a number of different implementations.
>
>
> We’ve already made one pass on pruning the authors and since we are only
> one over, I’d like to leave it as is.
>
>
>
> My review comments are below.   Thanks again for your hard work in getting
> this far!
>
> Minor issues:
>
> 1) On p. 6, it says " AF Address family for the prefix.  Currently, the
> only supported value is 0 for IPv4 unicast."  Please clarify VERY
> CLEARLY why this restriction exists.  Not everyone reading this will
> be familiar with support for IPv6 in various protocols and we are really
> finally heading towards lots more IPv6.
>
>
> I will clarify. There are basically two reasons. The first is that we
> really didn’t want to specify more than was necessary in this base
> document. The second is that we have OSPFv3 for IPv6. So, you may ask why
> we have this at all. The reason is that we didn’t want to rule out
> extension of OSPFv2 completely.
>
>
>
>
> 2) On p. 6 and 8.:
> "The Instance field is an arbitrary value used to maintain multiple
> Extended Prefix Opaque LSAs.  A maximum of 16777216 Extended Prefix
> Opaque LSAs may be sourced by a single OSPF instance.": This doesn't
> really give normative behavior.  I assume that what you mean is that
> the advertising router has a number space for the Instance which has
> no significance outside of that advertising router and can have
> arbitrary values allocated from it.  Each of these LSAs is identified
> uniquely by its Instance number.  Please provide good text for what
> MUST be done and indicate that the value may be used for tie-breaking
> ("In this case, the Extended-Prefix-TLV in the Extended Prefix Opaque
> LSA with the smallest Instance is used by receiving OSPFv2 Routers. ")
> and there's an assumption that the values will be allocated from
> smallest to largest.
>
>
> I will clarify this. However, I don’t want to specify any assumption about
> allocation.
>
>
>
> 3) On p. 6 for the Route Type, it would be useful to have a reference to
> where these type values are pulled from.  I'd also like to see some
> text about whether other values could be valid in the future and how
> so.  For instance, I'm assuming that you are basically pulling the
> values from the OSPFv2 Link State (LS) Type
> (
> http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-5
> )
> - so perhaps you could simply say so or clarify for what are valid
> values.
>
>
> Is there an example of referencing an IANA directory? I could also
> reference RFC 2823 and RFC 3101 directly.
>
>
> I am referencing this URL directly. Given all the YANG documents I’m
> reviewing or even writing, this seems very natural ;^)
>

Sure - I was suggesting the name of the registry also.

4) On p. 9: For Link-Type, could you also put a reference to the IANA
> registry?  I'd prefer it to be clear that if (unlikely as it seems)
> there were a new Link-Type added, it would apply here too.
>
>
> Sure. We’ll do the same.
>
>
>
> 5) In Sec 5, pleaes add an RFC Editor note that Section 5 will be removed
> upon publication.  That's the intent wtih RFC 6982.  Thanks for
> including this section in the draft.  If the information wants to move
> to the OSPF WG wiki, that would give it a place to survive after this
> draft is submitted to the RFC Editor.
>
>
> Ok - I need to hunt down this OSPF Wiki we talked about in Prague as well.
>
>
>
> Nits:
>
> 6) In Sec 2, there's an "e.g., mapping server deployment".  Could you add
> a reference?  This tells me nothing...
>
>
> Sure - it is the segment routing architecture document.
>
>
>
> 7) In Sec 2, In the packet format, could you clarify Opaque type = 7? Same
> for on p.8 for opaque type = 8 ?
>
>
> Sure.
>
>
> I guess you want me to reference the Opaque draft. We have early IANA
> allocation for both these values but that will be completely irrelevant
> once this is published.
>

Sure - it'd be nice to have a reference - but all I was asking was for the
figure to be updated to show the value of the Opaque Type since it is known.

Thanks,
Alia




> Thanks,
> Acee
>
>
>
>
> 8) Since you are creating the registry for the TLVs, please clearly state
> that value 1 is being used earlier - instead of "suggested value" as
> on p.9
>
>
> Sure.
>
> Thanks,
> Acee
>
>
>
> Regards,
> Alia
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>