Subject: [Idr] comments on draft-ietf-idr-add-paths-09

From: Jay Borkenhagen <[email-masked]>
Date: Mon, 4 Nov 2013 11:01:37 -0500

Some comments on draft-ietf-idr-add-paths-09:

The second paragraph of Section 5 now reads:

   A BGP speaker that is willing to receive multiple paths from its
   peer, or would like to send multiple paths to its peer, SHOULD
   advertise the ADD-PATH Capability to the peer using BGP
   Capabilities advertisement [RFC5492].

BGP speakers *hate* being anthropomorphized, so I would recommend
removing terms such as "is willing" and "would like to".  Also, this
use of "SHOULD" should be changed: "SHOULD" implies that add-path
might still happen in this session even if the ADD-PATH capabilities
advertisements do not occur -- that ain't gonna happen.  Let me
propose:

   For a BGP speaker to be able to send multiple paths to its peer,
   that BGP speaker MUST advertise the ADD-PATH 'send' capability to
   the peer AND that peer MUST advertise the ADD-PATH 'receive'
   capability to the BGP speaker, using BGP Capabilities advertisement
   [RFC5492].

OR possibly you should delete this second paragraph entirely -- I
think the current third paragraph specifies this requirement well
enough.

The draft needs to specify how certain conditions should be dealt
with. Suppose router A and router B agree that A will send to B
using add-path.  

 - What should B do if an update received from A is a withdrawal
containing a Path Identifier not seen previously, while B had
previously received from A an announcement for the same prefix with a
different Path Identifier?  One implementation might be strict in
interpreting the withdrawal as gratuitous and leave the received
annoucement in place, while another might conclude that the odd
withdrawal is a sign that router A has lost track of which Path
Identifiers it has used for which announced prefixes, and take some
other action.  This standard should specify which interpretation
should be used.

 - What should B do if an update received from A does not include any
Path Identifier?  (I presume this situation would be a NOTIFY-worthy
protocol error condition.)

---

From: Shyam Sethuram <[email-masked]>
Date: Mon, 4 Nov 2013 17:37:31 -0800

On Mon, Nov 4, 2013 at 8:01 AM, Jay Borkenhagen <[email-masked]> wrote:

> different Path Identifier?

That would be a NOP.

> One implementation might be strict in

The former is the right behavior. IMHO it's sufficiently clear in the
standard.

> protocol error condition.)

There's no reliable way to know this... you'd probably run into a
parsing error and end up sending a Notification anyway.

Cheers!
-Shyam

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

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 5 Nov 2013 02:18:47 +0000

Withdraw for non-existent path:
BGP is permitted to do that without add-path.
My vote would be to do the same with add-path: ignore it.
You said never-existed path. I can not tell the difference between a once-existed-and-now-gone path and a never-existed path.

Send add-path capability, but send updates without path-id:
I can not see a reason for doing this, so consider it an error.
My vote would be to treat it as withdraw, in accordance with the error-handling draft.
That is: withdraw all paths with that prefix from this speaker. And log an error, of course.

Thanks,
Jakob.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Borkenhagen
Sent: Monday, November 04, 2013 8:02 AM
To: [email-masked]
Subject: [Idr] comments on draft-ietf-idr-add-paths-09

BGP speakers *hate* being anthropomorphized, so I would recommend removing terms such as "is willing" and "would like to".  Also, this use of "SHOULD" should be changed: "SHOULD" implies that add-path might still happen in this session even if the ADD-PATH capabilities advertisements do not occur -- that ain't gonna happen.  Let me
propose:

OR possibly you should delete this second paragraph entirely -- I think the current third paragraph specifies this requirement well enough.

