Re: [spring] Different MSDs for different traffic types on the same headend.

[Nat Kao <[e-mail]>]

Hello, Robert.

Surely the current BMI-MSD definition is sufficient for platforms without
artificial boundaries.
In this ideal case, maximum labels available for SR-TE policy can be
inferred from BMI-MSD and VPN routes.

However we have 3 different artificial boundaries across 3 different
platforms now.
Hardcoding these boundaries might not scale well. (Especially different OS
versions may behave differently.)
A standard mechanism to discover this boundary would greatly help
constructing SR-TE policy candidate paths.

Regards,
Nat.


On Tue, Dec 17, 2019 at 5:58 PM Robert Raszuk <[e-mail]> wrote:

> Hi Nat,
>
> I am having a bit of difficulty understanding reasoning and the way you
> are separating transport from service labels.
>
> The processing label limit usually comes from data plane capabilities of
> the platform namely LFIB or hardware below.
>
> Such layer is function agnostic and it does not matter what role the label
> serves.
>
> Label lookup results in pointer to a adj. rewrite on the outbound side. It
> really does not matter if the adjacent peer is your P router, segment
> endpoint or CE.
>
> Of course there are number of processing exceptions - for example concept
> of aggregate VPN label, additional header modifications etc ...
>
> Likely some platforms put such artificial boundary between transport and
> service hence your request. But if so IMHO this is more of an issue with
> specific platform or its marketing message then IETF :).
>
> Many thx,
> R.
>
>
>
>
>
>
>
> On Tue, Dec 17, 2019 at 6:06 AM Nat Kao <[e-mail]> wrote:
>
>> Hi, Jeff.
>>
>> Consider a headend that can perform 1 of the following 2 modes(but not
>> both):
>> 1) Plain IPv4: 6 transport labels + 0 service label => traffic can be
>> steered into a 6-label SR-TE policy.
>> 2) Any type of VPN: 3 transport labels + 1~3 service labels => traffic
>> cannot be steered into a 6-label SR-TE policy.
>>
>> a) As defined in RFC8491, the BMI-MSD is 6 for this headend. Do we have a
>> standardized way to signal the transport label depth in mode 2?
>>    Maybe in a different MSD type?
>> b) Since plain IPv4 and VPN routes can be steered into the same SR-TE
>> policy, do we have a standardized headend behavior in this situation?
>>    (Should I open a new thread to discuss this? It seems not quite
>> MSD-relative.)
>>
>> Thanks..
>> Nat
>>
>>>
>>> On Tue, Dec 17, 2019 at 7:19 AM Jeff Tantsura <[e-mail]>
>>> wrote:
>>>
>>>> Gyan,
>>>>
>>>> MSD is only relevant for a device that either imposes the label stack
>>>> (head-end) or manipulates it (BSID anchor). There are some other constrains
>>>> when it comes to entropy labels and ERLD, please read the respective drafts.
>>>> In general, SID stack would grow when TE is in use (any time you need
>>>> to use additional SID to deviate from SPT), another case is when additional
>>>> SID’s are used for services on the nodes, other than the tail-end.
>>>> That’s why we've designed MSD to be very flexible to accommodate all
>>>> the different use cases, it is upto computational logic to decide how to
>>>> deal with different constrains (MSD types)
>>>>
>>>> Cheers,
>>>> Jeff
>>>>
>>>> P.S. you might want to see the NANOG MSD presentation I did some time
>>>> ago.
>>>>
>>>> https://pc.nanog.org/static/published/meetings/NANOG71/1424/20171004_Tantsura_The_Critical_Role_v1.pdf
>>>> On Dec 14, 2019, 11:59 PM -0800, Gyan Mishra <[e-mail]>,
>>>> wrote:
>>>>
>>>> Jeff
>>>>
>>>> With SR-MPLS with SR-TR let’s say if you use cSPF snd don’t have an ERO
>>>> strict explicit path defined or is a loose path, then the for the cSPF
>>>> would the transport labels be 1.  For loose would also be 1 also.  If the
>>>> path were explicit defined to egress PE and was 7 hops from ingress to
>>>> egress then transport would be 6.  And if L3 vpn service sid was signaled
>>>> that would be 1 vpn label.
>>>>
>>>> Let me know if I have that right.
>>>>
>>>> In Nats scenario for IPv6 he has 3 vpnv6 labels.
>>>>
>>>> Why is that?
>>>>
>>>> With both SR-MPLS and SRv6 the L3 vpn AFI/SAFI MBGP services overlay
>>>> single label sits on top off SR as if does today with MPLS so why 3 vpn
>>>> labels.
>>>>
>>>> So with this draft with BGP-LS and BMI-MSD you can flood into the IGP
>>>> the SID depth so all the nodes along the SR-TE path don’t go over the
>>>> maximum which would result in an error.
>>>>
>>>> If you set your MTU high enough in the core like 9216, does that
>>>> overcome the SID depth issues with SR-TE?
>>>>
>>>> Warm regards,
>>>>
>>>> Gyan
>>>>
>>>> On Sat, Dec 14, 2019 at 2:43 AM Nat Kao <[e-mail]> wrote:
>>>>
>>>>> Hi, Jeff.
>>>>>
>>>>> Thanks for the BMI-MSD reference. If I understand correctly:
>>>>>
>>>>> BMI-MSD = Transport Label Depth + Service Label Depth
>>>>> Only former can be utilized by SR-TE policies.
>>>>>
>>>>> Currently do we have any method to determine the composition of BMI?
>>>>> We need to know the transport label depth when doing service route
>>>>> per-destination steering.
>>>>>
>>>>> This problem arises when trying to steer a plain IPv4 route and a VPN
>>>>> service route into the same SR-TE policy that exceeds the transport label
>>>>> depth of the service route. I'm trying to figure out the standard behavior
>>>>> in this case since the headend we use currently produces some interesting
>>>>> results.
>>>>>
>>>>> Regards,
>>>>> Nat.
>>>>>
>>>>> On Sat, Dec 14, 2019 at 2:42 AM Jeff Tantsura <[e-mail]
>>>>> <[e-mail]>> wrote:
>>>>>
>>>>>> Hi Nat,
>>>>>>
>>>>>> Please read https://tools.ietf.org/html/rfc8491#section-5
>>>>>> Currently defined MSD types are:
>>>>>> 1: BMI
>>>>>> 2: ERLD
>>>>>>
>>>>>> Specifically to BMI:
>>>>>> Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels
>>>>>> that can be imposed, including all service/transport/special labels.
>>>>>> The answer to your question is 6
>>>>>>
>>>>>> Cheers,
>>>>>> Jeff
>>>>>> On Dec 13, 2019, 3:42 AM -0800, Nat Kao <[e-mail]>,
>>>>>> wrote:
>>>>>>
>>>>>> Hello, SPRING WG.
>>>>>>
>>>>>> How do we deal with an SR-TE policy headend with different MSDs for
>>>>>> different types of traffic?
>>>>>> For example, a headend H can impose:
>>>>>> 6 transport labels for plain IPv4 packets;
>>>>>> 5 transport labels + 1 IPv6 ExpNull label for plain IPv6 packets;
>>>>>> 3 transport labels + 3 VPN  labels for VPN packets.
>>>>>>
>>>>>> a) For a plain IPv4 route R4 and a VPN route Rv both steered into the
>>>>>> SR-TE policy P1 with SID list <S1, S2, S3, S4, S5>, what will H perform in
>>>>>> this situation?
>>>>>> b) What is the MSD of H? 6, 5 or 3?
>>>>>>
>>>>>> Thanks,
>>>>>> Nat.
>>>>>> _______________________________________________
>>>>>> spring mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>
>>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>
>>>> --
>>>>
>>>> Gyan S. Mishra
>>>>
>>>> IT Network Engineering & Technology
>>>>
>>>> Verizon Communications Inc. (VZ)
>>>>
>>>> 13101 Columbia Pike FDC1 3rd Floor
>>>>
>>>> Silver Spring, MD 20904
>>>>
>>>> United States
>>>>
>>>> Phone: [phone]
>>>>
>>>> Email: [e-mail]
>>>>
>>>> www.linkedin.com/in/networking-technologies-consultant
>>>>
>>>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>