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

Hi Gyan,

Please check inline below with KT2 for a few clarifications.

On Tue, Jan 24, 2023 at 11:09 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Hi Ketan
>
> Welcome!
>
> Responses in-line
>
> Thank you
>
> On Mon, Jan 23, 2023 at 10:06 PM Ketan Talaulikar <ketant.ietf@gmail.com>
> 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 <hayabusagsm@gmail.com>
>> 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=
>>> 40juniper.net@dmarc.ietf.org> 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
>>>> Idr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
>