Re: [alto] Path Vector final touch

[Qiao Xiang <[e-mail]>]

Hi Richard,

I also want to add a side note on the PV draft. I see that in Section 10.1
the privacy concern of PV is discussed and the network is suggested to
provide protection mechanisms when application and network are not in the
same trust domain. I wonder if the draft should be more specific on what
mechanisms can be used and the corresponding trade-offs? One strawman is to
let the network return a slightly smaller capacity region in the cost and
property map.

I'm not sure how important such privacy concerns can be for wrapping up the
draft, or the simple discussion in the current write-up is already
sufficient, just trying to throw in my two-cent. :-)



Best
Qiao

On Mon, Mar 19, 2018 at 9:35 PM, Y. Richard Yang <[e-mail]> wrote:

> Dear members of WG,
>
> This is a friendly update from the authors of the path vector draft. To be
> up front, we are wrapping up nicely on defining the new cost type
> (cost-mode: array, cost-metric: ane) and the  new domain. These, however,
> are only two of the three building blocks. The third building block, on
> integrating the cost map and the property map, however, still needs final
> touch. During the design, the LHC/esnet use case and the software defined
> coalition use case provide strong support for the benefit of the path
> vector capability. On the other hand, they result in more diversity in the
> supported scenarios.
>
> In a nut shell, the key issues are two:
>
> 1. How to handle compound data: cost map, endpoint cost map, and property
> map are all already defined. What PV needs is an integration. There are two
> approaches: (1) absorption reuse, in that we define a specific new type and
> import the existing types to build a new, single top-level object; (2)
> independent reuse, in that we allow the existing objects to remain
> independent and hence the system now consists of multiple top-level
> objects. The current design, using multipart, is (2), but some authors have
> a strong preference on (1).
>
> 2.. How to (Do we) handle “anonymous” resources? In several use cases, the
> property map is specific to the cost map. Hence, it should not be
> considered as an independent resource. Just as Java and some other
> languages support anonymous functions (e.g., some event handler), we can
> benefit from such a support. The authors are discussing the final wording.
>
> Any expert opinions will be greatly appreciated, as we wrap this draft to
> finish all chartered items sooner.
>
> Cheers,
> Richard
> --
> Richard
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>
>


-- 
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University