[Teas] Comments on draft-zzhang-teas-network-slicing-with-flex-te \\RE: draft-xie-idr-bgpls-sr-vtn-mt

["Dongjie (Jimmy)" <[e-mail]>]

Hi Jeff, 

Thanks for your information about the Flexible TE draft. 

After reading it, my understanding is only the edge nodes are allowed perform per-algo SPF, and for consistent forwarding, only adj-SIDs can be used for the SR path. 

I have a few questions and comments about this document, and I'd appreciate your reply and clarification on them, thanks.

1. Are the link admin-groups configured on links in the network? Or they are provisioned on the controller first, then distributed only to the edge nodes?

2. With the proposed mechanism, will IGP still be used for the distribution of Flex-Algo definition, the link admin-group information and the algo-specific SIDs? And are per-algo SIDs still needed? 

3. After an edge node performs per-algo SPF and builds an SR-TE path, does it generate a SR policy locally for the SR-TE path? 

4. It proposes to use BGP-LS with RT for targeted distribution of FAD and link-state information from controller, as discussed in IDR meeting, some reasons about why BGP-LS or BGP is suitable for this would be needed. 

5. In the IGP extensions, a router originates LSAs/LSPs with other node's link-state information, this is different from the traditional IGP mechanism. Also with IGP flooding, there is no control of the target nodes to receive and keep such information. Are these IGP extensions comply to the concept of the per-algo SPF on edge nodes or selected nodes?  


Best regards,
Jie

> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
> Sent: Saturday, August 1, 2020 3:24 AM
> To: '[e-mail]' <[e-mail]>cn>;
> '[e-mail]' <[e-mail]>cn>; Dongjie (Jimmy)
> <[e-mail]>om>; Lizhenbin <[e-mail]>
> Cc: idr@ietf. org <[e-mail]>rg>; [e-mail]
> Subject: RE: draft-xie-idr-bgpls-sr-vtn-mt
> 
> Oops the draft that I was referring to at the end of this email should be
> draft-zzhang-teas-network-slicing-with-flex-te.
> 
> Jeffrey
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Teas <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: Friday, July 31, 2020 11:11 AM
> To: '[e-mail]' <[e-mail]>cn>;
> '[e-mail]' <[e-mail]>cn>; 'Dongjie (Jimmy)'
> <[e-mail]>om>; '[e-mail]'
> <[e-mail]>
> Cc: idr@ietf. org <[e-mail]>rg>; [e-mail]
> Subject: [Teas] draft-xie-idr-bgpls-sr-vtn-mt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi,
> 
> About the following:
> 
> 4.  Scalability Considerations
> 
>    The mechanism described in this document requires that each VTN has
>    an independent topology, and for inter-domain VTNs, the MT-ID used
> in
>    each involved domain is consistent.  While this brings the benefits
>    of simplicity, it also has some limitations.  For example, it means
>    that even if multiple VTNs may have the same topology attribute, they
>    would still need to be identified using different MT-IDs in the
>    control plane.  This requires that for each VTN, independent path
>    computation would be executed.  The number of VTNs supported in a
>    network may be dependent on the number of topologies supported,
> which
>    is related to the control plane computation overhead.
> 
> As I mentioned after Cong's presentation in IDR, Flexible TE (Flexible
> Algorithm + SR-TE + Targeted Distribution) addresses the above scaling
> concerns. I also have some further thoughts on advertising other
> attributes, to be published in later revisions of my
> draft-zzhang-teas-flexible-te draft.
> 
> Would like to hear your thoughts.
> 
> Thanks.
> Jeffrey
> 
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas_
> _;!!NEt6yMaO-gk!U5ARee2LojrOjDlBuFV-m1hPriQ0KLGu4zNhkpLmgjTnuC0y
> 9n3kUr13t4g7CEZN$