Subject: [Teas] hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: Comments draft-ietf-teas-ietf-network-slices-06)

From: <[email-masked]>
Date: Mon, 7 Mar 2022 08:30:05 +0000

Hi John, Adrian, all,

Focusing on this part of the discussion.

Both the hub-spoke connectivity type and hub-/spoke endpoint roles are supported in -01 of the YANG module. These roles are inherited from RFC9181 and can be passed to L3NM, when L3VPNs are used to instantiate a slice.

The NEW text added by Adrian in Section 3.2. of -08 is great as it provides a clear reference for the model on these matters.

Cheers,
Med

De : Teas <[email-masked]> De la part de Adrian Farrel
Envoyé : dimanche 6 mars 2022 17:39
À : 'John Mullooly (jmullool)' <[email-masked]>; [email-masked]
Objet : Re: [Teas] Comments draft-ietf-teas-ietf-network-slices-06

Hi once more John,

Now I have to pick another colour.

Cheers,
Adrian

From: John Mullooly (jmullool) <[email-masked]<mailto:[email-masked]>>
Sent: 06 March 2022 16:16
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Comments draft-ietf-teas-ietf-network-slices-06

Hi Adrian,

Thank you for the quick and thoughtful response. By the way, I agree with you that this network-slicing work should  not just to be used for the 5G use-cases but also for the general transport services case.  Focused on desired outcome and intent.  What I would like to see is this draft and the cooresponding nbi-yang model  draft become the norm in how transport services are requested to the transport orchestration layer (NSC).  I’ve also been providing feedback to the authors on the network-slice-nbi-yang draft so  my questions below are mainly in the modeling context of how best we support this work.

With that understanding, see in-line for my final thoughts that you can consider (I leave any changes to your judgement).

Thanks
John

[snip]

Jjm> Again, in the context of the YANG automation work I’m also working on, I’m trying to balance simplicity with flexibility. While I know at the SDP level we can build any topology we need, for common topologies I like the idea of doing something at a “group” level (see previous point above on where to define SLO-sets). So having a few optional  “canned” topologies that can be defined at the group level would help simplify the automation and provide much needed abstraction. I think that was already part of this work. I think certain RAN transport use cases will lean towards the L3VPN hub/spoke model (with uniform policies) and it would be super easy to instantiate that if the user could simply specify that a hub-spoke connectivity type. Of course they would also need a “role” parameter to attach to the endpoint. If this topic has been well debated and the community has agreed, then I’m fine.

[AF2] Right. This is mainly a question for the YANG model (and maybe even for the tools that use the YANG model), but I have added a few words about hub-and-spoke with or without an ancillary SDP.

Best,
Adrian

_________________________________________________________________________________________________________________________

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Mar 2022 11:16:05 -0000

Hi Med,

I think that having hubnspoke in 9181 and included into the L2NM and L3NM models make sense. It is, for me, a service realisation thing.

I am less convinced about including hub and spoke in the network slice service model. It seems to me that the service is concerned about which edge points can send traffic to each other, not how they are connected in the underlay network.

Cheers,

Adrian

From: [email-masked] <[email-masked]> 
Sent: 07 March 2022 08:30
To: [email-masked]; 'John Mullooly (jmullool)' <[email-masked]>; [email-masked]
Subject: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi John, Adrian, all,

Cheers,

Med

De : Teas <[email-masked] <mailto:[email-masked]> > De la part de Adrian Farrel
Envoyé : dimanche 6 mars 2022 17:39
À : 'John Mullooly (jmullool)' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Objet : Re: [Teas] Comments draft-ietf-teas-ietf-network-slices-06

Hi once more John, 

Cheers,

Adrian

From: John Mullooly (jmullool) <[email-masked] <mailto:[email-masked]> > 
Sent: 06 March 2022 16:16
To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: Comments draft-ietf-teas-ietf-network-slices-06

Hi Adrian,

Thanks

John 

[snip]

Best,

Adrian

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 11:45:46 +0000

Re-,

The point Adrian is that a customer may need to control which nodes behave as spoke or hub. Assigning these roles cannot be blindly done by the provider when it instantiates the service.

Cheers,
Med

De : Adrian Farrel <[email-masked]>
Envoyé : lundi 7 mars 2022 12:16
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 'John Mullooly (jmullool)' <[email-masked]>; [email-masked]
Objet : RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi Med,

