IPv6 Traffic Engineering in IS-IS
draft-ietf-isis-ipv6-te-08

[Ballot comment]
A number of acronyms are used without expansion.

---

It would probably be proper for Section 5 to include a pointer to RFC
5304 for general security considerations for IS-IS.

---

Are you sure the authors don't want to change their affiliation?

[Ballot discuss]
Please make the changes agreed after Routing Directorate review by
Tomonori Takeda, expecially the change wrt the deprecation of site-local
addresses.

---

In Section 4.4
  The flag octet indicates whether the IPv6 neighbor address is
  included (set to 1), or not included (set to 0).  Other values for
  the flags field are reserved - an implementation receiving a value
  for the flags field other than 0 or 1 SHOULD discard the TLV.

  Note that this rule for processing the flags octet allows for future
  extensibility of the IPv6 SRLG TLV.  In particular, it allows
  alternative means of identifying the corresponding link to be added
  in the future.  An implementation that does not understand such an
  extension will simply discard the TLV, rather than attempting to
  interpret the TLV incorrectly.

Surely this field contains bit flags and should not be treated as an
integer.

But anyway, what you have seems to break future extensibility rather
than facilitate it as you claim. Are you really saying that if a future
use of the flags is found, this TLV should not be propagated by legacy
routers? Are you also saying that such legacy routers should entirely
ignore all information in the TLV?

If this is what you are saying, you are really using the flags field as
a TLV sub-type value not as flags at all.

---

In Section 4.4

  To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP
  from contradicting each other, the following rules are applied.

I don't think a contradiction would be implied by breaking the rules
since one could infer an additive rule. So perhaps...
s/contradicting each other/causing confusion of interpretation/

---

A normative reference to RFC 2119 is missing.

---

[GMPLS] appears to be a normative reference from 3.2

---

[GMPLS-ROUTING] appears to be a normative reference from 4.4

[Ballot comment]
The following comments were made during Routing Directorate review.

The authors have agreed text with the reviewer that addresses these issues.

======
Summary:
This document is basically ready for publication, but has some minor
issues to be considered before publication.


Comments:
This document is well written and easy to read. I have several nits and
one minor question.


Major Issues:
No major issues found.


Minor Issues:

Section 3.1.1:
Global, site-local and link-local addresses are mentioned. Have you
considered that site-local addresses have been deprecated by RFC 3879?
Have you considered unique local addresses in RFC 4139?


Nits:

- I would suggest to add RFC 2119 to normative references.

- Usually, the main body starts with Introduction section, followed by
Requirement Words. I would suggest that Section 2 (Overview) is moved up
to Section 1, followed by Requirement Words (or Requirement Words can be
a separate section).




======

[Ballot comment]
1) acronyms should be expanded on first use. CSPF, SPF,
2) section 3 is very lightweight; mainly it is pointers to sub-sections in section 4 that correspond to IPv4 TLVs. I think section 3.2 could be eliminated by simply moving the reference to the IPv4 TLVs into each section 4 sub-section. (or even just providing a table of corresponding TLVs)
3) in 4.5, you should have a referendce for the Hello.

[Ballot discuss]
There are sections of this document that should be made more clear and unambiguous before being advanced to standards-track.

1) there are numerous places where "this TLV" is used, and sometimes the reference is ambiguous. I recommend spelling out the TLVs by name.

2) 3.2.3 says a new TLV is needed to build a Neighbor Address TLV, but never says WHY another TLV is needed. As far as I can tell, there needs to be a mapping between a link-local address and a "global" address, but I don't know why from this text.

3) The second paragraph in 3.2.3 has lots of ambiguity and really needs to be tightened up.
I don't know what "get hold of" means from a technical point of view.
I don't know what "build" a sub-TLV means from a technical point of view.
"To achieve this" - from the context, "this" seems to refer to "getting hold of a global or site-local address"
"To achieve this, [a TLV] is defined in 4.5", but 4.5 doesn't talk at all about how to "get hold of" an address.
The next to last sentence talks about using the new TLV in the IIH. Then the last sentence talks about two TLVs - "The TLV" used with an [IPv6] TLV, which, when used in the IIH carries a link-local address. Does this mean that "The TLV" (the new one), when used in the IIH, carries a link-local address, or does this mean the [IPv6] TLV, when carried in the IIH, carries a link-local address?

