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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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]<mailto:[e-mail]>> wrote:
Alia -

From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, December 03, 2015 1:14 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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. ☺

[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.
 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