Subject: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 Sep 2013 15:31:44 -0400

This begins a 2 week working group last call for (ending 9/27)
Enhanced Route Refresh Capability for BGP-4
http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04

This WG last call is in parallel with the 2 week 
implementation report adoption call. 

The implementation report is at: 
http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/

We will read both threads in considering the last call.  If the
implementation report is accepted, we will do a last call on the
implementation report. 

Sue Hares and John Scudder
Idr co-chairs

---

From: Edward Crabbe <[email-masked]>
Date: Fri, 13 Sep 2013 12:32:51 -0700

support

On Fri, Sep 13, 2013 at 12:31 PM, Susan Hares <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Dickson, Brian" <[email-masked]>
Date: Fri, 13 Sep 2013 19:42:16 +0000

Support both.

Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 09:44:43 -1000

the grammar really needs to be cleaned up before it leaves the wg.  e.g.

   A BGP speaker that support the message
                             ^s
and many more

---

    The enhancement can be used to facilitate on-line, non-
    disruptive consistency validation of BGP routing updates.

but it never says how, which may cause someone to wonder if this is a
useful or correct hack

randy

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 Sep 2013 15:46:43 -0400

<chair hat off> 
Agreed. Grammar and English editorial fixes are needed. 
<chair hat on>
Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy
Bush
Sent: Friday, September 13, 2013 3:45 PM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] 2 Week WG last call for
draft-ietf-idr-bgp-enhanced-route-refresh

---

but it never says how, which may cause someone to wonder if this is a useful
or correct hack

randy

---

From: Bhavani Parise <[email-masked]>
Date: Fri, 13 Sep 2013 16:01:47 -0700

Support both

regards,
Bhavani

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Sep 2013 01:40:29 +0000

Section 3, paragraph 3 said:
"
When a route entry in the "ADJ-RIB-
Out" changes, the advertisement of the modified route entry (instead
of the snapshot entry) would suffice.
"
What message subtype is used when sending Route Refresh message in case of the advertisement of the modified route entry?
No Route message is sent in this case?

Regards!
-Qin

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 18 Sep 2013 11:39:40 -0400

<co-chair hat = off>

Summary: based on the below review, I think the document is not yet done.

- The document needs an "Updates: RFC2918" header

- "   A BGP speaker that support the message subtypes for the ROUTE-REFRESH"
  s/support/supports/
  This was previously noted by Randy Bush, IIRC. BTW, I don't claim to 
  be an expert grammarian but other than what I've noted in this review 
  I don't see any problems.

- "   Before the speaker starts a route refresh that is either initiated
   locally, or in response to a "normal route refresh request" from the
   peer, the speaker MUST send a ROUTE-REFRESH message with the
   specified message subtype to mark the beginning of the route refresh.
   After the speaker completes the re-advertisement of the entire Adj-
   RIB-Out to the peer, it MUST send a ROUTE-REFRESH message with the
   specified message subtype to mark the ending of the route refresh."

  Presumably in the first case, the "specified message subtype" is 
  the "Demarcation of the beginning of a route refresh" subtype 1, and
  in the second case, the "specified message subtype" is the 
  "Demarcation of the ending of a route refresh" subtype 2. Say that 
  explicitly (either by the name, the type code, or both). See also 
  the second-last point in this review, about short symbolic names.

- "   Conceptually the "entire ADJ-RIB-Out" for a peer in this section
   refers to all the route entries in the "ADJ-RIB-Out" for the peer at
   the start of the route refresh.  When a route entry in the "ADJ-RIB-
   Out" changes, the advertisement of the modified route entry (instead
   of the snapshot entry) would suffice."

  (By the way, s/ADJ/Adj/g)

  As Qin Wu's message suggests, this text isn't clear enough. Part of
  the problem is that you haven't defined "snapshot" but I think it
  goes beyond that. One way I can think of to fix it would be to
  simply remove the paragraph, on the assumption that "advertise the
  entire Adj-RIB-Out" is sufficiently obvious to an implementor, and
  that's all you're really trying to specify here. Otherwise, I think
  you're going to have to specify more rigorously what you mean by
  "advertise the entire Adj-RIB-Out". In particular, I suspect you're
  trying to bound the time you have to spend before you send the
  subcode 2 message to be O(size of Adj-RIB-Out when you started), so
  that you're not tripped up by pathological cases?

  I don't have text to offer for this case, but I do think the authors
  and WG need to consider it.

- I don't think this text is right:

  "   In processing a ROUTE-REFRESH message from a peer, the BGP speaker
   MUST examine the "message subtype" field of the message and take the
   appropriate actions."

  I mean, it's OK, except it basically says "do the right thing" ("take
  the appropriate actions"). The spec either needs to say unambiguously 
  what the right thing is (if it's a MUST) or adopt some more relaxed 
  tone. Likewise,

  "The BGP speaker SHALL use the demarcations of
   the beginning and the ending of a route refresh to perform
   consistency validations of the updates received from the peer."

  At most, the speaker MAY do that. If we wanted to mandate it (and I
  don't think we do) we would need to say what "perform consistency
  validations" means. I would be OK with either striking the text, or
  changing the SHALL to a MAY.

  Here is a possible rewrite of the paragraph:

   When a BGP speaker receives a Route Refresh message from a peer
   with subtype 1 it MUST mark all routes with the given AFI/SAFI 
   from that peer as stale. As it receives routes from its peer's 
   subsequent Adj-RIB-Out readvertisement, these replace any
   corresponding stale routes. When the BGP speaker receives a 
   Route Refresh message from the peer with subtype 2, it MUST 
   immediately remove any routes from the peer that are still marked 
   as stale for that address family. Such routes MAY be logged for
   further analysis. (It can be observed that this procedure is 
   substantially the same as for the Restarting Speaker in Section 
   4.2 of [RFC4724].)

- RFC 4724 has a timer to deal with the case where the Restarting
  Speaker forgets to send the EoR. Subcode 2 is basically an EoR, but
  we have no timer. Is this a problem? Do we need some other kind of
  safety mechanism? Or are we happy to just rely on the correctness
  of the implementation (ahem).

- During the initial Adj-RIB-Out advertisement, can normal withdraws
  be sent? I assume so. Not sure if anything need be said about this.

- The Error Handling section of the draft assumes traditional RFC 4271
  style error handling, namely if you see something wrong, reset the
  session. Is this the right thing to do in light of the other work the 
  WG has been doing with draft-ietf-idr-error-handling? For that 
  matter, is this the right thing to do in light of the fact that 
  regular route-refresh messages aren't specified to behave in this 
  way? I don't *necessarily* propose that malformed refresh messages 
  should be ignored, but it seems worth discussing. If this stricter
  approach is adopted, should it be considered for regular Route 
  Refresh too, and if so, should that go in this document?

  Also, assuming the current error approach is kept, why not go whole 
  hog and finish enumerating the possible error conditions? I think 
  there's only one other: Invalid Subtype. (See also my final point
  below.)

- What is the expected behavior if the peer sends another Route Refresh
  request when the first request is still in progress (subtype 2 has
  not yet been sent)? One option is that you could cancel the old
  refresh, send another subtype 1, then the new refresh, then close it
  with a subtype 2. But this implies there would be two subtype 1's
  followed by only one subtype 2. Another way of asking this question
  is whether there are any restrictions on the interleaving of subtype
  1 and 2, and what error handling (if any) is to be applied if the
  restrictions (if any) are violated.  

- In the Acks, you need to capitalize Jeff Hass's last name.

- In writing this review I've had to choose several times between 
  referring to "subcode 1" and "subcode 2" (not very descriptive) and
  "Demarcation of the beginning of a route refresh" and "Demarcation 
  of the ending of a route refresh" (verbose). This leads me to think
  it might be handy for the document to provide short symbolic names
  for the subtypes, such as BoRR and EoRR.

- By the way, now that you've turned the "reserved" field into a 
  "subtype" field, you need to decide what to do with the rest of the
  values. Right now we have 0 which means either route-refresh or
  ORF (disambiguated by length) and 1 and 2 defined in this document.
  The obvious thing to do would be to make this a registry, though
  then you have to say what to do with unrecognized values. Come to
  think of it, you have to say that anyway, right now the Error 
  Handling section doesn't cover it. 

</hat>

Thanks,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 18 Sep 2013 11:39:40 -0400

<co-chair hat = off>

</hat>

Thanks,

--John

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 18 Sep 2013 18:02:53 +0100

Hello,

>  of the implementation (ahem).

Good point. I was happy to rely on the correctness of the implementation (see reason below) but can see how a timer could be considered.

>  be sent? I assume so. Not sure if anything need be said about this.

As the draft speaks of a "snapshot", which I read (quoting wikipedia) as "the state of a system at a particular point in time", I assumed that all updates received after the sending of the start of route-refresh message, including withdrawn, from the same family as the route being currently transferred, should be queued and only sent once the end of refresh message (EoRR in your speak) was sent.

This decision as the side effect to remove the need for a timer as the number of route to transfer is bound but I believe the definition should be loose enough to not close the option to reflect change received since the start of the dump, including sending withdraw message.

Another advantage of this design : as it is not possible for the recipient to differentiate routes sent part of a Route-Refresh and 'normal' updates, a withdrawn being send (part of a normal update) before the announcement (part of the RR refresh) could leave a route as announced when it should not. This border case could be dealt with by a clever implementation, using point in time snapshot simply eliminate the need for such cleverness.

>  WG has been doing with draft-ietf-idr-error-handling?

IMHO, this is outside the scope of this draft. Would we want some RFC implementing part of draft-ietf-idr-error-handling if it this draft never reach RFC status ?
If the normal behaviour of BGP regarding notification should change, this should be reflected in draft-ietf-idr-error-handling not in this draft.

>  not yet been sent)?

