Re: [Idr] draft-ietf-idr-te-lsp-distribution questions

[Boris Hassanov <[e-mail]>]

 Hi Ketan, GyanMy short feedback on the proposal to extend the reporting capabilities by adding additional info (path segment etc.), although it is understandable I afraid that we can get into quite long cycle of  adding new extensions that can slow down the implementations for reporting the state of a SR Policy. So some balance is needed.
Thanks.
SY,Boris


    On Wednesday, January 25, 2023 at 07:55:45 AM GMT+3, Gyan Mishra <[e-mail]> wrote:  
 
 
Thank you Ketan
I am all set.
Kind Regards 
Gyan
On Tue, Jan 24, 2023 at 10:02 PM Ketan Talaulikar <[e-mail]> wrote:

Hi Gyan,
Please check inline below with KT2 for a few clarifications.
On Tue, Jan 24, 2023 at 11:09 AM Gyan Mishra <[e-mail]> wrote:

Hi Ketan 
Welcome!
Responses in-line 
Thank you
On Mon, Jan 23, 2023 at 10:06 PM Ketan Talaulikar <[e-mail]> wrote:

Hi Gyan,
Thanks for your feedback and please check inline below for responses.
On Fri, Jan 20, 2023 at 9:26 AM Gyan Mishra <[e-mail]> wrote:

Hi Jeffrey 
I read the draft as well and I agree with you that it is primarily goal is to coalesce all the characteristics of RSVP-TE and SR Policy into new BGP-LS TLVs to collect to build a network visualization of a domain wide multi area or AS view for stateful path computation and instantiation by means other than centralized PCE.  I agree also the goal is to collect the multicast related RSVP-TE or SR P2MP policy using the cross connect interfaces TLVs.  
I agree with your recommendations for enhancements mentioned to support multicast.  Makes sense.
Overall I think the draft is very useful as SR policy can be complicated and  building the data structures and transporting to a single painted glass NMS station or controller is a great idea.  
Dear Authors 
Few comments on the draft.
I noticed the metric type - IGP, latency, TE, hop count is missing 

KT> Please check Sec 9.8.

    Gyan> Ack


Also noticed Flex Algo constraint missing

KT> FlexAlgo constraint is signaled into BGP-LS via IGPs and covered by the BGP-LS FlexAlgo draft. 
    Gyan> Ack.  My thought was that as the goal of this draft is to graph the SR policy into BGP-LS I was thinking along the lines of the SR Policy flex algo constraint “SR-Algo” knob that exists for SR-MPLS or SRv6 SR Policy to instantiate the SR policy steering over an Algo colored links.

KT2> We already have this covered via the Algo in the constraints TLV - please see sec 6.6 



Also static SID list weight for UCMP should be added 

KT> Please check sec 6.7 where we have weight per SL.
      Gyan> Ack 



Maybe ODN and automated steering color and colorless policy should be added 

KT> These types can be reported via this specification - please let us know what you think is missing to do that.

    Gyan> In section 4.5 where you specify the policy color and endpoint maybe also specify ODN where only color signaling is used for the dynamic endpoint tuple to be created.  For automated steering specifically the 0.0.0.0/4 next hop best path.  

KT2> The color-only is a BGP steering construct over SR Policy. Here we are reporting SR Policies. That said, the draft does cover the reporting of null-endpoint SR Policies that are used for color-only steering.
Thanks,Ketan 

 

Also I think SRv6 compression draft C-SID should be added.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-03

KT> There is no control plane extension required for C-SID since it leverages base SRv6 - that also applies to this draft. Please let us know if you think anything is missing. 
    Gyan> Yep makes sense.


I think maybe MPLS and Spring path Segment should be included.
SRv6 path Segment 
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment
SR-MPLS path Segment 
https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment
BIDIR path Segment 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment
Possibly SR-PM monitoring policy so that tracking data monitoring of SR policy endpoints within the policy can now be monitored by external applications.

KT> I will discuss with co-authors and get back. Please also check draft-ietf-idr-bgp-ls-sr-policy-path-segment 

    Gyan> Ack.  I think good idea to discuss with the authors on feedback.

Thanks,Ketan 

Kind Regards 
Gyan


On Wed, Jan 18, 2023 at 9:01 AM Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]> wrote:

Hi,

I have some questions on this draft.

It apparently is TE-specific (RSVP-TE or SR policy) and unicast-specific. While it mentions multicast in the cross-connect case, it is not clear how multicast state is reported. For example, if a node needs to replicate to 10 branches, would there be 10 cross-connect NLRIs used, each for a replication branch? If so, what is the use case of multiple outgoing interfaces?

Also, is the cross-connect NLRI intended only for locally "configured" (vs. signaled by RSVP-TE), as implied by the following text?

   In many network environments, traffic engineering (TE) policies are
   instantiated into various forms:

   *  MPLS Traffic Engineering Label Switched Paths (TE-LSPs).

   *  Segment Routing (SR) Policies as defined in [RFC9256]

   *  Local MPLS cross-connect *configuration*   <------

Relatedly, are the TE-LSP and SR policy NLRI intended for headend only (and not used to report RSVP-TE state on transit-nodes)?

Consider the following two use cases:

- Hop-by-hop signaled mLDP trees are used in a network but the operator wants state on the tree nodes to be reported to a controller for display/visualization purpose.
- A PCE signals SR-P2MP trees via BGP and it needs confirmation from tree nodes that replication state has been set up as signaled.

I had initially thought that the cross-connect NLRI can be used for that, but looks like quite some enhancements would be needed:

- make the draft applicable to non-TE as well
- make the cross-connect NLRI applicable to beyond local configuration
- add attribute to the cross-connect to indicate tree information (e.g. mLDP FEC, RSVP session object)

Alternatively, make the TE-LSP and SR policy NLRI applicable to transit nodes as well and report the cross-connect information as attribute.

If this makes sense, do we want to extend the existing draft or should I start a new draft?

Thanks.
Jeffrey

Juniper Business Use Only

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

-- 




Gyan Mishra

Network Solutions Architect 

Email [e-mail]


M 301 502-1347



_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr


-- 




Gyan Mishra

Network Solutions Architect 

Email [e-mail]


M 301 502-1347





-- 




Gyan Mishra

Network Solutions Architect 

Email [e-mail]


M 301 502-1347



_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr