I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
Reviewer: draft-ietf-teas-rsvp-te-li-lb-03.txt
Review Date: 2015/02/08
IETF LC End Date: 2015/02/18
IESG Telechat date: (if known) -
Summary: Almost ready with a number of nits. As somebody who has very
sketchy knowledge of RSVP-TE and GMPLS, I found the discussion of
specification of the identity of the loopback node in an ERO to be very
confusing. The phrase "strictly identify" doesn't really express what
is going on to somebody who is not deeply familiar with the topic. An
example of the relevant parts of a PATH message might help if that could
be managed. What I think is an unfortunate typo ("mode" instead of
"node" in s3.2) sent me off on a wildgoose chase looking for
specifications of loopback modes. I am still not absolutely certain
that this *is* a typo!
Major issues:
None
Minor issues:
None.
Nits/editorial comments:
General: For the avoidance of doubt for IANA, it would be desirable to
identify the five "TBA" values as TBA-1 to TBA-5 wherever they occur.
General: s/in ADMIN_STATUS/in the ADMIN_STATUS/ (10 cases)
Abstract: s/as control plane/for the control plane/
s1, para 1 and last para: s/in Multiprotocol/in the Multiprotocol/
s1,para 2: s/as control plane/for the control plane, s/e.g./e.g.,/
s1, last para: /For MPLS-TP network/For a network supporting MPLS-TP/
s1, last para: Although the formal definitions of LI and LB are given
in the 2 RFCs referenced, it would help with the understanding of this
draft to add short explanation, such as:
ADD:
An LSP that is locked, using LI, is prevented from carrying user data
traffic. The LB function can only be applied to an LSP that has been
previously locked.
s2.1: s?the lock/unlock?the lock/unlock status?,
s2.1: RFC 3471 calls ADMIN_STATUS "Administrative Status". RFC3473 uses
ADMIN_STATUS but the two terms are never formally linked together. I
suggest:
s/in ADMIN_STATUS/in the Administrative Status (ADMIN_STATUS) /
s3.1, para 1: Technically, the A bit isn't defined in this draft: Suggest:
s/bit defined above/bit used as specified above/
s3.2, para 2: Need to expand acronym: ERO
s3.2, para 2:
OLD:
The ingress MUST ensure that the desired loopback mode is strictly
identified in the ERO.
Am I right that "mode" is a typo? Should it be "node" rather than
"mode? I couldn't see anything about "loopback modes" in RFC 5860 or RFC
6371. After much head scratching I came to the conclusion that "node"
was the right answer... If not then please explain where modes are defined.
Continuing on the basis that the word s/b "node"... I think this would
be clearer as follows:
NEW
The ingress node MUST ensure that the node where loopback is intended to
occur is marked as a strict hop (i.e., not a loose hop) in the ERO.
s3.2, para 3:
the node MUST check that the desired loopback is strictly
identified by verifying that the L bit is set to 0 in both the ERO
Hop Attributes subobject and the prior subobject. The prior
subobject MUST also be checked to ensure that it provides strict
identification.
What would the prior subobject likely be? Would it be possible to give
an example of what the RSVP message would contain in the way of objects
and subobjects? This would help with understanding this section. As
with the previous comment, the phrase 'strictly identified' is not very
clear. Maybe:
OLD:
desired loopback is strictly identified
NEW:
node at which loopback is desired is a strict hop in the explicit route
OLD:
it provides strict identification
NEW:
it identifies a strict hop in the explicit route
s3.2, para 3:
Currently, the type value MUST be verified to be
less than 32, and for type values 1 and 2 the prefix length MUST be
32 and 128 respectively.
It would be better to use the names of the types (1 = IPv4, 2 = IPv6)
that would make it clearer why the lengths are as they are specified.
Is it possible to explain why the type has to be less than this
apparently arbitrary limit of 32? And hence what allocation constraints
ought to be applied in the future - this might need a change in the IANA
allocation rules that should be specified in this document.
s5: In line with "modern" policy, the discussion in para 3 of s5 of
draft-ietf-teas-lsp-attribute-ro-01 could be thought of a "Privacy
Considerations" rather than strictly Security Considerations. Please
consider separating out a privacy discussion and referencing the
discussion in draft-ietf-teas-lsp-attribute-ro-01 (which should in turn
talk about Privacy Considerations).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
