Re: [alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-03.txt

[Shawn Lin <[e-mail]>]

Hi Jensen,

Thank you so much! Very appreciated! Please see my comments in line.

On Mon, Jul 9, 2018 at 11:47 AM Jensen Zhang <[e-mail]>
wrote:

> Hi authors and WG,
>
> I reviewed the document alto-cdni-request-routing-alto-03 until Section 4.
> About the content after Section 4, I only quick go over the English issues.
> I will post my detailed review of the later sections tomorrow.
>
> My current thought is that cdni fci information may not match the ALTO map
> service very well. Because it does not even provide an object-map format
> message. So it's hard to use the benefit of the ALTO map service, like
> filtering. Or maybe we need to introduce a proper key like PID to index
> the BaseAdvertisementObject.
>
>
PID is one type of Footprint. BaseAdvertisementObject contains Capabilities
and Footprints. So using PID to index the BaseAdvertisementObject may not
be proper. And in current design, we can use the unified property map to
descripe a Footprint with its Capabilities. I think I can add one example
to show a PID Footprint with its Capabilities.

           "pid:pid1": {

             "cdni-fci-capabilities": [{"capability-type":,
"capability-value":}]

           }

A potentially way to utilizing the existed ALTO services to filter based on
Capabilities is to use the unified property map. We could consider
Capability as an entity as well.
            "FCIDeliveryProtocol:http_11": {
              "footprints": [{"footprint-type":, "footprint-value":}]
            }

If we do so, we may need to rich the semantics of entity. Section 2.4
Entity Address in unified property map may need to be revised.
What do you think?



> Below is the part 1 of my detailed review:
>
> =======
> Abstract:
>
> >    The Content Delivery Networks Interconnection (CDNI) WG is defining a
> >    set of protocols to inter-connect CDNs, to achieve multiple goals
> >    such as extending the reach of a given CDN to areas that are not
> >    covered by that particular CDN.  One component that is needed to
> >    achieve the goal of CDNI is the CDNI Request Routing Footprint &
> >    Capabilities Advertisement interface (FCI) [RFC7336].  [RFC8008] has
> >    defined precisely the semantics of FCI and provided guidelines on the
> >    FCI protocol, but the exact protocol is explicitly outside the scope
> >    of that document.  In this document, we define an FCI protocol using
> >    the Application-Layer Traffic Optimization (ALTO) protocol.
>
>   [Jensen] Based on nits:
>
> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-03.txt
> ,
>   the references should not appear in the abstract.
>
> Thanks, fixed.

>
> Section 1., paragraph 13:
>
> >    This document focuses solely on CDNI FCI, with a goal to specify a
> >    new Application-Layer Traffic Optimization (ALTO) [RFC7285] service
> >    called "CDNI FCI Map Service", to transport and update CDNI FCI
> >    objects, which are defined in a separate document in [RFC8008] and to
> >    describe a mechanism for filtering CDNI FCI map on capabilities or
> >    footprints.
>
>   [Jensen] a mechanism -> approaches. If my understanding is right, this
>   document does not introduce any new mechanism beyond the JSON encoding
>   and the HTTP request/response. And Section 5 and 6 actually propose
>   two different approahces for filtering on capabilities and footprints
>   respectively.
>
> Thanks, fixed.

>
> Section 2., paragraph 1:
>
> >    The design of CDNI FCI transport using ALTO depends on understanding
> >    of both FCI semantics and ALTO.  Hence, we start with a review of
> >    both.
>
>   [Jensen] understanding -> the understanding
>
> Thanks, fixed.

>
> Section 2.1., paragraph 3:
>
> >    o  Given that a large part of Footprint and Capabilities
> >       Advertisement will actually happen in contractual agreements, the
> >       semantics of CDNI Footprint and Capabilities advertisement refer
>
>   [Jensen] refer -> refers
>
> Thanks, fixed.

>
>
Section 2.1., paragraph 10:
>
> >    o  For all of these mandatory-to-implement footprint types,
> >       footprints can be viewed as constraints for delegating requests to
> >       a dCDN: A dCDN footprint advertisement tells the uCDN the
> >       limitations for delegating a request to the dCDN.  For IP prefixes
> >       or ASN(s), the footprint signals to the uCDN that it should
> >       consider the dCDN a candidate only if the IP address of the
> >       request routing source falls within the prefix set (or ASN,
> >       respectively).  The CDNI specifications do not define how a given
> >       uCDN determines what address ranges are in a particular ASN.
> >       Similarly, for country codes, a uCDN should only consider the dCDN
> >       a candidate if it covers the country of the request routing
> >       source.  The CDNI specifications do not define how a given uCDN
> >       determines the country of the request routing source.  Multiple
> >       footprint constraints are additive, i.e. the advertisement of
>
>   [Jensen] i.e. -> i.e.,
>
> Thanks, fixed.

>
> Section 2.1., paragraph 12:
>
> >    o  The following capabilities are defined as "base" capabilities,
> >       i.e. ones that are needed in any case and therefore constitute
>
>   [Jensen] i.e. -> i.e.,
>
> Thanks, fixed.

>
> Section 2.2., paragraph 5:
>
> >    o  The semantics of an ALTO network map are an exact match for the
>
>   [Jensen] are -> is
>
> Thanks, fixed.

>
> Section 2.2., paragraph 6:
>
> >       needed information to convey a footprint by a downstream CDN, in
> >       particular if such a footprint is being expressed by IP-prefix
> >       ranges.
>
>   [Jensen] "in particular" -> "in particular,"
>
> I think this comma is not needed.
>From http://dd.dgacm.org/editorialmanual/ed-guidelines/style/punctuation.htm
   A comma is not necessary after “in particular” if it would separate the
phrase from the person or thing to which it applies.

>
> Section 3., paragraph 1:
>
> >    The ALTO protocol is based on an ALTO Information Service Framework
> >    which consists of several services, where all ALTO services are
> >    "provided through a common transport protocol, messaging structure
> >    and encoding, and transaction model" [RFC7285].  The ALTO protocol
> >    specification [RFC7285] defines several such services, e.g. the ALTO
> >    map service.
>
>   [Jensen] "e.g." -> "e.g.,"
>
> Thanks, fixed.

>
> Section 3., paragraph 2:
>
> >    This document defines a new ALTO Map Service called "CDNI FCI Map
> >    Service" which conveys JSON objects of media type "application/alto-
> >    cdnifcimap+json".  These JSON objects are used to transport
> >    BaseAdvertisementObject objects defined in [RFC8008]; this document
> >    specifies how to transport such BaseAdvertisementObject objects via
> >    the ALTO protocol with the ALTO "CDNI FCI Map Service".  Given that
> >    the "CDNI FCI Map Service" is very similar in structure to the two
> >    already defined map services (network maps and cost maps), the
> >    specification of CDNI FCI Map below uses the same specification
> >    structure for Cost Map specification in Section 11.2.3 of [RFC7285]
> >    when specifying cost maps.
>
>   [Jensen] Why use the same structure for Cost Map here? And even in
>   structure, I think CDNI FCI Map is very different from Network Map and
>   Cost Map. Because the data entry of those two map services point to
>   object-map(s). But the data entry of CDNI FCI Map points to an
>   JSONArray.
>
> CDNI FCI map may depend on network map, and it also needs meta information
such as version tag, so it is similar to network map/cost map in some sense.

>
> Section 3.6., paragraph 1:
>
> >    If a CDNI FCI map does not depend on other resources, the "meta"
> >    field of a CDNI FCI map response MUST include the "vtag" field
>
>   [Jensen] Why need to emphasize "does not depend on other resources"?
>   Even it depends on some resource, the "vtag" field is still necessary.
>   Because whether the "vtag" field is needed depends on whether there
>   are other resources using it, not whether it depends on others.
>
> When a CDNI FCI map depends on a network map, we can use the "vtag" of
that network map which is "tag" field in "dependent-vtags" in CDNI FCI map.
And I do not see any other resources may depend on CDNI FCI map. However, I
will support your suggestion because CDNI FCI map may depend on multiple
resourecs such as network maps, so in such cases, a "vtag" field can help
the ALTO client to check the version of this CDNI FCI map. Thanks!

>
> Section 3.6., paragraph 2:
>
> >    defined in Section 10.3 of [RFC7285], which provides the version tag
> >    of the retrieved CDNI FCI map.  If a CDNI FCI map response depends on
> >    a resource such a network map, it MUST include the "dependent-vtags"
>
>   [Jensen] such -> ,such as
>
> Thanks, fixed.

>
> Section 3.6., paragraph 6:
>
> >    Specifically, a CDNIFCIMapData object is a JSON object, and it
> >    includes only one property "capabilities" and whose value is an array
>
>   [Jensen] To be distinguished from the ALTO Information Resource
>   Capabilities, how about we change the field name "capabilities" to
>   something like "fci-capabilities"?
>
> Thanks, I will change it to "cdni-fci-capabilities".

>
> Section 3.6., paragraph 8:
>
> >    The ALTO client MUST interpret footprints appearing multiple times as
>
>   [Jensen] "The ALTO client MUST ..." -> "For each
>   BaseAdvertisementObject, the ALTO client MUST ..."
>
> Thanks, fixed.

>
> Section 3.6., paragraph 9:
>
> >    if they appeared only once.  If no footprint restriction list is
> >    specified (or an empty list is specified), the ALTO client MUST
> >    understand that all footprint types are reset to "global" coverage.
>
>   [Jensen] reset to "global" coverage -> set to the "global" coverage
>
> Thanks, fixed.

>
> Section 3.7.1., paragraph 1:
>
> >    Below is an example IRD announcing two network maps, one CDNI FCI map
> >    without dependency, one CDNI FCI map depending on a network map, one
> >    filtered CDNI FCI map, one unified property map including "cdni-fci-
> >    capabilities" as its entities' property, one filtered unified
> >    property map including "cdni-fci-capabilities" and "pid" as its
> >    entities' properties and two update stream services (one for updating
> >    CDNI FCI maps, and the other for updating property maps).
>
>   [Jensen] Since this is the first time to mention the "filtered CDNI
>   FCI map", can we refer it to its definition? Like "filtered CDNI FCI
>   map (defined in Section xxx)".
>
> Thanks, fixed.