Cheers,
Adrian

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 07 March 2022 08:30
To: [email-masked]<mailto:[email-masked]>; 'John Mullooly (jmullool)' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi John, Adrian, all,

Cheers,
Med

De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Adrian Farrel
Envoyé : dimanche 6 mars 2022 17:39
À : 'John Mullooly (jmullool)' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [Teas] Comments draft-ietf-teas-ietf-network-slices-06

Hi once more John,

Cheers,
Adrian

Hi Adrian,

Thanks
John

[snip]

Best,
Adrian

Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Mar 2022 11:49:52 -0000

Ah, yes. If the customer wants to assign the hub (perhaps as an ancillary SDP) then I agree with you completely.

A

From: [email-masked] <[email-masked]> 
Sent: 07 March 2022 11:46
To: [email-masked]; 'John Mullooly (jmullool)' <[email-masked]>; [email-masked]
Subject: RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Re-,

Cheers,

Med

De : Adrian Farrel <[email-masked] <mailto:[email-masked]> > 
Envoyé : lundi 7 mars 2022 12:16
À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]> >; 'John Mullooly (jmullool)' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Objet : RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi Med,

Cheers,

Adrian

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > 
Sent: 07 March 2022 08:30
To: [email-masked] <mailto:[email-masked]> ; 'John Mullooly (jmullool)' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi John, Adrian, all,

Cheers,

Med

Hi once more John, 

Cheers,

Adrian

Hi Adrian,

Thanks

John 

[snip]

Best,

Adrian

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Mon, 7 Mar 2022 12:20:40 +0000

Hi Adrian,

If the IETF slice represents user intent, then if they wanted a specific connectivity model (as opposed to building it per source SDP) then these abstractions help
simplify that. In the below statement you say “connected thru the underlay network”, but these connectivity-type abstractions could be primarily used in the overlay network
(i.e. they could help drive automatic RT assignment by the NSC).

Thanks
john

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, March 7, 2022 at 6:16 AM
To: "[email-masked]" <[email-masked]>, Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi Med,

Cheers,
Adrian

Hi John, Adrian, all,

Cheers,
Med

Hi once more John,

Cheers,
Adrian

Hi Adrian,

Thanks
John

[snip]

Best,
Adrian

Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Mar 2022 12:33:39 -0000

Yes, as just commented to Med, if the connectivity model is in the overlay (in other words, the hub is in the overlay) then this is all fine and the words in -08 of the framework probably cover us. 

I think it is important to distinguish between hub-and-spoke in the overlay, and hub-and-spoke used in the underlay to meet the connectivity aspirations of the service.

A

From: John Mullooly (jmullool) <[email-masked]> 
Sent: 07 March 2022 12:21
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi Adrian,

Thanks

john

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Organization: Old Dog Consulting
Reply-To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Date: Monday, March 7, 2022 at 6:16 AM
To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Cisco Employee <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi Med,

Cheers,

Adrian

Hi John, Adrian, all,

Cheers,

Med

Hi once more John, 

Cheers,

Adrian

Hi Adrian,

Thanks

John 

[snip]

Best,

Adrian

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Mon, 7 Mar 2022 13:32:04 +0000

Hi Med,

I’ve provided feedback to the authors already on network-slice-nbi-yang-01 that they do show the roles in the detailed Yang model (section 8), but not in the
tree structure in figure 3.  I believe their intention was to remove roles and hub-spoke as a connectivity model, thus my comments here.

I also think they need to add connectivity-type into the ns-connection-group, with that I think we can accomplish what I had previously discussed in my earlier thread where
in certain “canned” cases the connectivity can be auto-built. We had agreed that in network-slicing draft that stating that each SDP has its own SLO-set does not
preclude using a less granular approaches.

thanks
John

From: "[email-masked]" <[email-masked]>
Date: Monday, March 7, 2022 at 3:30 AM
To: "[email-masked]" <[email-masked]>, Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi John, Adrian, all,

Cheers,
Med

Hi once more John,

Cheers,
Adrian

Hi Adrian,

Thanks
John

[snip]

Best,
Adrian

Thank you.

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Mon, 7 Mar 2022 13:36:48 +0000

Hi Adrain, I’m not sure the user cares about overlay and underlay. They just want a specific connectivity built that meets certain SLOs.

Is the draft implying that the connectivity parameters are only describing the underlay?

John

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, March 7, 2022 at 7:34 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

A

Hi Adrian,

