Re: [alto] Reviews on draft-gao-alto-fcs-02

[Jensen Zhang <[e-mail]>]

Shenshen,

Thanks for your reply. Fixed the typos.

Jensen

On Fri, Jun 30, 2017 at 9:20 PM Shenshen Chen <[e-mail]> wrote:

> 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
>
>