Very good question ! I would propose that the draft should ask the sender to not send another RR for the same family while the first one is being honoured, and explicitly request for the second message to be ignored by the receiving party while its first transfer is still ongoing. Otherwise how would you do this ?

Allowing cancellation would surely require the creation of a new code for this "cancelled transfer" (like a subtype 3) before a new start of RR (subtype 1) is sent, or how would the router know that it can not performed any validation with the data received as incomplete ?

>  for the subtypes, such as BoRR and EoRR.

Agree.

Thomas

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 24 Sep 2013 15:56:51 -0400

Thomas,

On Sep 18, 2013, at 1:02 PM, Thomas Mangin <[email-masked]> wrote:
...
> This decision as the side effect to remove the need for a timer as the number of route to transfer is bound but I believe the definition should be loose enough to not close the option to reflect ch…

Two points:

First, I think your "snapshot" paragraph above illustrates the need for a little more clarity in the draft as to what routes are to be transferred, and when, since I suspect not all readers would have the same interpretation.

Second, I don't see how this has "the side effect to remove the need for a timer", since one possible error case is where the sending side simply forgets to send the EoRR, but otherwise continues to send normal routing updates. One may argue that this is unlikely, but it's still possible. I guess the counter-argument is that unlike GR, we aren't mandating that implementations hold up any other processing or retain large volumes of state, so the consequences of not ever getting the EoRR might not be severe -- or if implementation choices make the consequences severe, the implementation could implement a timer as a local option.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 24 Sep 2013 16:00:40 -0400

It occurs to me that one bit of clarification that might help is to state that all updates received during the route refresh are to be processed as normal, except as explicitly noted in the spec, and that the EoRR's only uses are to signal that stale routes can be flushed, and optionally any "sanity" steps (locally defined) can be taken.

--John

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 24 Sep 2013 21:58:35 +0100

> Second, I don't see how this has "the side effect to remove the need for a timer", since one possible error case is where the sending side simply forgets to send the EoRR,

I assumed that vendor would never ship code as broken as that, but I will concede this point and agree with you :-)

> It occurs to me that one bit of clarification that might help is to state that all updates received during the route refresh are to be processed as normal, except as explicitly noted in the spec, a…

Sounds good to me.

Thomas

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 13:19:22 +0000

Hi all,

Please find below some comments:

