Hi Carlos,
Thank you for the follow-up. Glad to hear that you agree on the alignment with
YANG data types.
I don't understand however your point about "configure features of a control
plane", flexibility, and ambiguity, but let me clarify the following:
* YANG models are classified in the IETF into three categories: service
(reflects the intent as seen by a client/requestor), network (reflects the
network-wide view of how a service will be put into effect but with the view of
the entity that will deliver the service), and device (the actual device
configuration) models [1]
* The ACaaS is a service model. It does not expose the actual device
configuration.
* YANG allows to tag portions of a module as conditional. It does so by
means of "feature" [2]. The ACaaS uses extensively features to adapt to
specific deployment contexts. For example,
* If all what a server cares about is BGP with both IPv4 and IPv6
address families, then only these features will be advertised by the server.
All the other portions that are conditioned by the support of other features
will be stripped.
I provided a pointer to an appendix with a very detailed flow to illustrate how
this can be used in an interconnection context. The examples even include
provision of validation status updates. I do see a lot of common aspects with
your draft.
Cheers,
Med
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-yang-module-classification
[2] https://datatracker.ietf.org/doc/html/rfc7950#section-5.6.2
De : Carlos Aguado <[email protected]>
Envoyé : mercredi 12 juin 2024 12:04
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
Cc : Job Snijders <[email protected]>; [email protected];
[email protected]
Objet : Re: [GROW]Re: Working Group Call for Adoption for
draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024)
Hello all, Med,
About pending questions, we are trying to navigate the IETF process to gather
the consensus on the right use case. Please let me shed light on what's been
discussed privately.
I shared that the main business use case expressed at the top of the document
is to describe intent of interconnection via a RESTful API and the behaviors
each party can expect. This declarative intent behavior is to help both sides
to programmatically reach a business decision automatically before proceeding
with the organizations' internal processes. In my opinion, the YANG model
proposed is very extensive and flexible as one would expect to configure
features of a control plane. I am concerned that such flexibility makes it very
ambiguous to programmatically cover the expectations from the combination of
options in an API, without defaulting to human escalation. I do agree that
alignment to YANG data types can help with the device configuration, but in
this draft we are trying to reduce ambiguity and not expose device
configuration but a model of what semantics, API verbs, and the associated data
types go together. If the request is to use the YANG model to influence those
data types I'd think it is a reasonable next step to hear more of this wider
audience as to what the expectation of doing with them is.
We have also iterated over the doc to make the document self contained and
describe the API artifacts without resorting to a github repo.
>From the IETF submission guidelines we were under the impression that this
>disambiguation is expected to happen during adoption but please let us know
>whether we should have further iterations on a specific topic before that or
>whether iterating on the document from wider inputs in this list is the
>correct step at this stage.
Best,
Carlos
On Wed, 12 Jun 2024 at 08:11,
<[email protected]<mailto:[email protected]>> wrote:
Hi Job, all,
As an editor of [1], I'm supportive of work that enables more automation, not
only for provisioning but also for service negotiation. I'm specifically
supportive of mechanisms to automate interconnection.
However, I think we need to clarify the scope here, avoid overlapping, and
leverage existing specifications before considering adoption.
When checking the archives I was surprised that there was no technical
discussion on the list. There was no follow-up to the very few technical
comments raised on the list:
* Tom asked on [2] to clarify the use of existing tools such YANG.
* Qin raised [3] a question whether Attachment Circuit as Service API defined
in draft-ietf-opsawg-teas-attachment-circuit be reused, but no follow-up.
* I raised a similar point in [4], and also privately to the authors.
Very detailed walk trough examples are provided in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-13#name-interconnection-via-interne
to cover the target use cases in draft-ramseyer (and even more). The module
includes a rich set of reusable groupings to cover other workflow needs, etc.
There are also tools out there for YANG/OpenAPI transforms.
So, the first question we need to assess is what are the missing pieces?
Thank you.
Cheers,
Med
[1] https://datatracker.ietf.org/doc/html/rfc8921
[1] https://mailarchive.ietf.org/arch/msg/grow/0TkURmDuTSv4KNsZ8K9URjHAPs0/
[2] https://mailarchive.ietf.org/arch/msg/grow/HZ36NsnyKA6aN7OSOI4XpNGfYkc/
[3] https://mailarchive.ietf.org/arch/msg/grow/jHut32YWE5zceUifo5pO3MAtxnc/
> -----Message d'origine-----
> De : Job Snijders
> <[email protected]<mailto:[email protected]>>
> Envoyé : vendredi 7 juin 2024 20:13
> À : [email protected]<mailto:[email protected]>
> Objet : [GROW]Working Group Call for Adoption for draft-ramseyer-
> grow-peering-api (start 07/Jun/2024 end 21/Jun/2024)
>
>
> Dear GROW,
>
> The author of draft-ramseyer-grow-peering-api asked whether the
> GROW working group could consider adoption of their internet-
> draft.
>
> This message is a request to the group for feedback on whether
> this internet-draft should be adopted.
>
> Title: Peering API
> Abstract:
> We propose an API standard for BGP Peering, also known as
> interdomain
> interconnection through global Internet Routing. This API
> offers a
> standard way to request public (settlement-free) peering,
> verify the
> status of a request or BGP session, and list potential
> connection
> locations. The API is backed by PeeringDB OIDC, the industry
> standard for peering authentication. We also propose future
> work to
> cover private peering, and alternative authentication methods.
>
> The Internet-Draft can be found here:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> Fdatatracker.ietf.org<http://fdatatracker.ietf.org/>%2Fdoc%2Fdraft-ramseyer-grow-peering-
> api%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7Cd9a91862bb
> 794544104708dc871d81ca%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
> %7C638533807998852919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> a=KK16qnk7B278E1eDMSv%2FlhGOkwhI4m%2BbQLRlnTY6iCk%3D&reserved=0
>
> Please share with the mailing list if you would like this work to
> be adopted by GROW, are willing to review and/or otherwise
> contribute to this draft!
>
> WG Adoption call ends June 21st, 2024.
>
> Kind regards,
>
> Job / Chris
> GROW co-chairs
>
> _______________________________________________
> GROW mailing list -- [email protected]<mailto:[email protected]>
> To unsubscribe send an email to
> [email protected]<mailto:[email protected]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
GROW mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
