Re: [Isis-wg] AD Review of draft-ietf-isis-prefix-attributes-09

[Alia Atlas <[e-mail]>]

Les,

On Thu, Dec 3, 2015 at 6:38 PM, Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> Alia –
>
>
>
> Inline
>
>
>
> *From:* Alia Atlas [mailto:[e-mail]]
> *Sent:* Thursday, December 03, 2015 3:24 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: AD Review of draft-ietf-isis-prefix-attributes-09
>
>
>
> Les,
>
>
>
> Thanks for the prompt reply.  Responses in-line as always.
>
>
>
> Regards,
>
> Alia
>
>
>
> On Thu, Dec 3, 2015 at 6:17 PM, Les Ginsberg (ginsberg) <
> [e-mail]> wrote:
>
> Alia -
>
>
>
> *From:* Alia Atlas [mailto:[e-mail]]
> *Sent:* Thursday, December 03, 2015 1:14 PM
> *To:* [e-mail]; [e-mail]
> *Subject:* AD Review of draft-ietf-isis-prefix-attributes-09
>
>
>
> Hi,
>
>
>
> As is customary, I have done my AD review of this draft before progressing
> it.
>
> First, let me thank you for a well-written draft and the work you have put
> into it.
>
>
>
> Next, I believe that a revised version is needed.
>
>
>
> 1)  This draft has 7 authors.  The limit is 5; you can pick an editor if
> you can't trim
>
> down to 5.  I can, of course, listen to a clear write-up of contributions
> made by each
>
> author of this 7 page draft, if you feel that an exception is truly
> warranted.   Until this
>
> issue is addressed, I will not progress this draft.
>
>
>
> *[Les:] I will revise with myself as editor.*
>
>
>
> [Alia]  Thanks
>
>
>
>
>
> 2) The Security Considerations section is completely empty.  You know that
> this
>
> needs to be filled in - if only as a reference to the existing ISIS
> security and a bit
>
> on why sending additional information isn't a concern.
>
>
>
> *[Les:] Sigh…*
>
> *If we had not thought about Security issues we would have put TBD in the
> section. The statement “none” represents a thoughtful consideration of the
> security issues and a conclusion that there are “none”.*
>
> *I am willing to put a statement in that says that – but allow me to
> “sigh” because Security seems to be the only Section where even if you have
> nothing to say you are required to say something anyway. **J*
>
>
>
> [Alia] Because they are reviewed by folks who aren't intimately familiar
> with all the existing security aspects of every protocol
>
> that the IETF does or has ever done.  It's useful to have a pointer saying
> "this adds no additional security issues and ISIS has security handled by
> ...."
>
> It may be the same boiler-plate that isis puts in every draft, but the
> repeated pointer is still useful for those coming a bit new to the topic.
>
>
>
> *[Les:] ACK*
>
> 3)  As a minor kvetch (meaning that you don't have to agree), I'd prefer
> to see
>
> a bit of motivation or how this is expected to be used.  There's a very
> small amount
>
> of motivation from SR - but that doesn't really explain the need to send
> the originating
>
> Router ID.
>
>
>
> *[Les:] Your “kvetch” is about how this should/could be used in the
> future? *
>
> *I believe Section 1 clearly states the motivation for the bits which are
> currently defined – as well as router-id.*
>
> *It is hard to anticipate what additional bits might be defined in the
> future – though clearly they all need to be an attribute of a prefix.*
>
>
>
> [Alia] From reading Section 1, I can see that the motivation is SR - but
> don't actually have enough context (without crawling through reading the
>
> associated SR drafts) to fully see the problem.  In particular, the
> example given doesn't clarify for me the router-id need.  That said, if the
> real
>
> answer is to go read the SR draft in detail, that's fair enough.
>
>
>
>
>
> *[Les:] SR is only one of the use cases. The N bit is useful in a variety
> of circumstances- e.g.RLFA endpoint – any case in which one needs to know
> whether an address can be used as a node address.*
>
> *I think the SR uses are better left to be described in the SR draft. This
> has already been done in draft-ietf-isis-segment-routing-extensions-05
> Section 2.1.1.1. and Section 2.4.5.2.*
>

[Alia]  Pointing out other uses very very briefly would be useful.  While I
didn't think deeply about how else one might use this information, that
there
are other uses expected than SR wasn't clear.

Thanks,
Alia


>  4) Clarifying question:  When a prefix has the external prefix flag set
> and the Router ID is sent, is that the Router ID of the router that is
> doing the redistribution or of the original advertising router (if it were
> available)?
>
>
>
> *[Les:] The routerid is always the ID of the originator of the IS-IS
> advertisement- not the router-id of the external protocol instance from
> which IS-IS might have learned the route.*
>
> *That said, I don’t see any need to advertise the router-id when the
> prefix is an eXternal prefix. It would not do any harm to do so – it just
> isn’t useful. We could add some text to that effect.*
>
>
>
> I think that'd be useful - just your usual brief phrasing is fine :-)
>
>
>
> *[Les:] ACK*
>
>
>
> *   Les*
>
>
>
>
>
> If you can address these issues quickly, then I can issue an IETF Last
> Call and we can have
>
> it on the agenda for the Jan 7, 2016 telechat.  That means that I can
> issue the IETF Last Call no later than Dec 17.
>
>
>
> *[Les:] We will try to get a new version out by early next week.*
>
>
>
> Thanks!  Sorry to have taken so long on the review.
>
>
>
> Alia
>
>
>
>    Les
>
>
>
> Thanks,
>
> Alia
>
>
>