4) The IPv6 Global Interface Address TLV can carry either a global or a site-local address. Well, when it is carrying a site-local address, isn't this poorly named? and since, according to section 2, IS-IS doesn't differentiate between global and site-local, making it sound like it is "global" is misleading. Would this be better called something like IPv6 Remote Interface Address or IPv6 Peer Interface Address?

5) in 3.2.5, "the SRLG TLV defined in [GMPLS] identifies the corresponding link". Actually, RFC5307 never mentions the word "corresponding". and the text doesn't explain "corresponding to what". The langauge should be made more consistent with RFC 5307.

6) in 3.2.5, I am not quite sure what "either of these means" refers to. Is the flag one of these means? or is the flag irrelevant, and the "means of identification" the contents of the SRLG TLV? This is a NIT, but it reflects the looseness of the text in this document.

There is an assertion that there is no backward-compatible way to encode an IPv6 address into a SLRG TLV. It seems unfortunate that RFC5307 was also written rather loosely, and apparently all the reserved bits of the Flags field that "should be set to zero" could actually be set to anything because there is no text specifying what should happen if the bits are not set to zero. Otherwise, we might have been able to use a flag bit to specify support for IPv6 addressing, and provided a list of 4 4-octet values to carry an IPv6 address.

7) in 4.1, we seem to be EXTREMELY loose with compliance requirements.

If you do not implement traffic engineering, you MAY include or omit this TLV. This TLV is designed to do traffic engineering; why would anybody include it if they don't do traffic engineering? What should a receiving entity do if this IS included whenn  traffic engineering is not supported? ignore it? What this does from an engineering perspective is invite implmenters to overload this TLV for purposes for which it is not being designed. and that can lead to problems down the road. I think this should be a MUST NOT.

A stable, global or site-local address SHOULD be used; so what are the exceptions that justify a SHOULD? When exactly does it make sense to use an unstable address or a link-local address in this TLV? Why is this not a MUST?

Let me point out that section 3.2.1 says the IPv4 Router ID TLV contains a stable address, not that it SHOULD contain a stable address. RFC 5305 says
  The router ID is useful for traffic engineering purposes because it
  describes a single address that can always be used to reference a
  particular router.
I interpret that "always" as meaning it MUST be a stable address.

This TLV MUST NOT be included more than once [but if you do then] all except the first must be ignored. If this is a MUST NOT, why not return an error or throw the thing away if the implementer is not compliant to the MUST NOT? What is the benefit to allowing an implementer to send multiple TLVs if all but the first will be ignored? So what are the security risks of allowing a sender (or a man-in-the-middle) to send extra TLVs that will be ignored? Could I maybe use this unchecked space in IS-IS messages to transport malware? The security considerations sections doesn't mention anything about this.

8) in 4.1, If "injecting" a /128 prefix into routing table is a really bad thing to do, is this something that an implementation of the TLV should detect and prevent? I am not quite sure which actor should take which action here. What values should a TLV sender not send? How should a receiver act if they get such a bad value? 

9) in 4.2, what is the (main) TLV? why not use the approrpiate name for the TLV?

10) in 4.4, the flags handling has been tightened - good. Instead of saying it must be 0 or 1 or discard the TLV, you might want to say if a bit is non-zero that the receiver does not understand then discard the TLV. This way, you could add new functionality identified by flags not defined in this document. If you do this, you should create a registry for the flags to control and coordinate flag bit semantics.

Have you considered duplicating the functionality of type 138 in type 139 with an eye to replacing 138 with a more extensible type? The existing flag usage from type 138 could be preserved; additional Flag bits could be used to specify whether the interface and neighbor addresses are IPv4 or IPv6. While you can not achieve backwards compatibility, you can achieve forward compatibility to a more extensible replacement type, and deprecate 138 usage.

