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

Request Review of draft-ietf-mpls-rfc3107bis-01
Requested rev. 01 (document currently at 04)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-04-20
Requested 2017-04-04
Requested by Loa Andersson
Authors Eric Rosen
Draft last updated 2017-04-27
Completed reviews Rtgdir Early review of -01 by Jonathan Hardwick (diff)
Rtgdir Last Call review of -02 by Stewart Bryant (diff)
Genart Last Call review of -02 by Brian Carpenter (diff)
Comments
The dead line is because the wglc ends that day. It is not terribly important who is doing the review, but if you can pick someone with a bess profile.

/Loa
Assignment Reviewer Jonathan Hardwick
State Completed
Review review-ietf-mpls-rfc3107bis-01-rtgdir-early-hardwick-2017-04-27
Reviewed rev. 01 (document currently at 04)
Review result Has Nits
Review completed: 2017-04-27

Review
review-ietf-mpls-rfc3107bis-01-rtgdir-early-hardwick-2017-04-27

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’)