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

From: Alia Atlas <[email-masked]>
Date: Thu, 3 Dec 2015 16:14:04 -0500

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.

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.

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.

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)?

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.

Thanks,
Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 3 Dec 2015 23:17:25 +0000

Alia -

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

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.

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

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.

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.

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.

   Les

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 3 Dec 2015 18:23:40 -0500

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) <[email-masked]>
wrote:

> Alia -
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Thursday, December 03, 2015 1:14 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* AD Review of draft-ietf-isis-prefix-attributes-09
>
>
>
> Hi,
>
>
>
> *[Les:] I will revise with myself as editor.*
>

[Alia]  Thanks

> *[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:] 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.

>  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 :-)

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 3 Dec 2015 23:38:50 +0000

Alia –

Inline

From: Alia Atlas [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 3:24 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]
Subject: Re: AD Review of draft-ietf-isis-prefix-attributes-09

Les,

Regards,
Alia

On Thu, Dec 3, 2015 at 6:17 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Alia -

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 03, 2015 1:14 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AD Review of draft-ietf-isis-prefix-attributes-09

Hi,

[Alia]  Thanks

[Les:] Sigh…

[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

[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:] ACK

   Les

Alia

   Les

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 3 Dec 2015 18:40:46 -0500

Les,

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

> *Sent:* Thursday, December 03, 2015 3:24 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: AD Review of draft-ietf-isis-prefix-attributes-09
>
>
>
> Les,
>
>
>
> On Thu, Dec 3, 2015 at 6:17 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Alia -
>
>
>
> *[Les:] ACK*
> 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
>
> *[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

> *[Les:] ACK*
> *   Les*