>> On Dec 17, 2019, 4:21 AM -0800, Ketan Talaulikar (ketant) <
>> ket...@cisco.com>, 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 e
- label blocks
>> are associated with particular functions and programmed in HW, so the
>> service label would come out of the service range, which is significant to
>> the device advertising it.
>> In modern OS’s the ranges are configurable, in older ones, it is static
>> an
on - label blocks
> > > are associated with particular functions and programmed in HW, so the
> > > service label would come out of the service range, which is significant
> > > to the device advertising it.
> > > In modern OS’s the ranges are configurable, in o
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.
>>
>
es 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 *On Behalf Of* Nat
se 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 On Behalf Of Nat Kao
> > > Sent: 17 Decemb
Cc: SPRING WG ; Nat Kao
> 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 availa
Robert,
While you are correct wrt single ASIC platforms, on a line-card based platforms
(at least ones I’m familiar with and that includes merchant silicon) in some
case service labels were imposed on egress LC while transport on ingress, in
any case, they are imposed at different stages in th
:16
> *To:* Robert Raszuk
> *Cc:* SPRING WG ; Nat Kao
> *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 boundari
:16
To: Robert Raszuk
Cc: SPRING WG ; Nat Kao
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
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
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 matte
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
Thanks Jeff!!
Both SR-MPLS & SRv6 in general I am guessing most deployments have been
centralized controller based model to take advantage of PCEP and SR-TE
policy as necessary automatically instead of statically defined explicit
paths.
For small deployments I guess you could get away with non c
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 ne
Spring
Does anyone know if there are plans to add RSVP PCALC path and reserve
model to both SR-TE for SR-MPLS and TI-LFA for SRv6. That would be good so
that we can still use the benefits of MOLS TE for bandwidth management
using auto bandwidthor PCALC bandwidth management in pcep distributed or
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
egres
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 se
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 you
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
20 matches
Mail list logo