Note: in this email, RR stands for ROUTE-REFRESH.

1) Routing consistency validation
3. Operations:
" When a route entry in the "ADJ-RIB-
   Out" changes, the advertisement of the modified route entry (instead
   of the snapshot entry) would suffice."

This indeed allows faster propagation of routing change which is a priori good.
However, this seems to limit the ability to perform "consistency validations of BGP routing updates" as described in the abstract. Because the BGP speaker receiving the route refresh does not know if the inconsistency (between its local route and the received refreshed one) is due to a new update, or a missed old one.
Indeed, the introduction only refers to "missing withdraws". However, for VPN SAFI, missing updates are also important as the VPN label of the NLRI may have change and hence, with a missed BGP update, the packet could be directed to a wrong VPN.

2) Error handling
2.a) " When the BGP speaker detects an error while processing a ROUTE-
   REFRESH message with a non-zero "Message Subtype" field, it MUST send
   a NOTIFICATION message"

I don't think this behavior is the one called by " Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 "
draft-ietf-grow-ops-reqs-for-bgp-error-handling
This seems too disruptive for a non vital message.
One could say that this point if for draft-ietf-idr-error-handling. However IMHO, draft-ietf-idr-error-handling should rather cover the general case plus past RFC. New document should handle their new error cases, the new way.
And from an implementation standpoint, let's imagine a company that has implemented both drafts, which error handling behavior has been implemented i.e. will get deployed?

2.b) One case of error is missing: what should be done if the BGP capability received has a length not matching the receiver requirements? (ignore the capability? ignore the wrong length? send a notification?

2.c) Draft is more or less overriding the "Reserved [...]. Should be set to 0 by the sender and ignored by the receiver.". I think I would be fair to say that "RR messages with unknown Subtypes SHOULD be processed as regular RR", which seems on the same line of the existing RR RFC (rather than sending a notification as currently specified in this draft: " When the BGP speaker detects an error while processing a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message")

3) Message subtypes
- IMO, a new IANA registry needs to be created to allow new values to be defined for this new sub-type.
- It would be good to define how new sub-types values are going to be introduced in the protocol/network. One option may be to have the new "Enhanced Route Refresh Capability" listing (in its value field) all the supported subtypes.

4) aborting ERR
A BGP speaker having send a "Demarcation of the beginning of a route refresh" may want to abort the ERR procedure and not send the "Demarcation of the ending of a route refresh". One reason may be that sending the route refresh is too long (e.g. exceed a local timer) and hence delay too much the sending of BGP withdraw, hence delay the BGP convergence. In such case, how is the speaker supposed to react? (one option may be to define a sub-type for abortion)

Same question for the receiver: if it finds the RR too long (compared to its BGP convergence time requirements), how should it behave? (one option which may help would be to advertise such max delay in the BGP capability)

5) not receiving "Demarcation of the ending of a route refresh
How is the receiver supposed to react?
- Never ever send a new RR on this session? This would be problematic as RR are typically used often, e.g. when a new VPN is configured. But it's not clear if sending a new RR is, strictly speaking, allowed by the current text. Hence the receiver would take the risk of "upsetting" the speaker and receiving a NOTIFICATION. 

- And if it sends a new RR, and receive a new "Demarcation of the beginning of a route refresh", should it wait for two " Demarcation of the ending of a route refresh" or is single one. (same question for the speaker: should it send two or one).

6) MUST?
" Before the speaker starts a route refresh that is either initiated
   locally, or in response to a "normal route refresh request" from the
   peer, the speaker MUST send a ROUTE-REFRESH message with the
   specified message subtype to mark the beginning of the route refresh."

If the RR is initiated locally, I don't think that there is a need for a MUST. SHOULD seems more reasonable. MAY could even be enough.

Thank you,
Regards,
Bruno

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan
>Hares
>Sent: Friday, September 13, 2013 9:32 PM
>To: idr wg
>Cc: 'Keyur Patel (keyupate)'
>Subject: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-
>refresh
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 27 Sep 2013 17:38:15 -0400

Bruno and all other reviewers:

