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

[Nat Kao <[e-mail]>]

Hi, Jeff & Ketan.

Should I provide more details about the use cases?
I'm not sure whether this is enough.

Thanks!

On Wed, Dec 18, 2019 at 2:20 PM Nat Kao <[e-mail]> wrote:

> Hi, Jeff & Ketan.
>
> For better discussion, let's assume these first:
>
> "TP-MSD" denotes the maximum transport label depth for traffic without
> service labels.
> "SRV-TP-MSD" denotes the maximum transport label depth for traffic with 1+
> service label(s).
>
> Here's one of the use cases:
>
> A customized best-effort TE process:
>
> 1. Decide which route R (incl. VPN routes) to diverge from its
> shortest-path.
>
> 2. Compute SID-list S for R that satisfies the (TE or whatever)
> constraints.
>
> 3a. If R is a plain IPv4/IPv6 route, we consult TP-MSD.
>     If length(S) <= headend's TP-MSD:
>         Inject an SR-TE policy candidate path P with color X by BGP.
>         Inject a new route R' with color X and larger localpref value.
>     else:
>         This path is not feasible, consider another route.
>
> 3b. If R is a service route, we consult SRV-TP-MSD.
>     If length(S) <= headend's SRV-TP-MSD:
>         Inject an SR-TE policy candidate path P with color X by BGP.
>         Inject a new route R' with color X and larger localpref value.
>     else:
>         This path is not feasible, consider another route.
>
> 4. Repeat 1 to 3 until the main objectives are met.(best-effort approach,
> some might fail)
>
> Notes:
>
> a) Clearly, BMI-MSD >= TP-MSD >= SRV-TP-MSD
> b) TP-MSD & SRV-TP-MSD can be signaled by the same methods as BMI-MSD.
> c) If a change on headend that modifies transport label depths(ex:
> recirculation), TP-MSD & SRV-TP-MSD shall reflect that change accordingly.
> d) If a change on headend that modifies transport label depths of certain
> LCs, TP-MSD & SRV-TP-MSD of those links shall reflect that change, too.
>
> Hope this helps.
>
> Regards,
> Nat
>
>
>
>
> On Wed, Dec 18, 2019 at 8:44 AM Jeff Tantsura <[e-mail]>
> wrote:
>
>> Hi Nat,
>>
>> Please bring your use case to the wg, MSD has specifically been designed
>> to address new types with a very little effort.
>>
>> Cheers,
>> Jeff
>> On Dec 17, 2019, 4:21 AM -0800, Ketan Talaulikar (ketant) <
>> [e-mail]>, wrote:
>>
>> Hi Nat,
>>
>>
>>
>> The MSD framework enables us to define more/new MSD types. If there is a
>> real use-case and requirement (as you express) and the necessary MSD
>> type(s) can be formally defined then perhaps the WG can evaluate it.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>> *From:* spring <[e-mail]> *On Behalf Of* Nat Kao
>> *Sent:* 17 December 2019 17:16
>> *To:* Robert Raszuk <[e-mail]>
>> *Cc:* SPRING WG <[e-mail]>; Nat Kao <[e-mail]>
>> *Subject:* Re: [spring] Different MSDs for different traffic types on
>> the same headend.
>>
>>
>>
>> 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
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>>