[alto] ALTO O&M data model: multi-domain support

[Jensen Zhang <[e-mail]>]

Hi all,

I just bring the open discussion about multi-domain support on ALTO O&M
data model to this separate thread. See my comments inline below.

Thanks,
Jensen


On Tue, Sep 6, 2022 at 9:13 PM Jensen Zhang <[e-mail]>
wrote:

> Hi Qin,
>
> Sorry for my late reply. See my comments inline.
>
>
> On Sun, Aug 21, 2022 at 8:44 AM Qin Wu <[e-mail]> wrote:
>
>> Hi, Jensen:
>>
>> Thank for summarizing the discussion in last IETF meeting, please see my
>> comments inline.
>>
>>
>>
>> *发件人:* alto [mailto:[e-mail]] *代表 *Jensen Zhang
>> *发送时间:* 2022年8月16日 21:04
>> *收件人:* IETF ALTO <[e-mail]>
>> *主题:* [alto] Open discussions of ALTO O&M data model
>>
>>
>>
>> Hi ALTOers,
>>
>> From the WG session in IETF 114, we had a lot of discussions about the
>> open issues for ALTO O&M. Authors appreciate all the comments and are
>> working on the next revision.
>>
>> We quickly summarize the major debates and are willing to have more
>> discussions to move this work forward. To be more efficient, we may
>> separate the discussions to different threads later.
>>
>>
>> 2. Whether and how to supply server-to-server communication for
>> multi-domain settings
>>
>> There is no draft defining any standard for ALTO eastern-western bound
>> API (server-to-server communication). Defining data model for this may be
>> too early. But this problem is important in practice. We have several
>> potential choices:
>>
>> 2.a. Each ALTO server connects data sources for its own domain, and build
>> interdomain connections with each other (using eastern-western bound API)
>>
>> 2.b. A single ALTO server connects data sources from multiple domains.
>> The data sources provide interdomain information for ALTO server to build
>> global network view.
>> *[Qin Wu] *You might refer to multi-domain case in RFC7165, it did
>> describe a few requirements and use cases for ALTO eastern-western bound
>> API, but I think it leave the door open for the solution.
>>
>> *I think if you use other protocol than ALTO to define ALTO
>> eastern-western bound API, it is apparent not in the scope of ALTO WG, it
>> you use ALTO protocol to define server to server communication, I think it
>> is in the scope ALTO OAM YANG.*
>>
>
> I agree. From my experience, ALTO eastern-western bound API should be
> based on other protocols than ALTO. Therefore, the OAM to it should not be
> in the scope of ALTO OAM. But ALTO OAM may still need to configure some
> meta information for it.
>
>
>> *Also don’t forget ALTO discovery mechanism, one is intra-domain
>> discovery mechanism ,the other is inter domain discovery mechanism.*
>>
>
Yes, from the discussion for multi-domain ECS [1], we do need cross-domain
server discovery. For ALTO O&M, the only information that needs to be
configured is the scope of the domain for a given ALTO server. The scope
indicates which endpoint is owned by the domain. According to RFC8686, the
ALTO server can use this information to generate NAPTR records for
the reversed DNS lookup. Check the proposed update to the current data
model [2].

[1] https://mailarchive.ietf.org/arch/msg/alto/RUw_CS79CKbO2gV4aHm3k4pXAy4/
[2]
https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-oam-yang&url2=https://ietf-wg-alto.github.io/draft-ietf-alto-oam-yang/draft-ietf-alto-oam-yang.txt


>
>>
>> Looking forward to seeing feedback and further discussions.
>>
>>
>>
>> Best regards,
>>
>> Jensen
>>
>