>
> Section 4.1., paragraph 1:
>
> >    In addition to the already defined CDNI footprint typs (e.g.,
> >    ipv4cidr, ipv6cidr, asn, countrycode), ALTO network maps can be a
> >    type of FCI footprint.  To enable such referencing to ALTO network
> >    maps, a new CDNI Footprint Type "altonetworkmap" is defined (see also
> >    Section 8.1).
>
>   [Jensen] Not "see also Section 8.1". Because the IANA registry should
>   point out the detailed specification, this section should describe the
>   semantics and the specification of "altonetworkmap" footprint, and the
>   Section 8.1 should refer to this section.
>
>
> Section 4.2.4., paragraph 1:
>
> >    In this example, the ALTO client is interested in changes of "my-
> >    cdnifci-map-with-network-map-footrprints".  And we present two
>
>   [Jensen] footrprints -> footprints
>
> Thanks, fixed.

>
> Section 5.1., paragraph 1:
>
> >    Since a filtered CDNI FCI map is still a CDNI FCI map, it uses the
> >    media type defined for CDNI FCI maps at Section 3.1.
>
>   [Jensen] at -> in
>
Thanks, fixed.

> =======
>
Thanks again!

>
>
Best,
> Jensen
>
> On Wed, Jul 4, 2018 at 9:00 PM Shawn Lin <[e-mail]> wrote:
>
>> Dear ALTO WG members,
>>
>> This is a short summary of updates in *alto-cdni-request-routing-alto-03*
>> .
>>
>> *Major updates:*
>> 1. Add a new section, "*section 7 Protocol Errors"*.
>> 2. In *section 3.6*, shorten the original encoding with
>> *BaseAdvertisementObject* defined in Section 5.1 of RFC 8008.
>> 3. In *section 3.6*, remove the description of optimization to keep the
>> document clean, but keep a note about the optimization of BaseAdvertisement
>> objects.
>>
>> *   Note: Further optimization of BaseAdvertisement objects to*
>> *   effectively provide the advertisement of capabilities with footprint*
>> *   restrictions is certainly possible, however, it is not necessary for*
>> *   the basic interconnection of CDNs.  The note here is for*
>> *   completeness, however, the specifics of such mechanisms are outside*
>> *   the scope of this document.*
>>
>>
>> *Minor updates:*
>> 1. Change media type of CDNI FCI Map to
>> *"application/alto+cdnifcimap+json"*.
>> 2. Change the response name of CDNI FCI Map to *"cdni-fci-map"* so it is
>> consist with "network-map", "cost-map", "endpoint-cost-map".
>> 3. Fix some typos.
>>
>> Any comments or feedback are highly appreciated!
>>
>> Bests,
>> Shawn Lin
>>
>> On Mon, Jun 18, 2018 at 12:56 PM <[e-mail]> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Application-Layer Traffic Optimization
>>> WG of the IETF.
>>>
>>>         Title           : Content Delivery Network Interconnection
>>> (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using
>>> ALTO
>>>         Authors         : Jan Seedorf
>>>                           Y.R. Yang
>>>                           Kevin J. Ma
>>>                           Jon Peterson
>>>                           X.S. Lin
>>>         Filename        :
>>> draft-ietf-alto-cdni-request-routing-alto-03.txt
>>>         Pages           : 34
>>>         Date            : 2018-06-17
>>>
>>> Abstract:
>>>    The Content Delivery Networks Interconnection (CDNI) WG is defining a
>>>    set of protocols to inter-connect CDNs, to achieve multiple goals
>>>    such as extending the reach of a given CDN to areas that are not
>>>    covered by that particular CDN.  One component that is needed to
>>>    achieve the goal of CDNI is the CDNI Request Routing Footprint &
>>>    Capabilities Advertisement interface (FCI) [RFC7336].  [RFC8008] has
>>>    defined precisely the semantics of FCI and provided guidelines on the
>>>    FCI protocol, but the exact protocol is explicitly outside the scope
>>>    of that document.  In this document, we define an FCI protocol using
>>>    the Application-Layer Traffic Optimization (ALTO) protocol.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-03
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-03
>>>
>>> A diff from the previous version is available at:
>>>
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-03
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> alto mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>