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

[Gyan Mishra <[e-mail]>]

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
>>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions A**rchitect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>>
>>>>
>>>> *M 301 502-1347*
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*