11) in 4.4, What should a receiver do if the IPv6 SRLG (139) is used when an IPv4 SRLG (138) could have been used? Is the MUST enforceable? Is this detectable? Is this an error? should the TLV be discarded?

If the problem is possible contradiction, why not specify that if both are received, then the receiver MUST ignore the IPv6 SRLG and apply the IPv4 SRLG? (although since IPv6 use is expected to grow while IPv4 use lessens, and you've made the IPv6 SRLG TLV extensible, and an extended IPv6 SRLG TLV might be more useful than the legacy limited-extensibility IPv4 SRLG, favoring the IPv6 SRLG might make more sense).

[Ballot comment]
Several acronyms are not expanded on first use (e.g., TLV, LSP, IIH, PDU). The RFC Editor will ask that you expand them, so you might as well start working on that task now. :)

IANA comments:

Upon approval of this document, IANA understands that it has two actions
it needs to complete.

First, in the IS-IS TLV Codepoints Registry located at
http://www.iana.org/assignments/isis-tlv-codepoints
IANA must register three new codepoints as follows:

Type Description IIH LSP SNP
---- ---------------------- --- --- ---
139 IPv6 SRLG TLV n y n
140 IPv6 TE Router ID n y n
233 IPv6 Global Interface y n n
Address TLV

Second, in the Registry for Sub-TLVs for TLV 22, 141, and 222 located at
http://www.iana.org/assignments/isis-tlv-codepoints
IANA must register two new sub-TLV types for the top-level TLV 22 as
follows:

Type Description Length
---- ------------------------------ --------
12 IPv6 Interface Address 16
13 IPv6 Neighbor Address 16

IANA understands that these two actions are the only registrations that
need be completed upon approval of this document.

PROTO writeup for: draft-ietf-isis-ipv6-te-07.txt by Chris Hopps:

Shepherding WG-Chair: Chris Hopps (chopps@rawdofmt.org)

    Q1) Have the chairs personally reviewed this version of the
    Internet Draft (ID), and in particular, do they believe
    this ID is ready to forward to the IESG for publication?

A1) Yes.

    Q2) Has the document had adequate review from both key WG
    members and key non-WG members? Do you have any concerns
    about the depth or breadth of the reviews that have been
    performed?

A2) Adequately reviewed.

    Q3) Do you have concerns that the document needs more review
    from a particular (broader) perspective (e.g., security,
    operational complexity, someone familiar with AAA, etc.)?

A3) No concerns.

    Q4) Do you have any specific concerns/issues with this
    document that you believe the ADs and/or IESG should be
    aware of? For example, perhaps you are uncomfortable with
    certain parts of the document, or have concerns whether
    there really is a need for it. In any event, if your issues
    have been discussed in the WG and the WG has indicated it
    that it still wishes to advance the document, detail those
    concerns in the write-up.

A4) No concerns.

    5) How solid is the WG consensus behind this document? Does
    it represent the strong concurrence of a few individuals,
    with others being silent, or does the WG as a whole understand
    and agree with it?

A5) Strong Consensus.

    6) Has anyone threatened an appeal or otherwise indicated
    extreme discontent? If so, please summarise the areas of
    conflict in separate email to the Responsible Area Director.

A6) No.

    7) Have the chairs verified that the document adheres to
    all of the ID Checklist items ?

A7) Yes.

    8) Is the document split into normative and informative
    references?  Are there normative references to IDs, where
    the IDs are not also ready for advancement or are otherwise
    in an unclear state? (note here that the RFC editor will
    not publish an RFC with normative references to IDs, it
    will delay publication until all such IDs are also ready
    for publication as RFCs.)

A8) Yes.

    9) What is the intended status of the document? (e.g.,
    Proposed Standard, Informational?)

A9) Proposed Standard.

*** Write-up

** Technical Summary

This specification provides the ability to provide IPv6 traffic engineering
information within IS-IS. The design very closely parallels the IPv4
specification.

** Working Group Summary

There consensus was strong for this specification. There was very little
discussion as the implementation and need were fairly obvious.

** Protocol Quality

There are currently no known implementations of this specification. The
quality of the protocol extension though can easily be measured by it's
analogous IPv4 implementation which is widely implemented.