The draft needs to specify how certain conditions should be dealt with. Suppose router A and router B agree that A will send to B using add-path.  

 - What should B do if an update received from A is a withdrawal containing a Path Identifier not seen previously, while B had previously received from A an announcement for the same prefix with a different Path Identifier?  One implementation might be strict in interpreting the withdrawal as gratuitous and leave the received annoucement in place, while another might conclude that the odd withdrawal is a sign that router A has lost track of which Path Identifiers it has used for which announced prefixes, and take some other action.  This standard should specify which interpretation should be used.

 - What should B do if an update received from A does not include any Path Identifier?  (I presume this situation would be a NOTIFY-worthy protocol error condition.)

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Tue, 5 Nov 2013 02:25:37 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Monday, November 04, 2013 6:19 PM
To: Jay Borkenhagen; [email-masked]
Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09

[SR] What does it mean to say "without path ID"? If the BGP speaker is expecting an "add-path NLRI" (because the capabilities are exchanged at least one way), then it will always parse the first 4 octets as the ID. If the sender didn't actually add the Path ID field in the NLRI, it will (most likely) run into a parsing error (a length error somewhere), in which case it has to reset the neighbor session.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 5 Nov 2013 02:31:41 +0000

Good point. Didn't think enough.

--
Jakob Heitz. 

> On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" <[email-masked]> wrote:
>

---

From: Jay Borkenhagen <[email-masked]>
Date: Tue, 5 Nov 2013 22:51:04 -0500

Top-posting here because we already have a formatting mish-mash.

I agree that if add-path capability is negotiated but a sender omits
the PathID, this will result in length error.  That is why I
initially wrote "I presume this situation would be a NOTIFY-worthy
protocol error condition."

But I still believe more care needs to be taken for the other case,
namely: 

 A and B negotiate that A will announce to B with add-path.

 A announces prefix-1, using PathID-1 in so doing.

 Later A withdraws prefix-1, using PathID-2.

Suppose this situation occurs because of an off-by-one or other logic
error in managing PathIDs in A's implementation, and now A will never
again update prefix-1 using PathID-1.  That PathID-1/prefix-1 will
never be removed from B's RIB-IN until someone (a person) notices that
the prefix-1 route learned from A is no longer forwarding correctly.

Prior to add-path, the situation is different: a gratuitous withdrawal
won't hurt (other than possibly causing needless work) and it will be
effective in removing any state that might earlier have been created.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 6 Nov 2013 05:32:10 +0000

How can you tell the difference between a gratuitous withdrawal and this error?

--

Jakob Heitz.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jay Borkenhagen [[email-masked]]
Sent: Tuesday, 05 November 2013 7:51 PM
To: [email-masked]
Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09

---

From: Jay Borkenhagen <[email-masked]>
Date: Wed, 6 Nov 2013 08:28:34 -0500

Precisely!

So while in regular BGP a gratuitous withdrawal might be no big deal,
with add-path it could be one of the few things a receiver could look
for as a sign that the sender has lost its mind.

Summing up: to create add-path's value, the draft introduces the Path
Identifier which carries no semantics.  But in doing so some new
ambiguities are created.  Perhaps the requirements of add-path
receivers should be tightened w.r.t. regular BGP receivers to
eliminate/control the ambiguities.  For the specific case in point: if
there is no demonstrably good reason to send an explicit withdrawal
using a Path Identifier that had not been used to announce the same
prefix, then perhaps it should not be allowed.

That's what I wanted to say.  I would very much like to hear the
[respected] authors' reactions.

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Wed, 6 Nov 2013 17:01:48 +0000

The path-id is part of the NLRI key. If the id is changed, it is a different key. So first sending a prefix with id 10, and then sending a withdraw with the same prefix with id 20 is no different from the case where sender first sends 1.1.1.1/32 and then sends a withdraw for 0.1.1.1/32.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Borkenhagen
Sent: Wednesday, November 06, 2013 5:29 AM
To: Jakob Heitz
Cc: [email-masked]
Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09

Precisely!

So while in regular BGP a gratuitous withdrawal might be no big deal, with add-path it could be one of the few things a receiver could look for as a sign that the sender has lost its mind.

