[alto] LHCONE deep visibility deployment using ALTO

[Y. Richard Yang]

Hi WG,

Sorry for the spam. Deployment is another topic which we will discuss in
the coming weekly meeting. Below is a quick email update to save update
time so that we can focus on discussions at the meeting.

There were 3 meetings yesterday to push the effort forward: an early
meeting with Edoardo Martelli (CERN), the next GNA-G meeting and then the
short meeting with Tom Lehman (ESnet). These are wonderful, collaborative
meetings. The goal is to push forward the base component: a deep visible
ability into the LHCONE network, which is the largest network supporting
multiple workloads.

So far, the implementations push on two approaches: A1 extracting the
routing information base (RIB) directly (currently based on NAPALM), and A2
extracting control plane configuration and computing the RIB (currently
based on batfish)

There are two main challenges: (1) wide deployment with partial visibility
(not able to get access to all routers), and (2) visibility into “physical”
assets, not higher level L3 links.

During the weekly meeting, we will discuss the details. In the 4 pm ET
meeting today, we will continue to work with Dr. Tom Lehman and Chin Guok.
All are welcome to work together to push forward the deployment.

Thanks,

Richard

-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Jensen Zhang]

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

> Hi Qin,
>
> Sorry for my late reply. See my comments inline.
>
>
> On Sun, Aug 21, 2022 at 8:44 AM Qin Wu  wrote:
>
>> Hi, Jensen:
>>
>> Thank for summarizing the discussion in last IETF meeting, please see my
>> comments inline.
>>
>>
>>
>> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Jensen Zhang
>> *发送时间:* 2022年8月16日 21:04
>> *收件人:* IETF ALTO 
>> *主题:* [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
>>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Http/2/3 version independent transport finalization

[Y. Richard Yang]

Hi WG,

Updating transport mechanisms is an WG item and we are getting close to the
milestone (in September). Hence, the authors are finalizing the updates as
soon they can, and the topic will be a main item for the coming weekly
meeting. It was suggested that we send out some main points for others to
think about them before the meeting.

In particular, the goal is to finalize the version-dependent design, where
by version independent, it means that the design can benefit from
improvements in http without explicit control. Applying the inference, it
means that the design should not use version specific methods, which will
be PUSH_PROMISE. In other words, it should use only base http/1.x methods;
that is, we use GET/PUT/POST.

In this design space, there are still two design points: (D1): introducing
PUT; (2) not introducing PUT.

For discussion, we need to distinguish between ALTO server/client and HTTP
server/client. In general design, an ALTO server can be an HTTP client and
so on.

For D1, to allow ALTO server pushing updates using PUT, the ALTO server
needs to become an HTTP client. Hence, it needs two HTTP connections, with
in one the ALTO server being an HTTP client and the other HTTP server.

For D2, it needs only one HTTP connection, and the efficiency depends on
low long-poll overhead in non-blocking HTTP/2/3.

The authors prefer D2 and will finalize the document in a couple days. Any
comments are greatly appreciated.

Richard, Roland, Kai and Jensen
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto