Re: [Idr] Queries on draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-18.txt

[Abhishek Chakraborty <[e-mail]>]

Thanks a lot Ketan. This definitely helps.

Thanks and Regards,
Abhishek



Juniper Business Use Only
From: Ketan Talaulikar <[e-mail]>
Sent: Monday, November 21, 2022 10:21 PM
To: Abhishek Chakraborty <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Queries on draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-18.txt

[External Email. Be cautious of content]

Hi Abhishek,

Please check inline below.


On Mon, Nov 21, 2022 at 7:06 PM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
Thanks a lot Ketan.
This clarifies my doubt.

But then one more query is that:
If both of these TLVs are different then why we need to have a D flag in SR-MPLS BSID?

KT> The SR BSID TLV works for both SR-MPLS and SRv6 BSIDs

Since these 2 TLVs are separated out and an SR-MPLS BSID TLV is always guaranteed to carry a label and SRv6 BSID TLV (Type 1211) will be used to carry a SRv6 BSID. If this 2 TLVs had been same then only the D flag has some purpose. Else depending on the Type of TLV it can be decoded, or depending on the Address family of the BSID it can be encoded. Right?

KT> The SRv6 BSID TLV was added later on to enable additional signaling (e.g. endpoint behavior) that could not be introduced in a backward compatible manner in the previously defined TLV.

Thanks,
Ketan


I am trying to figure out the case where an SR-MPLS BSUD TLV can carry a SRv6 BSID as we already have a separate TLV to encode SRv6 BSID.

Thanks and Regards,
Abhishek



Juniper Business Use Only
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 21, 2022 6:59 PM
To: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Queries on draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-18.txt<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-18.txt__;!!NEt6yMaO-gk!E4HBDwiL0bLUoZGuKGR2EJNKC1kWKbi19IXSqQTE6uTmHxhVkHU_5dndDh4T1pQA1tO8c2d3JXZf3wSHE7E$>

[External Email. Be cautious of content]

Hi Abhishek,

The D-flag in the BSID TLV only indicates whether the BSID is an MPLS label or SRv6 SID.

The D-flag in the CP Constraints TLV and SR SL TLV indicates the data plane of the path.

Hope this clarifies.

Thanks,
Ketan


On Mon, Nov 21, 2022 at 6:50 PM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Ketan for your reply.

So then for SR-MPLS BINDING SID (Type 1201) the D flag indicates the dataplane for the BSID. So I am guessing that this is to indicate the forwarding state of this BSID is whether formed of labels or SRv6 SIDs. So in that case this is kind of an inter-networking scenario.
Can't we provide such flag in SRv6 BSID TLV as well or do we always expect that SRv6 BSID must only have SRv6 Dataplane?

Thanks and Regards,
Abhishek



Juniper Business Use Only
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 21, 2022 6:21 PM
To: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Queries on draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-18.txt<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-18.txt__;!!NEt6yMaO-gk!EB4n7mYskzp8oEnrX1Utgl14fNWOUOc6AZ6K7uY4AzAbzo5w8qvXQ-TsRyGTPhS7O5ipgSdM15NyjL2yOnY$>

[External Email. Be cautious of content]

Hi Abhishek,

Please check inline below for response.


On Sun, Nov 20, 2022 at 12:24 AM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
I hope all are doing well.

Hello Ketan,

It is a long due query from my side on this draft but couldn't find time to shoot out an email.

1.
When I see section 6.1 and 6.2 for binding SID, the flag bits for these 2 section overlap each other at 0th bit with 2 different flags:
For SR Binding SID:
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |D|B|U|L|F|                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For SRv6 Binding SID:
          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |B|U|F|                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The D bit is used to identify if the SID is SR-MPLS or SRv6. Now the B flag in SRv6 Binding SID is placed at the 0th Bit in the draft. Is it a typo or intentional which I am missing? Shouldn't the SRv6 flag have the beow:

KT> The flags field for the two TLVs are different. While some flags may be the same, the intention is not to use the same flags in both cases.

          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |D|B|U|F|                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Depending on D flag the rest of the bits can be parsed.

2.
In section 6.6:
      -  P-Flag: Indicates that the CP prefers the use of only protected
         SIDs when set.  This flag is mutually exclusive with the
         U-Flag.

      -  U-Flag: Indicates that the CP prefers the use of only
         unprotected SIDs when set.  This flag is mutually exclusive
         with the P-Flag.
...
..
      -  S-Flag: Indicates that the use of protected (P-Flag) or
         unprotected (U-Flag) SIDs becomes a strict constraint instead
         of a preference when set

