Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis

[Jonathan Hardwick <[e-mail]>]

Hi Eric

Thanks for the replies – please see [Jon] inline.

Cheers
Jon

From: Eric C Rosen [mailto:[e-mail]]
Sent: 03 May 2017 19:23
To: Jonathan Hardwick <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis


Thanks for your review!

On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:
I also spotted a few nits that should be fixed at some point before publication.

I have fixed the nits.



Comments and Questions

1) In section 2.1 it says:
“   If the Multiple Labels Capability for a given AFI/SAFI had been
   exchanged on the failed session, but is not exchanged on the
   restarted session, then any prefixes advertised in that AFI/SAFI with
   multiple labels MUST be explicitly withdrawn.”

If I have understood this correctly, it requires a speaker to withdraw NLRI that it sent on the previous session but that it has not sent on the restarted session (because the negotiated session capabilities changed).
(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn when the EOR marker is sent?

The theory here is that the label stack in the stale routes is known to be invalid, so you really don't want your peer to hold on to them until EOR is received.

[Jon] OK, that’s fine.

(b) This seems to contradict section 2.4 which says “Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method.”

I added the following text to section 2.4 right after the quoted sentence:
 (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.)


2) In section 2.1 it says:
“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving” – why isn’t that MUST NOT?

Section 2.1 also requires the receiving speaker to apply "treat-as-withdraw" to such updates, which does imply that the sending speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT".

[Jon] Thanks.  Note that the same change also applies in section 3.2.1

   “Similarly, a given route SHOULD NOT be
   propagated to a given peer if the route's NLRI has more labels than
   the peer has announced”

…and also in section 3.2.2

“A BGP speaker MUST NOT send multiple

   labels to a peer with which it has not exchanged the "Multiple

   Labels" Capability, and SHOULD NOT send more labels to a given peer

   than the peer has announced”


3) In section 2.4 it says:
“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.”
Should that be “it MUST send”?

I think the non-normative (non-RFC2119) language is fine here.

[Jon] It just jarred with me a little.  I’m not going to dig in on this point, but let me explain where I was coming from.  When you say “it may send” the word “may” makes it sound like it is not obliged to do it this way.  I don’t think there is any other way to withdraw the route (short of closing the session) so I think that what you are describing is the obligatory way to withdraw the route.  For that reason I’d prefer either “it sends” or “it MUST send”.


4) In section 5: although some implementations treat SAFI 1 and SAFI 4 routes as comparable, I believe that they should always be treated as independent, in the following sense:
Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to the same prefix P.  The SAFI 4 route MUST NOT be treated by the receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 subsequently sends an explicit withdraw of the SAFI 4 route, this MUST NOT implicitly withdraw the SAFI 1 route, and vice versa.
Am I correct?  I have seen implementations that violate this so I think it is worth spelling out somewhere in this section.

From Section 1:
This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it.  However, for backwards compatibility, it declares most of these interactions to be matters of local policy.
Different deployed implementations have different behavior, and I think it is better to advance the document as is rather than derail it with the inevitable food fight that would occur if we wanted to try to get the IETF to say which implementation is better than which other implementation.  The deployed implementations have been around for many years, and people seem to have adapted to the differences.

[Jon] I agree that this document can’t retrospectively deprecate existing, widely deployed behaviours.  In section 5 you say


“Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable”



Imagine that the SAFI 1 and SAFI 4 routes were received from the same peer on the same session.  What do you mean by “comparable” in this context?  It has been interpreted in incompatible ways by different implementations.

-        Either: the routes are independent in the Adj-RIB-In but comparable in the LOC-RIB (a single best one is selected, the other is retained in memory)

-        Or: The routes are comparable in the Adj-RIB-In i.e. one implicitly withdraws the other.



Both of these behaviours are implemented and deployed.  The issue is that they do not interoperate if SAFI 1 and SAFI 4 are enabled on the same session.  For instance, if an implementation of the first type withdraws its SAFI 4 route then an implementation of the second type is left with no SAFI 1 route with which to forward traffic.  You describe this as a matter of policy, which I can live with, but without further discussion it gives no clue to the lack of interoperability.



I understand that it is too late to say that one of these is wrong and one is right, but the lack of interoperability is an important deployment consideration and I don’t think this document should be silent on it.  IMO this is an important detail for implementers, who need to be aware that both interpretations of “comparable” exist.  New implementations may wish to have a “compatibility setting” that emulates one or the other behaviour on a particular session, so that they can interoperate.



My suggestion: can we expand section 5 slightly to clarify that there are two ways in which implementations can consider SAFI 1 and SAFI 4 routes comparable on a given session, as above, and that the resulting interoperability issue can be avoided either by emulating the appropriate behaviour on that session or by not running SAFI 1 and SAFI 4 on the same session?

5) In section 7 it says:
“ If a BGP implementation, not conformant with the current document,
encodes multiple labels in the NLRI but has not sent and received the
"Multiple Labels" Capability, a BGP implementation that does conform
with the current document will likely reset the BGP session.”

Wouldn’t that prevent incremental deployment of this RFC into a network that is initially composed of such implementations?  Because it seems to require that both ends of each BGP session must be upgraded simultaneously, or else the BGP sessions will all reset.


This issue was discussed at great length when the draft was first submitted.  The vast majority of deployments do not check the S bit.  That is, the de facto standard is to assume that a received update has only one label.   If any existing deployment were transmitting updates with multiple labels encoded into the NLRI, it would already be causing BGP session resets.
[Jon] OK.

(Even iff this were a real problem, it wouldn't require both ends of a session to be upgraded simultaneously.  It would just require one end to have a knob allowing it to accept both old and new behavior from its peer, and a knob telling it whether to use old or new behavior when sending to its peer.  But since the defacto standard doesn't use multiple labels, I don't think we have to worry much about this.)