Summing up: to create add-path's value, the draft introduces the Path Identifier which carries no semantics.  But in doing so some new ambiguities are created.  Perhaps the requirements of add-path receivers should be tightened w.r.t. regular BGP receivers to eliminate/control the ambiguities.  For the specific case in point: if there is no demonstrably good reason to send an explicit withdrawal using a Path Identifier that had not been used to announce the same prefix, then perhaps it should not be allowed.

That's what I wanted to say.  I would very much like to hear the [respected] authors' reactions.

Jakob Heitz writes:
 > From: [email-masked] [[email-masked]] on behalf of Jay Borkenhagen [[email-masked]]  > Sent: Tuesday, 05 November 2013 7:51 PM  > To: [email-masked]  > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09  >  > Top-posting here because we already have a formatting mish-mash.
 >
 > I agree that if add-path capability is negotiated but a sender omits  > the PathID, this will result in length error.  That is why I  > initially wrote "I presume this situation would be a NOTIFY-worthy  > protocol error condition."
 >
 >
 > But I still believe more care needs to be taken for the other case,  > namely:
 >
 > Suppose this situation occurs because of an off-by-one or other logic  > error in managing PathIDs in A's implementation, and now A will never  > again update prefix-1 using PathID-1.  That PathID-1/prefix-1 will  > never be removed from B's RIB-IN until someone (a person) notices that  > the prefix-1 route learned from A is no longer forwarding correctly.
 >
 > Prior to add-path, the situation is different: a gratuitous withdrawal  > won't hurt (other than possibly causing needless work) and it will be  > effective in removing any state that might earlier have been created.
 >
 >
 >
 >
 >
 > Jakob Heitz writes:
 >  > > From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz  >  > > Sent: Monday, November 04, 2013 6:19 PM  >  > > To: Jay Borkenhagen; [email-masked]  >  > > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09  >  > >  >  > > Withdraw for non-existent path:
 >  > > From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Borkenhagen  >  > > Sent: Monday, November 04, 2013 8:02 AM  >  > > To: [email-masked]  >  > > Subject: [Idr] comments on draft-ietf-idr-add-paths-09  >  > >  >  > > Some comments on draft-ietf-idr-add-paths-09:
 >  > >
 >  > > BGP speakers *hate* being anthropomorphized, so I would recommend removing terms such as "is willing" and "would like to".  Also, this use of "SHOULD" should be changed: "SHOULD" implies that add-path might still happen in this session even if the ADD-PATH capabilities advertisements do not occur -- that ain't gonna happen.  Let me  >  > > propose:
 >  > >
 >  > > - What should B do if an update received from A does not include any Path Identifier?  (I presume this situation would be a NOTIFY-worthy protocol error condition.)  >  > >  >  > > _______________________________________________
 >  > > Idr mailing list
 >  > > [email-masked]

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 6 Nov 2013 17:17:16 +0000

Yes, the ambiguity exists with or without add-path.

To provide a demonstrably good reason not to treat the ambiguity as an error, a BGP receiver frequently discards received paths due to policy. Non imported route target is an example. To detect the bad withdrawal, the receiver would have to keep all received paths. It's not worth it.

--
Jakob Heitz.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Nov 2013 19:36:19 -0500

> Yes, the ambiguity exists with or without add-path.

There really is no ambiguity.  In deployment, there is no way to distinguish
this case from having discarded the associated *valid* reachability
according to local policy.

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 7 Nov 2013 00:39:37 +0000

By "ambiguity" I meant that there is no way to distinguish the cases.
So, even though the words don't agree, we agree on meaning.
--

Jakob Heitz.

________________________________________
From: Jeffrey Haas [[email-masked]]
Sent: Wednesday, 06 November 2013 4:36 PM
To: Jakob Heitz
Cc: Saikat Ray (sairay); [email-masked]; Jay Borkenhagen
Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09

-- Jeff