Hi.
The current wording in draft-du-anima-an-intent is "ANIMA Intent Policy".
This sounds a little repetitive, but it highlights the problematic nature
of intent in ANIMA.
I'm not sure if only parameters can be enough, but it is also depends on
the definition of "parameters"... Maybe some form of policies (for example,
ECA rules) can be included in the discussion. In any case, I believe this
could be addressed in draft-du-anima-an-intent.
I agree with Brian, the intent "philosophical" discussion fits better the
NMRG. BTW, there is a discussion about it in Prague and this could lead to
a new NMRG workshop (like the autonomic ones).
Best.
Jéferson

Em ter, 25 de jul de 2017 às 20:04, Brian E Carpenter <
[email protected]> escreveu:

> Distribution trimmed to Anima:
>
> Whenever I've asked "Is X Intent?", I've usually been told "No" except for
> cases where X is too abstract to interpret algorithmically.
>
> But in practice, I believe that many ASAs will need instructions from
> the NOC to modify their default behaviour. I don't care what we call
> those instructions; for the prefix management use case we just called
> them "parameters".
>
> So maybe Anima should focus on parameter distribution more than on
> Intent. I think that's the point of draft-liu-anima-grasp-distribution.
> A fairly simple change to the wording of draft-du-anima-an-intent
> would adapt it to generic parameter distribution.
>
> Converting abstract Intent to concrete parameters can be completely
> separate from this, and could well be a centralised operation.
>
> Or we could spend another 6 months discussing how to know Intent
> when we see it. But I would prefer that to happen in NMRG.
>
> Regards
>    Brian
>
> On 26/07/2017 08:34, Toerless Eckert wrote:
> > I have an autonomic network, and i want for another customer another
> > L3VPN service instance in it.  How would i tell the network that i want
> > this ? Via intent or via something else ?
> >
> > If it is something else, what is it ? I do not see any other information
> flow from
> > operator to network beside intent in RFC7575 or
> draft-ietf-anima-reference-model.
> > Maybe i am missing something.
> >
> > If it is intent, how would it look like ? Could it simply be a definition
> > of an L3VPN service instance in the model defined in rfc8049 ? If not,
> why not ?
> >
> > IMHO: Intent in ANIMA includes service definitions such as what rfc8049
> is,
> > except that we would reserve the right to eliminate all parameters of
> rfc8049
> > for which we figure out autonomic ways to determine them. Which alas
> seems to
> > be quite difficult for most parameters.
> >
> > Other folks in the IETF clearly think that a service definition is NOT
> intent,
> > but intent can only be some yet unclear high level policy. If thats the
> > prevailing opinion/wisdom in the IETF, then IMHO we need to be more
> explicit about the
> > fact that Intent is not the only input into the network but that there is
> > also other input. Such as services. And anything else that people do not
> want to
> > call Intent.
> >
> > Lets assume service and other necessary data operator->network should not
> > be called intent. But lets say the superset of intent + services +
> everything
> > else is called eg: "information". I think that draft-du-anima-an-intent
> > would equally apply to all information we would want to distribute into
> > an autonomic network.
> >
> > Cheers
> >     Toerless
> >
> > _______________________________________________
> > Anima mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/anima
> >
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to