Subject: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06

From: Alia Atlas <[email-masked]>
Date: Tue, 20 May 2014 18:37:54 -0400

As part of my routine evaluation of drafts before progressing them to
IETF Last Call,
I do a review.  This draft is very clearly written and I have only a
couple comments.

Please do respond and update the draft - but I am also starting the
IETF Last Call in
parallel with the discussion.  An updated version should be made
available before June 5 or I will have to remove it from the IESG
telechat scheduled for May 12.

Comments:

a) The draft should update RFC2918, given that it is redefining the
"Reserved" field of the ROUTE-REFRESH message.

b) I see that all 8 bits of the RESERVED field are being used for this
purpose.  Is there a reason to do so, given that only 3 values have a
planned use?   I know that there are existing implementations and I
don't have another plan for those values - just general conservation.
(Imagine wanting to do the same procedure but for a more limited scope
of routes.)

Thanks,
Alia

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 07:59:28 -0400

Alia,

(Clearly not speaking for the authors...)

> (Imagine wanting to do the same procedure but for a more limited scope

It seems to me that this is mostly turning the reserved field into the
"sub-types" field (sec 2.2).  While I don't foresee the likelihood of too
much new work being done in here, would the right fix be to create an IANA
registry for that field?

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 May 2014 08:51:05 -0400

Jeff,

The draft has a registry for this already.  I was thinking of any need for
future bits.
If it's been thought about and deemed not needed, that is sufficient.

Alia

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 08:56:29 -0400

On Wed, May 21, 2014 at 08:51:05AM -0400, Alia Atlas wrote:
> The draft has a registry for this already.

And of course now I notice that Google had taken me to -02. :-P

> I was thinking of any need for future bits.  If it's been thought about
> and deemed not needed, that is sufficient.

I don't believe such discussion in that context has happened.  The scheme
(in -06) basically would make it unlikely to carve up the numbers into
bitfields at a later date. 

If we got to the point where that was truly necessary, I suspect someone
would just allocate a new message type and make a next-generation route
refresh.  We're not exactly going through BGP message code points very
quickly.

-- Jeff

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 22 May 2014 14:58:22 +0000

Hi Alia,

Thanks for the feedback. Comments are inlined. #Keyur

>"Reserved" field of the ROUTE-REFRESH message.

#Keyur: ack.

>(Imagine wanting to do the same procedure but for a more limited scope

#Keyur: We have redefined the "Reserved" field to Message sub-type. 3 bits
are used. Remaining are reserved for future use.

Regards,
Keyur

>
>Thanks,
>Alia
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 29 May 2014 10:40:01 -0400

> are used. Remaining are reserved for future use.

Actually per the IANA Considerations section values 128-254 are FCFS which is not very “reserved”. If we really want to accommodate this concern, the whole registry should be Standards Action, instead of just the bottom seven bits of it. Or I guess maybe we could make a small FCFS range in the bottom few bits, say values 3-7, and leave the rest as SA.

> refresh.  We're not exactly going through BGP message code points very

I’m not really too bothered either way.

—John

---

From: Alia Atlas <[email-masked]>
Date: Thu, 29 May 2014 10:53:12 -0400

John,

Since you, Keyur and Jeff have all thought about the question and are not
concerned,
I see no need for any change.

My concern was more conservationist and that it had been considered.

Alia

On Thu, May 29, 2014 at 10:40 AM, John G. Scudder <[email-masked]> wrote:

> Actually per the IANA Considerations section values 128-254 are FCFS which
> is not very “reserved”. If we really want to accommodate this concern, the
> whole registry should be Standards Action, instead of just the bottom seven
> bits of it. Or I guess maybe we could make a small FCFS range in the bottom
> few bits, say values 3-7, and leave the rest as SA.
>