P and U flag already says that we use only Protected and Unprotected. How is it different from a strict constraint? Setting P/U means we are using strictly Protected/Unprotected.
Can you please help to clarify.

KT> Without the S-flag, the P/U indicates a preference.  With S-flag, the P/U are strict requirements for SID selection.

Thanks,
Ketan


Thanks and Regards,
Abhishek



Juniper Business Use Only
From: Abhishek Chakraborty
Sent: Friday, July 29, 2022 12:03 AM
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: Queries on draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17__;!!NEt6yMaO-gk!AtWUi34hm-VCXVUtyxjShMT69xgtGDP7RFxWdsH0PyXNzJy5ZWvfXT9KvCmmLgEthlAsgOD6riPDsTgTrgY$>

Thanks a lot Ketan for your response.
It has clarified all my doubts.

Thanks and Regards,
Abhishek



Juniper Business Use Only
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 28, 2022 6:15 PM
To: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Queries on draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17__;!!NEt6yMaO-gk!AtWUi34hm-VCXVUtyxjShMT69xgtGDP7RFxWdsH0PyXNzJy5ZWvfXT9KvCmmLgEthlAsgOD6riPDsTgTrgY$>

[External Email. Be cautious of content]

Hi Abhishek,

Thanks for your email that brings up some very good questions. Please check inline below for responses.


On Thu, Jul 28, 2022 at 3:33 PM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
Hope everyone is doing well.

My queries are regarding the following flags:

  1.  https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17#section-6.7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17*section-6.7__;Iw!!NEt6yMaO-gk!AadXpHLhwOmex9PJdephXXL1Ef1EKb2Dama9xDh4w6VooSngX6wI7WQCaQwbcG06enKPN7ok-dWW7tMZXyY$>


E-Flag : Indicates that SID-List is an explicit path when set
        and indicates dynamic path when clear.



         C-Flag : Indicates that SID-List has been computed for a

           dynamic path when set.  It is always reported as set for

           explicit paths.


     Does E flag only get set for Statically configured segment-list (non-compute) on headend router?

KT> Yes, but not "only" that. Please see further.

     Does E flag includes PCE/Controller provisioned segment-lists as well? Because PCE/Controller provisioned segment-lists are dynamically provisioned by controller on the headend.

KT> Yes.

     Does C flag only gets set for locally computed segment-lists? Because if PCE/Controller provisioned segment-lists are also dynamic paths but not locally computed, will this C flag
                    be set for those as well?

KT> The draft is about reporting from the SR Policy headend. If the headend does not see this as a dynamically computed path (e.g., if it is not delegating computation) then the C flag won't be set.


KT> The reference here is explicit and dynamic paths per RFC9256 and not about how they are provisioned. Specifically, please check section 5.1.

                    What is the meaning of "It is always reported as set for explicit paths" in C flag?

KT> The SID list is pre-computed always for explicit path and hence this flag is always set. For a dynamic path, not all paths may be computed (e.g., if it is not the preferred/active then the path may not yet have been computed).

                   In case of delegation how these 2 flags will be set? Because the computation is done in the controller with the local constraint set.

KT> Please check if my prior response clarifies.



  1.  https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17#section-6.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17*section-6.8__;Iw!!NEt6yMaO-gk!AadXpHLhwOmex9PJdephXXL1Ef1EKb2Dama9xDh4w6VooSngX6wI7WQCaQwbcG06enKPN7ok-dWWAqrqNz4$>

      *  E-Flag : Indicates the SID value is explicitly provisioned

         value (locally on headend or via controller/PCE) when set and

         is a dynamically resolved value by headend when clear

Does this E flag on each segment means if this segment is explicitly configured in the segment-list locally?
KT> This one is not about a dynamic or explicit path but about whether the headend is doing SID resolution. Even for an explicit path, the operator config could be simply using a node's IP address for a Prefix-SID (Type C). The headend needs to dynamically resolve to a SID value and so this flag is not set. For a dynamic path, if the controller is fully resolving the SID values and providing them to the headend then this flag would be set.


i.e. if a segment-list is a mixture of some statically configured segments (non-compute) and some are computed/translated segments, then segment-list will be set with both segment-list C and E flags and only the non-compute segments will be set with E flag?
KT> I hope my previous comments clarify.


Does this E flag be set on all segments of a PCE/controller provisioned segment-list? If yes then will such PCE/Controller provisioned segment-lists be marked with segment-list E flag? But then such segment-lists are not dynamic anymore right?
KT> I hope my previous comments clarify.

Thanks,
Ketan


Thanks and Regards,
Abhishek



Juniper Business Use Only