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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 1 Aug 2015 21:54:53 +0000

Hi Alia,
Thanks for the review.

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 30, 2015 at 2:22 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, shraddha <[email-masked]<mailto:[email-masked]>>
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.

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.

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

---

From: Alia Atlas <[email-masked]>
Date: Sat, 1 Aug 2015 23:46:11 -0400

Hi Acee,

On Sat, Aug 1, 2015 at 5:54 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Alia,
> Thanks for the review.
>
> From: Alia Atlas <[email-masked]>
> To: "[email-masked]" <
> [email-masked]>, OSPF WG List <[email-masked]>,
> shraddha <[email-masked]>
> 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.
>
>

That's fine.  I hear that you have given it consideration and everyone is
actively participating and will not cause delays during AUTH48.

My review comments are below.   Thanks again for your hard work in getting
> this far!
> 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.
>

Well, it's easier to specify it for IPv6 & have it not used than to go back
and need to do another draft to add it later.  But this is a judgement call
on your part.  Thanks for clarifying the reasoning in the draft.

> I will clarify this. However, I don’t want to specify any assumption about

I wasn't trying to put in assumptions about the allocation, but if you read
further in
the draft, there are assumptions in the tie-breaking based upon lower
instance values
being allocated first.  Consistency is preferred. :-)

> (
> http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-5
> )
> Is there an example of referencing an IANA directory? I could also
> reference RFC 2823 and RFC 3101 directly.
>

I was just thinking of referencing the name of the IANA registry; having
the URL would be fine in the reference
section, I think. If not, I'm sure the RFC Editor will let us all know ;-)

> Ok - I need to hunt down this OSPF Wiki we talked about in Prague as well.

The IDR one is at http://trac.tools.ietf.org/wg/idr/trac/wiki.  The OSPF
one would
be http://trac.tools.ietf.org/wg/ospf/trac/wiki but it looks like it isn't
there.  You may
need to contact the tools team ([email-masked] or more usefully
[email-masked]).

Once it is created, I can also add it to the charter page on the
datatracker - along with
any other URLs that might be useful.

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Sat, 1 Aug 2015 23:53:07 -0400

Hi Acee,

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

> Hi Alia,
> See a couple inlines.
>
> On Aug 1, 2015, at 5:54 PM, Acee Lindem (acee) <[email-masked]> wrote:
>
> Hi Alia,
> Thanks for the review.
>
> 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.

> 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

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>

---

From: t.petch <[email-masked]>
Date: Tue, 4 Aug 2015 12:57:57 +0100

Acee

On the IANA question, you might find 5226bis of value, particularly
sections 7 and 8.

That I-D also introduces a clarification to the terminology so that
Open Shortest Path First v2 (OSPFv2) Parameters
is a Group and
OSPFv2 Link State (LS) Type
is a registry, something which you might incorporate.

'existing OSPF IANA registry' I find ambiguous.

 Tom Petch

----- Original Message -----
From: "Acee Lindem (acee)" <[email-masked]>
To: "Alia Atlas" <[email-masked]>;
<[email-masked]>; "OSPF List"
<[email-masked]>; "shraddha" <[email-masked]>
Sent: Saturday, August 01, 2015 10:54 PM
Subject: Re: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06

> To:
"[email-masked]<mailto:draft-ietf-ospf-prefix
[email-masked]>"
<[email-masked]<mailto:draft-ietf-ospf-prefix
[email-masked]>>, OSPF WG List
<[email-masked]<mailto:[email-masked]>>, shraddha
<[email-masked]<mailto:[email-masked]>>
> 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.
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.
> values from the OSPFv2 Link State (LS) Type
(http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xht
ml#ospfv2-parameters-5)
> that value 1 is being used earlier - instead of "suggested value" as

------------------------------------------------------------------------
--------

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 4 Aug 2015 13:12:37 +0000

Hi Tom, 

>'existing OSPF IANA registry' I find ambiguous.

I agree - this will be clarified for all 4 of the new registries in the 08
version of the draft.

Thanks,
Acee