Hi guys,
Thanks for all your advices. It seems that having a service models common
types can be positive and on the other hand, we have all a lot of warnings to
do it with care, (not just extracting everything that seems common, types,
groupings, containers.. which can be a bad outcome).
Hence, Joe, WG chairs, will it make sense that within the working group,
with the guidance of people that have been involved in similar common types
experiences, we work to define what would make sense, because it is something
applicable to VPN services in general, make a first proposal, discuss it, and
then decide if it is worth as a service types common module?
My 2 cents to start is the proposal in slide #4 in
https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Meetings/20200528/l3nm_20200428.pptx
Reproducing it here, part of this common types module definitions could be:
* Service status (operative and administrative status, up & down)
* Underlay transport (all VPNs require a transport, which could be based on
traffic engineering such as SR-TE or RSVP-TE, based on LDP, etc)
* Encapsulation type (in the CE-PE interface the encapsulation options can be
Dot1q, QinQ,...etc)
* RTs/RDs (while this is mainly for L3 VPNs, for L2 we have also the case of
BGP-VPLS )
* Service profiles (routing profiles, QoS profiles, etc..)
* Service topology (example hub & spoke, custom...)
Comments? More suggestions?
Best Regards,
Oscar
-----Mensaje original-----
De: Italo Busi <[email protected]>
Enviado el: viernes, 29 de mayo de 2020 15:05
Para: tom petch <[email protected]>; [email protected]; 'Joe Clarke
(jclarke)' <[email protected]>; Oscar González de Dios
<[email protected]>
CC: 'opsawg' <[email protected]>
Asunto: RE: [OPSAWG] Minutes of L3NM/L2NM module discussions
Tom,
The difficulties with layer0-types were due to the complexity of the technology
we were trying to model.
Having a common layer0-types has actually helped a lot since only one module
(the layer0-types) had to go through "several revolutions" instead of the six
modules which depends on it.
There were also some technical issues in one draft which were discovered by
people working on other draft only after the code was moved to the
layer0-types. This helped at least to discover the issues earlier in the
process.
Italo
> -----Original Message-----
> From: tom petch [mailto:[email protected]]
> Sent: venerdì 29 maggio 2020 12:48
> To: Italo Busi <[email protected]>; [email protected]; 'Joe
> Clarke (jclarke)' <[email protected]>; 'Oscar González de
> Dios'
> <[email protected]>
> Cc: 'opsawg' <[email protected]>
> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
>
> From: Italo Busi <[email protected]>
> Sent: 29 May 2020 08:56
>
> I support developing a separate module for the common types/groupings/...
>
> This approach has worked quite well within TEAS and CCAMP WG.
>
> I agree that there are some risks with this work: my suggestion is
> just be aware of the risks and be careful to avoid them.
>
> Working in parallel on L3NM, L2NM and the common modules would really
> help identifying what is really common and what it is not.
>
> The suggestion we have got in CCAMP WG was not to send to IESG the
> common module alone but to send it with at least one of the modules
> importing it.
>
> I would suggest to follow the same approach in OPSWG if a separate
> module for the common types/groupings/... is developed.
>
> <tp>
> I asked what the four documents were since AFAICT two are published
> RFC, and that has been confirmed. So what is going to happen to those RFC?
>
> And as you will know from CCAMP, layer0 types has undergone several
> revolutions before getting to its current state. These common
> identity etc are hard to get right in the IETF.
>
> Tom Petch
>
> Italo
>
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[email protected]]
> > Sent: giovedì 28 maggio 2020 19:15
> > To: 'tom petch' <[email protected]>; 'Joe Clarke (jclarke)'
> > <[email protected]>; 'Oscar González de Dios'
> > <[email protected]>
> > Cc: 'opsawg' <[email protected]>
> > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> >
> > OK, thanks, that's clear.
> >
> > I *think* (I was on the call where this was discussed) that it was
> > exactly the worry about importing a whole module that led to the
> > suggestion of having a separate module just for common types. As I
> > understand it, there was a desire to have a common type used in
> > several modules, but some implementers felt that this would lead
> > them to have to import the whole module (not just the type).
> >
> > The idea of a separate module certainly has some risks associated:
> > not capturing the right things; including too much "stuff"; forcing
> > commonality where none exists.
> >
> > There is, as you suggest, an alternative that each module goes its
> > own way and there is no sharing. I *think* we received a strong
> > steer that sharing is a good idea.
> >
> > Best,
> > Adrian
> >
> > -----Original Message-----
> > From: tom petch <[email protected]>
> > Sent: 28 May 2020 17:26
> > To: 'Joe Clarke (jclarke)' <[email protected]>;
> > 'Oscar González de Dios' <[email protected]>;
> > [email protected]
> > Cc: 'opsawg' <[email protected]>
> > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> >
> > From: Adrian Farrel <[email protected]>
> > Sent: 28 May 2020 14:29
> >
> > Hey Tom,
> >
> > Is there a typo in your email? You said...
> >
> > > So carving out the current types (etc) will likely lead to a bad
> > > outcome; it is a question of looking carefully across the range of
> > > documents to see what is, or is likely to be common.
> >
> > I wondered whether you intended a "not" in there somewhere.
> >
> > <tp>
> > Adrian,
> > no, no 'not' was intended. The danger is taking e.g. the 50 or so
> > pages of identity, typedef, grouping in L2NM and assuming that they
> > form a good starting point or, worse still, making a logical OR of
> > the four documents under consideration and to create a monster
> > document and assuming that that is a good basis.
> >
> > Critical assessment is what is needed IMHO. Sometimes it is better
> > to create your own version of vpn-id or ODUC than import a hundred
> > pages of someone else's in order to get them.
> >
> > Tom Petch
> >
> > If you wrote what you intended, could you explain a little further
> > what the danger is?
> >
> > Best,
> > Adrian
> >
> > -----Original Message-----
> > From: OPSAWG <[email protected]> On Behalf Of tom petch
> > Sent: 26 May 2020 17:05
> > To: Joe Clarke (jclarke) <[email protected]>; Oscar
> > González de Dios <[email protected]>
> > Cc: opsawg <[email protected]>
> > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> >
> > From: OPSAWG <[email protected]> on behalf of Joe Clarke
> > (jclarke) <[email protected]>
> > Sent: 21 May 2020 15:43
> >
> >
> >
> > 2. L3NM
> > Revision of the three main issues:
> > Implementation Report by Cisco. It has two main issues
> > (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110)
> > - Common module to have all the L3NM specific requirements.
> > Type-like module.
> > [Anton]: It makes implementation simpler. Does not generate
> > unnecessary dependencies
> > [Adrian]: It depends on if we need module for specific types, to
> > avoid unnecessary imports. Also don't you only need to import types,
> > not the entire module?
> > [Qin]: With L3SM we did not take an augmentation approach. If there
> > are common types defined in both models, then we may need to find
> > the common components. We should decouple of L3SM.
> > [Sriram]: Prefer to have a separate type-file for the specific parameters.
> > [Oscar]: Define a common type-file for the service models.
> > [Qin]: Is it possible to manage it as an independent draft?
> >
> > [Oscar in github issues]: After the discussions, it seems reasonable
> > to have a separate Yang module to contain the types. The suggestion
> > is to write the module to cover the four service models (client
> > service models, l3sm, l2sm and Network service models, l2nm, l3nm).
> > It seems reasonable to include this module in l3nm draft instead of
> > creating a new
> one to avoid dependencies.
> > Samier, Dan and Anton to collaborate for a first version of the
> > split
> >
> > As chair, I want to call this out since it sounds like the authors
> > made a decision here, and I want to make sure the whole WG has a
> > chance to weigh in. In reading these minutes and issue #110, I can
> > see the value of a types module to avoid what may be confusing
> > imports, but I want to know if anyone on the WG has a different opinion.
> >
> > <tp>
> > Joe
> > The four documents are not spelled out but referred to in shorthand
> > and while I think I know which are intended, that IMHO needs spelling out.
> > In principle, a common types is a no-brainer provided it is done
> > early enough - before anything becomes an RFC! - and with limited enough
> > scope.
> > NETMOD got it right but did have decades of SMI experience to go on,
> > RTGWG got it right, with TEAS it is less clear while layer0-types
> > has changed much over its short life - is it right now? May be.
> > So carving out the current types (etc) will likely lead to a bad
> > outcome; it is a question of looking carefully across the range of
> > documents to see what is, or is likely to be common. The higher up
> > the stack you go the more likely items are to be common but equally
> > the more likely it is that someone has been there already.
> > And if you look at existing types modules, it took a while for the
> > penny to drop but they end up as separate I-D, better still with a
> > different author to the importing I-D; a no brainer really.
> >
> > Tom Petch
> >
> > Joe
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
> > =
> >
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
contener información privilegiada o confidencial y es para uso exclusivo de la
persona o entidad de destino. Si no es usted. el destinatario indicado, queda
notificado de que la lectura, utilización, divulgación y/o copia sin
autorización puede estar prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente
por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential
information intended only for the use of the individual or entity named above.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this transmission in error, do not
read it. Please immediately reply to the sender that you have received this
communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
