BGP Traffic Engineering Attribute
draft-ietf-softwire-bgp-te-attribute-04

[Ballot comment]
Section 3:

  When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
  the Switching Capability specific information field includes Minimum
  LSP Bandwidth and Interface MTU.

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Minimum LSP Bandwidth                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Interface MTU      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE
  floating point format.  The units are bytes (not bits!) per second.
  The Interface MTU is encoded as a 2 octet integer.

I don't think this text is that clear. First of all, is the MTU value in octets or bits? I also assume that it is an unsigned integer, rather than a signed which the current language defaults to.

The I wonder, is it clear on what level the MTU measurement is performed on. I know to little about what is actually represented by PSC-1 to PSC-4 to determine if the point in the stack the measurement is taken is always clear.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignment in the "BGP Path Attributes" registry at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

Value Code Reference
---- ---- ---------
TBD Traffic Engineering [RFC-softwire-bgp-te-attribute-03]

We understand the above to be the only IANA Action for this document.

draft-ietf-softwire-bgp-te-attribute-03.txt

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) 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? Which chair is the WG
Chair Shepherd for this document?

Dave Ward

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

No.

1.d) 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.

No.

1.e) 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?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) 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. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area
Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Protocol write-up for:
by Dave Ward, dward@cisco.com

Technical Summary

This document defines a new BGP attribute, Traffic Engineering
attribute, than enables BGP to carry Traffic Engineering
information.

The scope and applicability of this attribute currently excludes its
use for non-VPN reachability information.


Working Group Summary

The SOFTWIRE WG supports the development and advancement of this
document.


Protocol Quality

This document was thoroughly reviewed by WG chairs and WG members,
including those with expertise in IPv4 to IPv6 transitions and
interworking.

Dave Ward is the WG chair shepherd. Mark Townsley is the
responsible Area
director.