Re: [alto] Comments on the Path-Vector draft during IETF 102

[Jensen Zhang <[e-mail]>]

Hi all,

I’m glad to see your active discussion. Sorry for my late reply.

For the first issue, instead of pointing “array” MAY be unordered, I will
suggest we split ordered and unordered list into different cost modes. I
believe it will be more convinced. We already have a use case for the
unordered ane-path in Section 3 of the current path-vector document. We may
add another use case to motivate the ordered ane-path is also required.
(Still thinking about this.)

For the second issue, I believe Dawn proposed the multipath issue is a
general issue for all the cost services. Although multipath is still the
one-source-one-destination paradigm, it will have multiple costs for each
<source, destination> pair. So actually we can consider it as a general
proposal, not just for the path-vector extension. Considering the use case
only requiring the simple cost but still sensitive to multipath, the ALTO
server should also provide multipath cost in those cost metric. In this
sense, it is probably better to introduce multipath extension in another
document, rather than put it into the path-vector draft.

And of course, supporting such new cost schema will introduce more complex
ALTO resource dependency issue. But I think this issue comes from the
unified property (see my IETF102 slides for the alto-unified-properties
draft). When an ALTO resource has multiple dependent resources, there will
be some ambiguities for the client to resolve the dependencies. We have
noticed the resource dependency issue and try to solve the issue in the
unified property document.

Best,
Jensen

On Wed, Aug 22, 2018 at 4:38 AM Danny Alex Lachos Perez <
[e-mail]> wrote:

> Hello Qiao,
>
> See inline a quick comment about the AS-level path information at the
> Broker-assisted architecture
>
> In Danny's multi-domain broker draft tries to use the PV extension to
>> provide the AS-path information for different NFs. This may be a strong
>> case to use the array of ANEs, instead of a set of ANEs, in the PV draft.
>> However, such information is already provided by BGP and will be the source
>> of an ALTO server getting such information, why is ALTO better than BGP at
>> providing such information?
>>
> In multi-domain SFC/NFV scenarios, besides the AS-level topology (provided
> by BGP, for instance) information, the provision of a complete E2E network
> service needs resource (storage, storage, memory), network (bandwidth,
> delay)  and services (Virtual/physical Network Functions) information. The
> current SG object proposed on the Broker-assisted draft is focused purely
> on AS-level connectivity information between entities (e.g., SAP->NF,
> NF->NF, etc.), following an ordered flow. However, the SG object is
> conceived to support (extension or potential new ALTO service) additional
> information (e.g., resource, network, service). This means the connectivity
> information will be computed considering also such additional parameters.
>
> Best regards,
>
> Danny Lachos
>
>
> On Tue, Aug 7, 2018 at 5:49 PM Qiao Xiang <[e-mail]> wrote:
>
>> Dear authors of the PV draft and the ALTO WG members,
>>
>> Before and during IETF 102, I raised a couple of issues about the path
>> vector draft: (1) why we use a vector of abstract network element (ANE)?
>> and (2) update the current PV design to support multicast/multicast. It was
>> suggested during IETF 102 that we move this discussion to the mailing list.
>> Hence the following are my opinions in detail:
>>
>> *1. The design choice of using "array/sequence/list of abstract network
>> elements (ANEs)".*
>>
>> We all know that the concept "path vector" in this draft was highly
>> motivated by BGP, a path-vector interdomain routing protocol. In BGP, a
>> path vector encodes an AS path, which provides the semantics that to reach
>> a destination IP prefix, which ASes will be traversed in what "order". The
>> AS-path vector has semantics: (1) the first one in the vector is the
>> neighbor AS providing this route, (2) the last one is the destination AS
>> providing the destination IP prefix, (3) The ASes in between help provide
>> information about inter-AS connectivity. In contrast, a path vector in ALTO
>> is an ANE-path. What semantics does it have? In order words, why does the
>> order of ANEs matter? One may argue that it may help provide information
>> like "a flow will pass through a firewall middlebox before entering a DPI
>> middlebox", but why would a network operator want to provide such detailed
>> private information to the application? Is there a strong, reasonable use
>> case?
>>
>> In Danny's multi-domain broker draft tries to use the PV extension to
>> provide the AS-path information for different NFs. This may be a strong
>> case to use the array of ANEs, instead of a set of ANEs, in the PV draft.
>> However, such information is already provided by BGP and will be the source
>> of an ALTO server getting such information, why is ALTO better than BGP at
>> providing such information?
>>
>> I see 3 ways that we can proceed:
>>
>> (1) we keep the current design, and provide strong use cases in the draft
>> to justify "array of ANEs" is necessary, and explicitly state that the
>> application MUST recognize that the returned array of ANEs MAY be
>> unordered;
>> (2) we keep the current design, do not provide strong use cases to
>> justify this design, but explicitly state that the server MAY return the
>> array of ANEs unordered;
>> (3) we change the design from "array of ANEs" to "set of ANEs" (i.e.,
>> cost mode changed from "array" to "set"). Given that all specifications in
>> ALTO are specified using JSON format, which does not have a concept called
>> "set", this design choice may seem a bit strange. However, I believe that
>> we should not let the specification language used by the WG affect the
>> semantics of the design.
>>
>> *2. Handling multipath (and potentially multicast).*
>>
>> The current PV design does not handle multipath routing or multicast. Per
>> suggestion from Richard, I took a look at how BGP handles multipath, given
>> that PV was highly motivated by BGP. I found RFC7911 ("Advertisement of
>> Multiple Paths in BGP") provides the solution. And the basic idea is very
>> simple: in BGP announcement, assigning an ID (path identifier) to the
>> route. This motivates me to propose the following design to let the PV
>> extension support multipath.
>>
>> Consider a source-destination pair (a flow), its route (no matter
>> single-path route or multipath route) is essentially a set of route
>> segments. When the ALTO client submits a PV query about this flow to the
>> ALTO server. Instead of returning an array of ANEs, the ALO server returns
>> a set of arrays of ANEs, where each array represents a route segment in the
>> route of this flow and is assigned a unique ID. These IDs are also sent to
>> the ALTO client. In addition to the property map of all ANEs used in these
>> route segments, the ALTO server also sends another property map of all
>> route segments, where the property is "traffic load percentage".
>>
>> I intended to talk about this design during the IETF 102 meeting,
>> however, given my unstable internet connection, I had to omit this part.
>> Slide 4-6 in the attached presentation illustrates this design with an
>> example. I believe this design perfectly provides accurate, compact
>> information of resource sharing in multipath routing. It can also handle
>> the resource sharing defined by TE policies, and can potentially provide
>> such information in multicast, provided that the query format supports a
>> query on multicast flow.
>>
>> What do you think about these two issues? It would be great to hear the
>> opinion from not only the authors, but also other WG members. If they are
>> reasonable to most of you, may I suggest integrating them into the next
>> version of the PV draft? Thank you very much.
>>
>>
>> Best wishes
>> Qiao Xiang
>> --
>> Qiao Xiang
>> Postdoctoral Fellow,
>> Department of Computer Science,
>> Yale University
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>