Internet DRAFT - draft-farrel-ccamp-ero-survey
draft-farrel-ccamp-ero-survey
Network Working Group Adrian Farrel
Internet Draft Old Dog Consulting
Category: Informational
Expiration Date: November 2006 May 2006
Informal Survey into Explicit Route Object Implementations in
Generalized Multiprotocol Labels Switching Signaling Implementations
<draft-farrel-ccamp-ero-survey-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
During discussions of a document to provide guidance on the use of
addressing fields within the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) signaling protocol used in Generalized
Multiprotocol Label Switching (GMPLS), it was determined that there
was considerable variation in the implementation of options for the
Explicit Route Object (ERO).
Since there was a proposal to deprecate some of the options, it was
felt necessary to conduct a survey of the existing and planned
implementations.
This document summarizes the survey questions and captures the
results. Some conclusions are also presented.
This survey was informal and conducted via email. Responses were
collected and anonymized by the CCAMP working group chair.
A. Farrel [Page 1]
draft-farrel-ccamp-ero-survey-00.txt May 2006
1. Introduction
[GMPLS-ADDR] documents advice and procedures for filling in protocol
fields that contain addresses within the signaling and routing
protocols in the Generalized Multiprotocol Label Switching (GMPLS)
protocol family.
The Resource Reservation Protocol (RSVP) [RFC2205] has been extended
as RSVP for Traffic Engineering (RSVP-TE) for use in Multiprotocol
Label Switching (MPLS) signaling [RFC3209] and Generalized MPLS
(GMPLS) [RFC3473].
[RFC3209] defines the Explicit Route Object (ERO) to encode the
explicit path of a Label Switched Path (LSP) through the network.
This object and its encoding rules are inherited by [RFC3473], but
further details specific to GMPLS are added in [RFC3473] under the
guidance of [RFC3471]. [RFC4201] introduces additional
GMPLS-specific ERO encodings. In total there are many options
about how an ERO may be constructed, and therefore some confusion
about what EROs a Label Switching Router (LSR) may construct and
what ERO formats an LSR must be able to process.
During discussion of [GMPLS-ADDR] it was proposed that unused and
unwanted options for ERO construction within the existing RFCs be
deprecated. However, it was unclear which options were commonly
supported, which were used, and which might be safely deprecated.
In order to discover the current state of affairs amongst
implementations a survey of the existing and planned implementations
was conducted. This survey was informal and conducted via email.
Responses were collected and anonymized by the CCAMP working group
chair.
This document summarizes the survey questions and captures the
results. Some conclusions are also presented.
2. Survey Details
2.1. Survey Preamble
The survey was introduced with the following text.
In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03
we determined that implementations must support any form of ERO that
is legitimately sent by any other implementation. At the same time
there is a desire to reduce the number of options if this is
possible. Lastly, there was some confusion about what the RFCs
actually allow you to do, and rather than debate this as though we
were lawyers, it may be more profitable to look at what current
implementations do.
A. Farrel [Page 2]
draft-farrel-ccamp-ero-survey-00.txt May 2006
Obviously we can do further work on this if/when RFCs 3209, 3471 and
3473 go to Draft Standard.
To move things forward, I would like to do an informal and
*confidential* survey of current implementations.
Please respond to each question below with, Yes / No / NA. NA would
largely apply where the implementation is found on a NE where the
technology makes the ERO option inappropriate.
Send your responses to me and not to the mailing lists (unless you
fancy the publicity).
Thanks,
Adrian
2.2. Survey Questions
The following two survey questions were asked.
1. EROs built for use on Path messages
For each hop in the path, which of the following options does
your implementation utilize?
This question applies to EROs that your implementations
construct, NOT to EROs that you forward.
a. IP Address with non-full prefix length specifying a group of
nodes
b. AS number
c. TE Router ID
d. Incoming TE link ID
e. Outgoing TE link ID
f. Outgoing TE link ID followed by one or two Label subobjects
g. Outgoing TE link ID followed by Component Interface ID
subobject
h. Outgoing TE link ID followed by Component Interface ID
subobject and one or two Label subobjects
i. TE Router ID and Outgoing TE link ID
j. TE Router ID and Outgoing TE link ID followed by one or two
Label subobjects
A. Farrel [Page 3]
draft-farrel-ccamp-ero-survey-00.txt May 2006
k. TE Router ID and Outgoing TE link ID followed by Component
Interface ID subobject
l. TE Router ID and Outgoing TE link ID followed by Component
Interface ID subobject and one or two Label subobjects
m. Incoming TE link ID and Outgoing TE link ID
n. Incoming TE link ID and Outgoing TE link ID followed by one
or two Label subobjects
o. Incoming TE link ID and Outgoing TE link ID followed by
Component Interface ID subobject
p. Incoming TE link ID and Outgoing TE link ID followed by
Component Interface ID subobject and one or two Label
subobjects
q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
followed by one or two Label subobjects
s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
followed by Component Interface ID subobject
t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
followed by Component Interface ID subobject and one or two
Label subobjects
2. EROs received from the previous hop on Path messages
Which *top* subobjects in the ERO does your implementation
support receiving?
This question applies to ERO subobjects that your
implementations must handle, NOT to ERO subobjects that you
forward.
a. IP Address with non-full prefix length specifying a group of
nodes
b. AS number
c. TE Router ID
d. Incoming TE link ID
e. Outgoing TE link ID
f. Outgoing TE link ID followed by one or two Label subobjects
A. Farrel [Page 4]
draft-farrel-ccamp-ero-survey-00.txt May 2006
g. Outgoing TE link ID followed by Component Interface ID
subobject
h. Outgoing TE link ID followed by Component Interface ID
subobject and one or two Label subobjects
i. TE Router ID and Outgoing TE link ID
j. TE Router ID and Outgoing TE link ID followed by one or two
Label subobjects
k. TE Router ID and Outgoing TE link ID followed by Component
Interface ID subobject
l. TE Router ID and Outgoing TE link ID followed by Component
Interface ID subobject and one or two Label subobjects
m. Incoming TE link ID and Outgoing TE link ID
n. Incoming TE link ID and Outgoing TE link ID followed by one
or two Label subobjects
o. Incoming TE link ID and Outgoing TE link ID followed by
Component Interface ID subobject
p. Incoming TE link ID and Outgoing TE link ID followed by
Component Interface ID subobject and one or two Label
subobjects
q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
followed by one or two Label subobjects
s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
followed by Component Interface ID subobject
t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
followed by Component Interface ID subobject and one or two
Label subobjects
3. Respondents
Responses were received from 9 vendors, one software house, and one
research lab. Two vendors made responses for their current products
and for the products that they currently have under development.
Thus there were a total of 13 responses.
Responses to questions from all respondents were clear yes or no
answers. The option of N/A (not applicable) was never used.
A. Farrel [Page 5]
draft-farrel-ccamp-ero-survey-00.txt May 2006
4. Results
This section breaks the results down by respondent category and then
shows an overall table of all results.
4.1. Vendors' Current Products
| Responding vendors | |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |Totals|
---+---+---+---+---+---+---+---+---+---+------+
1a | N | N | N | N | Y | Y | N | N | N | 2/9 |
1b | N | N | N | N | Y | N | N | N | N | 1/9 |
1c | Y | N | Y | N | Y | Y | N | Y | Y | 6/9 |
1d | Y | N | N | N | Y | Y | N | N | Y | 4/9 |
1e | Y | Y | Y | N | Y | Y | N | N | Y | 6/9 |
1f | Y | N | Y | N | Y | Y | N | N | N | 4/9 |
1g | Y | Y | N | N | Y | N | N | N | N | 3/9 |
1h | Y | Y | N | N | Y | N | N | N | N | 3/9 |
1i | Y | N | Y | Y | Y | Y | N | N | Y | 6/9 |
1j | Y | N | Y | N | Y | Y | N | N | Y | 5/9 |
1k | Y | N | N | Y | Y | N | N | N | Y | 4/9 |
1l | Y | N | N | Y | Y | N | N | N | Y | 4/9 |
1m | N | N | N | N | Y | N | Y | N | N | 2/9 |
1n | N | N | N | N | Y | N | Y | N | N | 2/9 |
1o | N | N | N | N | Y | N | Y | N | N | 2/9 |
1p | N | N | N | N | Y | N | Y | N | N | 2/9 |
1q | N | N | N | N | Y | N | N | N | N | 1/9 |
1r | N | N | N | N | Y | N | N | N | N | 1/9 |
1s | N | N | N | N | Y | N | N | N | N | 1/9 |
1t | N | N | N | N | Y | N | N | N | N | 1/9 |
---+---+---+---+---+---+---+---+---+---+------+
2a | N | N | N | N | Y | N | N | N | N | 1/9 |
2b | Y | N | N | N | Y | Y | N | N | N | 3/9 |
2c | Y | N | Y | N | Y | Y | Y | Y | Y | 6/9 |
2d | Y | N | N | N | Y | Y | Y | N | Y | 5/9 |
2e | Y | Y | Y | N | Y | Y | N | N | Y | 6/9 |
2f | Y | N | Y | N | Y | Y | N | N | N | 4/9 |
2g | Y | Y | N | N | Y | N | N | N | N | 3/9 |
2h | Y | Y | N | N | Y | N | N | N | N | 3/9 |
2i | Y | N | Y | Y | Y | Y | Y | N | Y | 7/9 |
2j | Y | N | Y | Y | Y | Y | Y | N | Y | 7/9 |
2k | Y | N | N | Y | Y | N | Y | N | Y | 5/9 |
2l | Y | N | N | Y | Y | N | Y | N | Y | 5/9 |
2m | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2n | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2o | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2p | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2q | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2r | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2s | Y | N | N | N | Y | N | Y | N | N | 3/9 |
2t | Y | N | N | N | Y | N | Y | N | N | 3/9 |
A. Farrel [Page 6]
draft-farrel-ccamp-ero-survey-00.txt May 2006
4.2. Vendors' Development Products
This section shows the responses for the two vendors who supplied
details of their products under development. The 'modified totals'
column shows the impact on the totals in the table in section 4.1
of replacing the vendors' entries with those in the table in this
section.
|vendors| ||Modified|
| 1 | 2 |Totals|| Totals |
---+---+---+------++--------+
1a | N | N | 0 || 2/9 |
1b | N | Y | 1 || 2/9 |
1c | Y | Y | 2 || 6/9 |
1d | N | N | 0 || 4/9 |
1e | Y | N | 1 || 6/9 |
1f | Y | N | 1 || 4/9 |
1g | N | N | 0 || 3/9 |
1h | N | N | 0 || 3/9 |
1i | Y | Y | 2 || 7/9 |
1j | Y | N | 1 || 5/9 |
1k | N | N | 0 || 4/9 |
1l | N | N | 0 || 4/9 |
1m | N | N | 0 || 2/9 |
1n | N | N | 0 || 2/9 |
1o | N | N | 0 || 2/9 |
1p | N | N | 0 || 2/9 |
1q | N | N | 0 || 1/9 |
1r | N | N | 0 || 1/9 |
1s | N | N | 0 || 1/9 |
1t | N | N | 0 || 1/9 |
---+---+---+------++--------+
2a | N | N | 0 || 1/9 |
2b | N | Y | 1 || 4/9 |
2c | Y | Y | 2 || 6/9 |
2d | Y | N | 1 || 6/9 |
2e | Y | N | 1 || 6/9 |
2f | Y | N | 1 || 4/9 |
2g | N | N | 0 || 3/9 |
2h | N | N | 0 || 3/9 |
2i | Y | Y | 2 || 8/9 |
2j | Y | N | 1 || 7/9 |
2k | N | N | 0 || 5/9 |
2l | N | N | 0 || 5/9 |
2m | Y | N | 1 || 4/9 |
2n | Y | N | 1 || 4/9 |
2o | N | N | 0 || 3/9 |
2p | N | N | 0 || 3/9 |
2q | Y | N | 1 || 4/9 |
2r | Y | N | 1 || 4/9 |
2s | N | N | 0 || 3/9 |
2t | N | N | 0 || 3/9 |
A. Farrel [Page 7]
draft-farrel-ccamp-ero-survey-00.txt May 2006
4.3. Software and Research Implementations
Separating these results into a separate section is in no way
intended to imply that these implementations are any more or less
valid.
|software|research|Total|
---+--------+--------+-----+
1a | Y | N | 1 |
1b | Y | N | 1 |
1c | Y | Y | 2 |
1d | Y | N | 1 |
1e | Y | Y | 2 |
1f | Y | N | 1 |
1g | Y | N | 1 |
1h | Y | N | 1 |
1i | Y | Y | 2 |
1j | Y | Y | 2 |
1k | Y | N | 1 |
1l | Y | N | 1 |
1m | Y | N | 1 |
1n | Y | N | 1 |
1o | Y | N | 1 |
1p | Y | N | 1 |
1q | Y | N | 1 |
1r | Y | N | 1 |
1s | Y | N | 1 |
1t | Y | N | 1 |
---+--------+--------+-----+
2a | Y | N | 1 |
2b | Y | N | 1 |
2c | Y | Y | 2 |
2d | Y | N | 1 |
2e | Y | Y | 2 |
2f | Y | N | 1 |
2g | Y | N | 1 |
2h | Y | N | 1 |
2i | Y | Y | 2 |
2j | Y | Y | 2 |
2k | Y | N | 1 |
2l | Y | N | 1 |
2m | Y | N | 1 |
2n | Y | N | 1 |
2o | Y | N | 1 |
2p | Y | N | 1 |
2q | Y | N | 1 |
2r | Y | N | 1 |
2s | Y | N | 1 |
2t | Y | N | 1 |
A. Farrel [Page 8]
draft-farrel-ccamp-ero-survey-00.txt May 2006
4.4. Grand Totals
This section presents totals for the vendor implementations, the
software implementation, and the research implementation. Where a
vendor submitted a response for a current and future product, only
the response for the future product has been counted.
| Grand |
| Totals |
---+---------+
1a | 3/11 |
1b | 3/11 |
1c | 8/11 |
1d | 5/11 |
1e | 8/11 |
1f | 5/11 |
1g | 4/11 |
1h | 4/11 |
1i | 9/11 |
1j | 7/11 |
1k | 5/11 |
1l | 5/11 |
1m | 3/11 |
1n | 3/11 |
1o | 3/11 |
1p | 3/11 |
1q | 2/11 |
1r | 2/11 |
1s | 2/11 |
1t | 2/11 |
---+---------+
2a | 2/11 |
2b | 5/11 |
2c | 8/11 |
2d | 7/11 |
2e | 8/11 |
2f | 5/11 |
2g | 4/11 |
2h | 4/11 |
2i | 10/11 |
2j | 9/11 |
2k | 6/11 |
2l | 6/11 |
2m | 5/11 |
2n | 5/11 |
2o | 4/11 |
2p | 4/11 |
2q | 5/11 |
2r | 5/11 |
2s | 4/11 |
2t | 4/11 |
A. Farrel [Page 9]
draft-farrel-ccamp-ero-survey-00.txt May 2006
5. Conclusions
The results shown in this survey are not wholly conclusive. They
suggest that all options may be generated by some implementations
and that some options are commonly available. At the same time, the
results show that the support for received options is patchy with
few implementations supporting a wide choice of received ERO options
and only two options (i and j - TE Router ID with Outgoing TE link
ID, and TE Router ID with Outgoing TE link ID followed by one or two
Label subobjects) being widely supported.
Results for options containing Component Link IDs (g, h, k, l, o, p,
s, and t) should be treated with some caution as support for these
options requires support for link bundling [RFC4201] which is an
implementation option on any device. A device that does not support
link bundling would not ever need to process these ERO options.
(Properly, many responses should have used 'N/A' and not 'No' for
these options.)
Interoperability would appear, from these results, to be a tough
objective to achieve. In order to successfully complete wide
interoperability at least one of the following options must be
adopted:
- Some implementations stop generating certain ERO options that
are not widely supported.
- Some implementations start to support certain ERO options that
are widely generated.
5.1. Proposed Action
The proposed action is as follows:
- No change is made to the protocols defined in [RFC3209], [RFC3471],
[RFC3473] and [RFC4201] at this time.
- [GMPLS-ADDR] continues to specify the availability of all options
on EROs that are generated
- [GMPLS-ADDR] continues to recommend that implementations support
the receipt of all ERO options applicable to their hardware
capabilities
- Implementations generate only those ERO options that they really
require
- A future survey is carried out when there is a plan to advance
the protocol RFCs to Draft Standard. This future survey should aim
to determine deployment experience as opposed to implementation
experience.
6. IANA Considerations
This informational document makes no requests to IANA for action.
A. Farrel [Page 10]
draft-farrel-ccamp-ero-survey-00.txt May 2006
7. Security Considerations
This survey defines no protocols or procedures and so includes no
security-related protocol changes.
Reductions in the supported ERO options will not have any negative
security impact, and removing options might possibly improve the
security of GMPLS signaling if there exist any undiscovered issues
with the retired options.
The survey responses in this document were collected by email and
that email was not authenticated, although responses were sent to
the respondents that might have triggered alarms if the responses
were spoofed. Spoofed or malicious responses could represent an
attack on the IETF process and so this survey should be treated
with some caution where there is reason to suspect such an attack.
Further, this survey was compiled and anonymized by a single
individual who, although (or perhaps because) he is a working group
chair, cannot necessarily be trusted. Thus, the IETF process is
open to an attack by this individual.
8. References
8.1 Normative References
[GMPLS-ADDR] Shiomoto, K., Papneja, R., and Rabbat, R., "Use of
Addresses in Generalized Multi-Protocol Label Switching
(GMPLS) Networks", draft-ietf-ccamp-gmpls-addressing,
work in progress.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205,
September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4201] Kompella, K., Rekhter, Y. and Berger, L. "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
A. Farrel [Page 11]
draft-farrel-ccamp-ero-survey-00.txt May 2006
9. Author's Address
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
10. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
11. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
A. Farrel [Page 12]