Thanks
john

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Organization: Old Dog Consulting
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 7, 2022 at 6:16 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi Med,

Cheers,
Adrian

Hi John, Adrian, all,

Cheers,
Med

Hi once more John,

Cheers,
Adrian

Hi Adrian,

Thanks
John

[snip]

Best,
Adrian

Thank you.

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 13:44:50 +0000

Re-,

Thanks.

Both the connectivity-type and node roles should be supported in the model.

Cheers,
Med

De : Teas <[email-masked]> De la part de John Mullooly (jmullool)
Envoyé : lundi 7 mars 2022 14:32
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]; [email-masked]
Objet : Re: [Teas] hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: Comments draft-ietf-teas-ietf-network-slices-06)

Hi Med,

thanks
John

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 7, 2022 at 3:30 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments draft-ietf-teas-ietf-network-slices-06)

Hi John, Adrian, all,

Cheers,
Med

Hi once more John,

Cheers,
Adrian

Hi Adrian,

Thanks
John

[snip]

Best,
Adrian

Thank you.

---

From: Tarek Saad <[email-masked]>
Date: Mon, 7 Mar 2022 15:23:30 +0000

Hi all,

Yes, ‘endpoint-role’ type still exists in the model, authors will discuss this in next meeting.
I agree designating a node role can help in automating the creation of connectivity constructs needed to realize the connectivity.

Regards,
Tarek

From: Teas <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Monday, March 7, 2022 at 8:45 AM
To: John Mullooly (jmullool) <jmullool=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] hub-spoke connectivity type & node roles in draft-ietf-teas-ietf-network-slice-nbi-yang (RE: Comments draft-ietf-teas-ietf-network-slices-06)
Re-,

Thanks.

Cheers,
Med

Hi Med,

thanks
John

Hi John, Adrian, all,

Cheers,
Med

Hi once more John,

Cheers,
Adrian

Hi Adrian,

Thanks
John

[snip]

Best,
Adrian

Thank you.

Thank you.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Mar 2022 10:24:45 -0500

If the customers wants the customer-visible topology to be 
hub-and-spoke, then that is something he needs to and can specify.  He 
picks the connectivity and communication pattern among his nodes.  For 
example, if there is a single hub than the topology as expressed by the 
customer is a collection of point-to-point links between the hub and eah 
other node.

If an operator uses internal hub (or hubs) for traffic delivery, that is 
his business.  That is not a matter of customer intent.  And the 
customer should not be specifying it.

Yours,
Joel

