To:
Cc:
Subject:
Hello
I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-foo-name/
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.
<case 1> As this document has recently been adopted by the working group, my focus for the review is on providing a new perspective on the work, with the intention of catching any issues early on in the document's life cycle.
<case 2> 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.
<case 3> If neither of the above describes the circumstances of the review, then write a brief summary of the reasons for and purpose of the review here (get this from the WG chair if you are not sure).
For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir
Document: draft-name-version.txt
Reviewer: your-name
Review Date: date
Intended Status: copy-from-I-D
Summary:
Choose from this list...
Comments:
Nits:
To: draft-ietf-mpls-rfc3107bis.all@ietf.org; mpls-chairs@ietf.org
Cc: mpls@ietf.org; rtg-dir@ietf.org
Subject: RtgDir Early review: draft-ietf-mpls-rfc3107bis-01.txt
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 https://wiki.ietf.org/en/group/rtg/RtgDir
Document: draft-ietf-mpls-rfc3107-01
Reviewer: John Doe
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
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.”
“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?
“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.”
Should that be “it MUST send”?
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.
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’)
Back to the Routing Area Directorate wiki
The content of this page was last updated on 2017-07-05. It was migrated from the old Trac wiki on 2022-12-20.