Early Review of draft-ietf-mpls-rfc3107bis-01
review-ietf-mpls-rfc3107bis-01-rtgdir-early-hardwick-2017-04-27-00

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc3107bis/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG.  The early review can be performed at any time during the draft’s
lifetime as a working group document.  The purpose of the early review depends
on the stage that the document has reached.  As this document is in working
group last call, my focus for the review was to determine whether the document
is ready to be published.  Please consider my comments along with the other
working group last call comments.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Best regards

Jon

Document: draft-ietf-mpls-rfc3107-01

Reviewer: Jonathan Hardwick

Review Date: 27 April 2017

Intended Status: Standards Track

Summary
Thank you for writing this document.  It provides much-needed clarity to the
original RFC 3107. This document is very well written.  I think that it is
ready to be published, but there are a few points below that I would like to
discuss for clarification. I also spotted a few nits that should be fixed at
some point before publication.

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? (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.”

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?

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

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.

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.

Nits

Section 2: Missing close-parenthesis on “([RFC4760]” – this occurs twice in
this section Section 2.1: s/ an prefixes advertised/ any prefixes advertised/
Section 2.1: Figure 1 appears quite a long way distant from the text that
references it.  I suggest moving it to immediately after the paragraph it is
referenced from. Section 2.1: s/MUST BE/MUST be/ Section 3.1: s/different path
identifiers../different path identifiers./  (i.e. remove stray extra period)
Section 3.2.1: “using the procedure of Figure 4” should be “using the procedure
of Section 2.4”. Ditto in section 3.2.2. Section 4: s/S a layer 2
encapsulation/a layer 2 encapsulation/ (i.e. delete stray ‘S’)