Hi all,
I'd like to join this discussion.
About the flow-cost-confidences, I prefer the original design.
The mean of cost makes sense (the expected cost if pick path randomly)
and can't be deduced from the range (since it may not be an
equal probability distribution).
Here is a list of typos (comments are marked with ">>>"):
[Page 1]
3.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 4
3.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 5
>>> Accept => Acceptable, also see 3.3.2. and 4.2.3.
[Page 1]
3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
>>> Example => Examples
>>> Also, the catalog doesn't include Section 4.2.5.1., 4.2.6.1., etc,
which looks weird.
[Page 1]
The emergence of new networking datapath capabilities has
substantially increased the flexibility of networking. For example,
OpenFlow has emerged as a major southbound protocol for Software-
Defined Networking, and OpenFlow allows flexible routing beyond
simple destination-based routing. In this document, we define a new
extention to ALTO, namely the Flow Cost Service, for ALTO clients in
>>> extention => extension
an OpenFlow-enabled network to query ALTO network information.
[Page 6]
The Protocol field is REQUIRED. The available values contain
different protocols including layer two protocols (e.g. "eth") and
layer three protocols (e.g. "ipv4", "ipv6"). It can also be
specified upper-layer protocols (e.g. "udp", "tcp", "ssh", "http" and
"ftp"). The source and destination protocols MUST NOT be conflict.
>>> be conflict => be conflicted
In every EndpointFilter object of either "endpoints" field or
"endpoint-flows" field, if the source protocol is conflict with the
>>> is conflict with => has conflict with
destination protocol, this endpoint pair is invalid. For different
protocols, some additional constraints are defined in Section 3.2.3.
[Page 7]
protocols: Defines a list of JSONString indicating the supported
Protocol values of the EndpointURI in the request. The ALTO
server does not have to claim "ipv4" and "ipv6" in this field
explictly, because they are supported by default. If not present,
>>> explictly => explicitly
this field MUST be interpreted as if it is specified the default
supported protocols "ipv4" and "ipv6".
[Page 16]
The ALTO servers can provide more information to the clients when
requests have errors. The FlowCostErrorMap below can provide basic
information about two most common errors for the flow cost service.
The ALTO servers MAY include it as the data component of an ALTO
error response. If multiple errors are identified, the ALTO server
MUST return exactly one error code according to Section 8.5.2 of
[RFC7285] .
[Page 20]
Security considerations: Security considerations are identical to
those specified in Section 15 of [RFC7285] .
>>> remove the redundent space between [RFC7285] and full stop
[Page 16, 17]
Some header fields may have conflicts. For example, IPv4 fields and
IPv6 fields can never appear in the same packet, nor can TCP and UDP
ports. These header fields MUST not be included in the same flow
filter, otherwise the ALTO server MUST return an ALTO error response,
with the error code "E_INVALID_FIELD_VALUE". As specified in
>>> , otherwise => . Otherwise,
remove the comma before "with"
Section 8.5.2 of [RFC7285], the ALTO server MAY include the "field"
and the "value" in the "meta" field. In this case, the ALTO server
MUST use the flow ID as the "field" and the flow filter as the
"value". However, the recommended approach is to use the
FlowCostErrorMap, where the server CAN provide the conflicting typed
header fields in the "conflicts" field of the FlowFilterError
associated with the corresponding flow ID.
Best Regards,
Shenshen
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