On 3/7/2022 7:20 AM, John Mullooly (jmullool) wrote:
> Hi Adrian,
> 
> If the IETF slice represents user intent, then if they wanted a specific 
> connectivity model (as opposed to building it per source SDP) then these 
> abstractions help
> 
> simplify that. In the below statement you say “connected thru the 
> underlay network”, but these connectivity-type abstractions could be 
> primarily used in the overlay network
> 
> *From: *Adrian Farrel <[email-masked]>
> *Organization: *Old Dog Consulting
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Monday, March 7, 2022 at 6:16 AM
> *To: *"[email-masked]" <[email-masked]>, 
> Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: hub-spoke connectivity type & node roles in 
> draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments 
> draft-ietf-teas-ietf-network-slices-06)
> 
> Hi Med,
> 
> I think that having hubnspoke in 9181 and included into the L2NM and 
> L3NM models make sense. It is, for me, a service realisation thing.
> 
> I am less convinced about including hub and spoke in the network slice 
> service model. It seems to me that the service is concerned about which 
> edge points can send traffic to each other, not how they are connected 
> in the underlay network.
> 
> Cheers,
> 
> Adrian
> 
> *From:[email-masked] <[email-masked]>
> *Sent:* 07 March 2022 08:30
> *To:* [email-masked]; 'John Mullooly (jmullool)' 
> <[email-masked]>; [email-masked]
> *Subject:* hub-spoke connectivity type & node roles in 
> draft-ietf-teas-ietf-network-slice-nbi-yang (RE: [Teas] Comments 
> draft-ietf-teas-ietf-network-slices-06)
> 
> Hi John, Adrian, all,
> 
> Both the hub-spoke connectivity type and hub-/spoke endpoint roles are 
> supported in -01 of the YANG module. These roles are inherited from 
> RFC9181 and can be passed to L3NM, when L3VPNs are used to instantiate a 
> slice.
> 
> The NEW text added by Adrian in Section 3.2. of -08 is great as it 
> provides a clear reference for the model on these matters.
> 
> Cheers,
> 
> Med
> 
> *De :*Teas <[email-masked] <mailto:[email-masked]>> *De la 
> part de* Adrian Farrel
> *Envoyé :* dimanche 6 mars 2022 17:39
> *À :* 'John Mullooly (jmullool)' <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Objet :* Re: [Teas] Comments draft-ietf-teas-ietf-network-slices-06
> 
> Hi once more John,
> 
> *From:*John Mullooly (jmullool) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* 06 March 2022 16:16
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: Comments draft-ietf-teas-ietf-network-slices-06
> 
> Hi Adrian,
> 
> Thank you for the quick and thoughtful response. By the way, I agree 
> with you that this network-slicing work should  not just to be used for 
> the 5G use-cases but also for the general transport services case. 
>   Focused on desired outcome and intent.  What I would like to see is 
> this draft and the cooresponding nbi-yang model  draft become the norm 
> in how transport services are requested to the transport orchestration 
> layer (NSC).  I’ve also been providing feedback to the authors on the 
> network-slice-nbi-yang draft so  my questions below are mainly in the 
> modeling context of how best we support this work.
> 
> With that understanding, see in-line for my final thoughts that you can 
> consider (I leave any changes to your judgement).
> 
> Thanks
> 
> John
> 
> *[snip]*
> 
> Jjm> Again, in the context of the YANG automation work I’m also working 
> on, I’m trying to balance simplicity with flexibility. While I know at 
> the SDP level we can build any topology we need, for common topologies I 
> like the idea of doing something at a “group” level (see previous point 
> above on where to define SLO-sets). So having a few optional  “canned” 
> topologies that can be defined at the group level would help simplify 
> the automation and provide much needed abstraction. I think that was 
> already part of this work. I think certain RAN transport use cases will 
> lean towards the L3VPN hub/spoke model (with uniform policies) and it 
> would be super easy to instantiate that if the user could simply specify 
> that a hub-spoke connectivity type. Of course they would also need a 
> “role” parameter to attach to the endpoint. If this topic has been well 
> debated and the community has agreed, then I’m fine.
> 
> [AF2] Right. This is mainly a question for the YANG model (and maybe 
> even for the tools that use the YANG model), but I have added a few 
> words about hub-and-spoke with or without an ancillary SDP.
> 
> Best,
> 
> Adrian
> 
> 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,
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Mon, 7 Mar 2022 15:49:06 +0000

Joel, 

I'm not sure if you're agreeing or disagreeing with me!

Yes, I understand that any topology can be realized with surgically provisioned pt-2-pt connectivity, 
that is a great way to build unique and custom use-cases. But because we have that capability, 
do we not also provide some basic generic connectivity types that can abstract this if the use case fits?

If the customer wants a generic type of topology (i.e. any-to-any or hub-spoke), then why not
provide the capability in the model to specify that at a general connectivity matrix level level? 
This is a service facing model where we should try to simplify usage and abstract as much as possible.  
Ultimately, it's the job of the NSC to take in this intent and derive the needed network configurations.

john

On 3/7/22, 10:25 AM, "Joel M. Halpern" <[email-masked]> wrote:

    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Mar 2022 11:07:27 -0500

I think I am disagreeing with you.

I take your point that some shorthands in terms of the description of 
the delivered service can be helpful.
On the other hand, many shortcuts simply creates confusion.
And hub-and-spoke in particular has so many variations (single, dual, 
hierarchical, hierarchical with redundancy at each level, ...) that I do 
not see having a shortcut for just one case is all that helpful.

Yours,
Joel

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Mon, 7 Mar 2022 16:14:26 +0000

Understood. I'm specifically looking at definitions in YANG model from RFC 9181:

  identity hub-spoke {
       base vpn-topology;
       description
         "Identity for Hub-and-Spoke VPN topology.  All Spokes can
          communicate with Hubs only and not with each other.  Hubs
          can communicate with each other.";
     }

thanks
john

On 3/7/22, 11:07 AM, "Joel M. Halpern" <[email-masked]> wrote:

    Yours,
    Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 7 Mar 2022 11:19:07 -0500

If we are going to include that, do we also need to include 
hub-spoke-disjoint?  And then we have to have something that says "no 
common term for topology?"

Yours,
Joel