draft-ietf-forces-protoextension-05.txt   draft-ietf-forces-protoextension-06.txt 
Internet Engineering Task Force J. Hadi Salim Internet Engineering Task Force J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Updates: 7121,5810 (if approved) August 18, 2014 Updates: 7121,5810 (if approved) September 9, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: February 19, 2015 Expires: March 13, 2015
ForCES Protocol Extensions ForCES Protocol Extensions
draft-ietf-forces-protoextension-05 draft-ietf-forces-protoextension-06
Abstract Abstract
Experience in implementing and deploying ForCES architecture has Experience in implementing and deploying ForCES architecture has
demonstrated need for a few small extensions both to ease demonstrated need for a few small extensions both to ease
programmability and to improve wire efficiency of some transactions. programmability and to improve wire efficiency of some transactions.
This documents updates both RFC 5810 and RFC 7121 semantics to The ForCES protocol is extended with a table range operation and a
achieve that end goal. new extension for error handling. This documents updates both RFC
5810 and RFC 7121 semantics to achieve that end goal.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 19, 2015. This Internet-Draft will expire on March 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 29
3.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Private Vendor Codes . . . . . . . . . . . . . . . . . 8 3.2.2. Private Vendor Codes . . . . . . . . . . . . . . . . . 8
3.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8 3.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8
3.2.3.1. Extended Result Backward compatibility . . . . . . 9 3.2.3.1. Extended Result Backward compatibility . . . . . . 9
3.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 10 3.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 10
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 14 Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Experience in implementing and deploying ForCES architecture has Experience in implementing and deploying ForCES architecture has
demonstrated need for a few small extensions both to ease demonstrated need for a few small extensions both to ease
programmability and to improve wire efficiency of some transactions. programmability and to improve wire efficiency of some transactions.
This document describes a few extensions to the ForCES Protocol This document describes a few extensions to the ForCES Protocol
Specification [RFC5810] semantics to achieve that end goal. Specification [RFC5810] semantics to achieve that end goal.
This document describes and justifies the need for 2 small extensions This document describes and justifies the need for 2 small extensions
which are backward compatible. The document also clarifies details which are backward compatible. The document also clarifies details
of how dumping of a large table residing on an FE is achieved. To of how dumping of a large table residing on an FE (Forwarding Engine)
summarize: is achieved. To summarize:
1. A table range operation to allow a controller or control 1. A table range operation to allow a controller or control
application to request an arbitrary range of table rows is application to request an arbitrary range of table rows is
introduced. introduced.
2. Additional error codes returned to the controller (or control 2. Additional error codes returned to the controller (or control
application) by an FE are introduced. Additionally a new application) by an FE are introduced. Additionally a new
extension to carry details on error codes is introduced. As a extension to carry details on error codes is introduced. As a
result the (FE Protocol Object) FEPO LFB is updated over the result the (FE Protocol Object) FEPO LFB is updated over the
definition in [RFC7121]. definition in [RFC7121].
skipping to change at page 5, line 5 skipping to change at page 5, line 5
control app) are prepended with a path to a component and sent to the control app) are prepended with a path to a component and sent to the
FE. In the case of indexed tables, the component path can either FE. In the case of indexed tables, the component path can either
point to a table or a table row index. point to a table or a table row index.
As an example, a control application attempting to retrieve the first As an example, a control application attempting to retrieve the first
2000 table rows appearing between row indices 23 and 10023 can 2000 table rows appearing between row indices 23 and 10023 can
achieve its goal in one of: achieve its goal in one of:
o Dump the whole table and filter for the needed 2000 table rows. o Dump the whole table and filter for the needed 2000 table rows.
o Send upto 10000 ForCES PL requests with monotonically incrementing o Send upto 10000 ForCES PL requests, incrementing the index by one
indices and stop when the needed 2000 entries are retrieved. each time, and stop when the needed 2000 entries are retrieved.
o If the application had knowledge of which table rows existed (not o If the application had knowledge of which table rows existed (not
unreasonable given the controller is supposed to be aware of state unreasonable given the controller is supposed to be aware of state
within an NE), then the application could take advantage of ForCES within an NE), then the application could take advantage of ForCES
batching to send fewer large messages (each with different path batching to send fewer large messages (each with different path
entries for a total of two thousand). entries for a total of two thousand).
As argued, while the above options exist - all are tedious. As argued, while the above options exist, all are tedious.
2.2. Error codes 2.2. Error codes
[RFC5810] has defined a generic set of error codes that are to be [RFC5810] has defined a generic set of error codes that are to be
returned to the CE from an FE. Deployment experience has shown that returned to the CE from an FE. Deployment experience has shown that
it would be useful to have more fine grained error codes. As an it would be useful to have more fine grained error codes. As an
example, the error code E_NOT_SUPPORTED could be mapped to many FE example, the error code E_NOT_SUPPORTED could be mapped to many FE
error source possibilities that need to be then interpreted by the error source possibilities that need to be then interpreted by the
caller based on some understanding of the nature of the sent request. caller based on some understanding of the nature of the sent request.
This makes debugging more time consuming. This makes debugging more time consuming.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as
defined in RFC 5810) MUST be set to indicate the presence of the defined in RFC 5810) MUST be set to indicate the presence of the
TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a
GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST
enforce the path flag constraints and ensure that the selected path enforce the path flag constraints and ensure that the selected path
belongs to a defined indexed table component. Any violation of these belongs to a defined indexed table component. Any violation of these
constraints MUST be rejected with an error code of E_INVALID_TFLAGS constraints MUST be rejected with an error code of E_INVALID_TFLAGS
with a description of what the problem is when using extended error with a description of what the problem is when using extended error
reporting (refer to Section 3.2). reporting (refer to Section 3.2).
It should be noted thata there are combination of path selection It should be noted that there are combination of path selection
mechanisms that should not appear together for the sake of simplicity mechanisms that should not appear together for the sake of simplicity
of operations. These include: TABLERANGE-TLV and KEYINFO-TLV as well of operations. These include: TABLERANGE-TLV and KEYINFO-TLV as well
as multiple nested TABLERANGE-TLVs. as multiple nested TABLERANGE-TLVs.
The TABLERANGE-TLV contents constitute: The TABLERANGE-TLV contents constitute:
o A 32 bit start index. An index of 0 implies the beginning of the o A 32 bit start index. An index of 0 implies the beginning of the
table row. table row.
o A 32 bit end index. A value of 0xFFFFFFFF implies the last entry. o A 32 bit end index. A value of 0xFFFFFFFF implies the last entry.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to
be 32 bit aligned. be 32 bit aligned.
o The EXTENDEDRESULT-TLV Result Value derives and extends from the o The EXTENDEDRESULT-TLV Result Value derives and extends from the
same current namespace that is used by RESULT-TLV Result Value as same current namespace that is used by RESULT-TLV Result Value as
specified in RFC 5810, section 7.1.7. The main difference is that specified in RFC 5810, section 7.1.7. The main difference is that
we now have a 32 bit result value (as opposed to old 8 bit). we now have a 32 bit result value (as opposed to old 8 bit).
o The optional result content is defined to further disambiguate the o The optional result content is defined to further disambiguate the
result value. It is expected UTF-8 string values to be used. result value. It is expected UTF-8 string values to be used. The
However, vendor specific error codes may choose to specify content result value is intended to be consumed by the (human)
different contents. Additionally, future codes may specify cause operator and implementations may choose to specify different
contents to be of types other than string. contents for the same error code. Additionally, future codes may
specify cause contents to be of types other than string.
o It is recommended that the maximum size of the cause string should o It is recommended that the maximum size of the cause string should
not exceed 32 bytes. We do not propose the cause string be not exceed 32 bytes. The cause string is not standardized by this
standardized. document.
3.2.3.1. Extended Result Backward compatibility 3.2.3.1. Extended Result Backward compatibility
To support backward compatibility, we update and the FEPO LFB (in To support backward compatibility, we update and the FEPO LFB (in
Appendix A) version to 1.2. We also add a new component ID 16 (named Appendix A) version to 1.2. We also add a new component ID 16 (named
EResultAdmin) and a capability Component ID 32 (named EResultCapab). EResultAdmin) and a capability Component ID 32 (named EResultCapab).
An FE will advertise its capability to support extended TLVs via the An FE will advertise its capability to support extended TLVs via the
EResultCapab table. When an FE is capable of responding with both EResultCapab table. When an FE is capable of responding with both
extended results and older result TLVs, it will have two table rows extended results and older result TLVs, it will have two table rows
skipping to change at page 10, line 15 skipping to change at page 10, line 15
3.3. Large Table Dumping 3.3. Large Table Dumping
Imagine a GET request to a path that is a table i.e a table dump. Imagine a GET request to a path that is a table i.e a table dump.
Such a request is sent to the FE with a specific correlator, say X. Such a request is sent to the FE with a specific correlator, say X.
Imagine this table to have a large number of entries at the FE. For Imagine this table to have a large number of entries at the FE. For
the sake of illustration, lets say millions of rows. This requires the sake of illustration, lets say millions of rows. This requires
that the FE delivers the response over multiple messages, all using that the FE delivers the response over multiple messages, all using
the same correlator X. the same correlator X.
The protocol document [RFC5810] does not adequately describe how a The protocol document [RFC5810] does not adequately describe how a
GET response to such a large message is delivered. The text in this large multi-part GET response message is delivered. The text in this
section clarifies. We limit the discussion to a table object only. section clarifies. We limit the discussion to a table object only.
Implementation experience of dumping large tables indicates we can Implementation experience of dumping large tables indicates we can
use the transaction flags to indicate that a GET response is the use the transaction flags to indicate that a GET response is the
beginning, middle or end of a multi-part message. In other words we beginning, middle or end of a multi-part message. In other words we
mirror the effect of an atomic transaction sent by a CE to an FE. mirror the effect of an atomic transaction sent by a CE to an FE.
CE PL FE PL CE PL FE PL
| | | |
skipping to change at page 11, line 44 skipping to change at page 11, line 44
| DATA TLV (SPARSE/FULL) | | DATA TLV (SPARSE/FULL) |
| | | |
| (N) Query-Response, EOT,AT, OP=GET-RESPONSE | | (N) Query-Response, EOT,AT, OP=GET-RESPONSE |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| correlator = X | | correlator = X |
| RESULT TLV (SUCCESS) | | RESULT TLV (SUCCESS) |
| | | |
Figure 4: EXTENDEDRESULT-TLV Figure 4: EXTENDEDRESULT-TLV
The last message which carries the EOT flag to go the CE MUST NOT The last message to go to the CE, which carries the EOT flag, MUST
carry any data. This allows us to mirror ForCES 2PC messaging NOT carry any data. This allows us to mirror ForCES 2PC messaging
[RFC5810] where the last message is an empty commit message. GET [RFC5810] where the last message is an empty commit message. GET
response will carry a result code TLV in such a case. response will carry a result code TLV in such a case.
4. Acknowledgements 4. Acknowledgements
The author would like to thank Evangelos Haleplidis and Joel Halpern The author would like to thank Evangelos Haleplidis and Joel Halpern
for discussions that made this document better. Adrian Farrel did an for discussions that made this document better. Adrian Farrel did an
excellent AD review of the document which improved the quality of excellent AD review of the document which improved the quality of
this document. Tobias Gondrom did the Security Directorate review. this document. Tobias Gondrom did the Security Directorate review.
Brian Carpenter did the Gen-ART review. Nevil Brownlee performed the Brian Carpenter did the Gen-ART review. Nevil Brownlee performed the
Operations Directorate review. S Moonesamy(SM) worked hard to review Operations Directorate review. S Moonesamy(SM) worked hard to review
our publication process. Perl Liang caught issues in the IANA our publication process. Pearl Liang caught issues in the IANA
specification. specification.
The author would like to thank the following IESG members who
reviewed and improved this document: Alia Atlas, Barry Leiba, Brian
Haberman, Kathleen Moriarty, Richard Barnes, and Spencer Dawkins.
5. IANA Considerations 5. IANA Considerations
This document registers two new top Level TLVs and two new path flags This document registers two new top Level TLVs and two new path flags
and updates an IANA registered FE Protocol object Logical Functional and updates an IANA registered FE Protocol object Logical Functional
Block (LFB). Block (LFB).
The Appendix A defines an update to the FE Protocol Object LFB to The Appendix A defines an update to the FE Protocol Object LFB to
version 1.2. The IANA registry version 1.2. The IANA registry
https://www.iana.org/assignments/forces sub-registy "Logical https://www.iana.org/assignments/forces sub-registy "Logical
Functional Block (LFB) Class Names and Class Identifiers" will need Functional Block (LFB) Class Names and Class Identifiers" will need
skipping to change at page 13, line 5 skipping to change at page 13, line 9
o codes 0x100-0x200 are reserved for private use. o codes 0x100-0x200 are reserved for private use.
A new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be A new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be
created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result
Values sub-registry. Any new allocations of this code range (in the Values sub-registry. Any new allocations of this code range (in the
range 0x21-0xfe) must happen only within the new sub-registry and not range 0x21-0xfe) must happen only within the new sub-registry and not
in RESULT-TLV Result Values sub-registry. The codes 0x100-0x200 are in RESULT-TLV Result Values sub-registry. The codes 0x100-0x200 are
reserved for private use as described earlier and the code ranges reserved for private use as described earlier and the code ranges
0x21-0xfe and 0x201-0xffffffff should be marked as Unassigned with 0x21-0xfe and 0x201-0xffffffff should be marked as Unassigned with
the IANA allocation policy of Specification Required [RFC5226]. the IANA allocation policy of Specification Required [RFC5226]. The
Designated Expert (DE) needs to ensure existing deployments are not
broken by any specified request. The DE should post a given code
request to the ForCES WG mailing list (or a successor designated by
the Area Director) for any comment and review. The DE should then
either approve or deny the registration request, publish a notice of
the decision to the ForCES WG mailing list or its successor, and
inform IANA of his/her decision. A denial notice must be justified
by an explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.
6. Security Considerations 6. Security Considerations
The security considerations that have been described in the ForCES The security considerations that have been described in the ForCES
protocol [RFC5810] apply to this document as well. protocol [RFC5810] apply to this document as well.
7. References 7. References
7.1. Normative References 7.1. Normative References
 End of changes. 17 change blocks. 
24 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/