Thank you for your comments and your review of
idr-ietf-idr-bgp-enhanced-route-refresh. 

This draft seems to be implemented, but the text seems to need another
revision prior to passing WG LC.  I encourage the authors to spin another
revision of the text. 

We'll pick this up with another WG LC on this draft. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2013 9:19 AM
To: Susan Hares; idr wg
Cc: 'Keyur Patel (keyupate)'
Subject: RE: [Idr] 2 Week WG last call for

Hi all,

This indeed allows faster propagation of routing change which is a priori
good.
However, this seems to limit the ability to perform "consistency validations
of BGP routing updates" as described in the abstract. Because the BGP
speaker receiving the route refresh does not know if the inconsistency
(between its local route and the received refreshed one) is due to a new
update, or a missed old one.
Indeed, the introduction only refers to "missing withdraws". However, for
VPN SAFI, missing updates are also important as the VPN label of the NLRI
may have change and hence, with a missed BGP update, the packet could be
directed to a wrong VPN.

2) Error handling

I don't think this behavior is the one called by " Operational Requirements
for Enhanced Error Handling Behaviour in BGP-4 "
draft-ietf-grow-ops-reqs-for-bgp-error-handling
This seems too disruptive for a non vital message.
One could say that this point if for draft-ietf-idr-error-handling. However
IMHO, draft-ietf-idr-error-handling should rather cover the general case
plus past RFC. New document should handle their new error cases, the new
way.
And from an implementation standpoint, let's imagine a company that has
implemented both drafts, which error handling behavior has been implemented
i.e. will get deployed?

2.b) One case of error is missing: what should be done if the BGP capability
received has a length not matching the receiver requirements? (ignore the
capability? ignore the wrong length? send a notification?

2.c) Draft is more or less overriding the "Reserved [...]. Should be set to
0 by the sender and ignored by the receiver.". I think I would be fair to
say that "RR messages with unknown Subtypes SHOULD be processed as regular
RR", which seems on the same line of the existing RR RFC (rather than
sending a notification as currently specified in this draft: " When the BGP
speaker detects an error while processing a ROUTE-REFRESH message with a
non-zero "Message Subtype" field, it MUST send a NOTIFICATION message")

3) Message subtypes
- IMO, a new IANA registry needs to be created to allow new values to be
defined for this new sub-type.
- It would be good to define how new sub-types values are going to be
introduced in the protocol/network. One option may be to have the new
"Enhanced Route Refresh Capability" listing (in its value field) all the
supported subtypes.

4) aborting ERR
A BGP speaker having send a "Demarcation of the beginning of a route
refresh" may want to abort the ERR procedure and not send the "Demarcation
of the ending of a route refresh". One reason may be that sending the route
refresh is too long (e.g. exceed a local timer) and hence delay too much the
sending of BGP withdraw, hence delay the BGP convergence. In such case, how
is the speaker supposed to react? (one option may be to define a sub-type
for abortion)

Same question for the receiver: if it finds the RR too long (compared to its
BGP convergence time requirements), how should it behave? (one option which
may help would be to advertise such max delay in the BGP capability)

5) not receiving "Demarcation of the ending of a route refresh How is the
receiver supposed to react?
- Never ever send a new RR on this session? This would be problematic as RR
are typically used often, e.g. when a new VPN is configured. But it's not
clear if sending a new RR is, strictly speaking, allowed by the current
text. Hence the receiver would take the risk of "upsetting" the speaker and
receiving a NOTIFICATION. 

- And if it sends a new RR, and receive a new "Demarcation of the beginning
of a route refresh", should it wait for two " Demarcation of the ending of a
route refresh" or is single one. (same question for the speaker: should it
send two or one).

6) MUST?

If the RR is initiated locally, I don't think that there is a need for a
MUST. SHOULD seems more reasonable. MAY could even be enough.

Thank you,
Regards,
Bruno

>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>Susan Hares
>This begins a 2 week working group last call for (ending 9/27) Enhanced 
>Route Refresh Capability for BGP-4
>This WG last call is in parallel with the 2 week implementation report 
>adoption call.
>

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.