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

Nat Kao <lekao@pyxisworks.org> Tue, 17 December 2019 05:05 UTC

Return-Path: <lekao@pyxisworks.org>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF4D1200A3 for <spring@ietfa.amsl.com>; Mon, 16 Dec 2019 21:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pyxisworks-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffk-FTCBYPjX for <spring@ietfa.amsl.com>; Mon, 16 Dec 2019 21:05:25 -0800 (PST)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3B9120059 for <spring@ietf.org>; Mon, 16 Dec 2019 21:05:25 -0800 (PST)
Received: by mail-oi1-x229.google.com with SMTP id c16so4163021oic.3 for <spring@ietf.org>; Mon, 16 Dec 2019 21:05:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pyxisworks-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sWp6mUKqPYJo2Zpuh0Cj3S2HJVakVhOP0krzuBdqDsY=; b=BkjIebtJiKjHTs/DTM1cMoP6ZxL+JUiMha4uIRgMPM/xLeQMqntnGGWBYim1v/Dedd EDKiRqamX/RxwXHZhfdY0x6s1nfjas7MQl74a/xupiIfgApTntukhMhmDklVB6/bXQvr 7a7HkRsSzUw6ffnQhoVdRrShx2fVcj3G2qo76KwlCyOqHZQccfO07IJ4ifrJ9naL7jB7 H2nZ0mvx0whiKFc/tRNbcoXaNPhB6+CUsfiyeYr+tMqbZijeK89NaBDK0M7hHMhAcL0a W0S1BpHNpVew4yMhW95OR1p2dW/3kN7f7C/teIeYlgj9Lp1c1hif+s9jqcbzRJwNS3QQ jS6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sWp6mUKqPYJo2Zpuh0Cj3S2HJVakVhOP0krzuBdqDsY=; b=fC+A5spHKlWZ2YkWN4+FmYpn4Q8Ler/Db+LtwXqgOQ7DAivkN0ctDbanzcT7iB+H+V joTpC1pX8aKI4wojfcxXGzVum/Ai0V8jhR409Aa4ZlKODRtIGa2D7+Vp1XVkyhMtErAS pcoTEOYbQdEEuGJcE2ZdJFzUgWJJ0SklgmFy0eCE785xp7yhRjzXFtyIG+GhISf++a8O c4TfsR0yr2R7bC7qCCevW8WHb5P9CmpPAyx08zNPQuANIIz+lbBpt8nVyclwrVuUnvMN Tbv06lNJ9FXpM7DP1XiJk145xoy3eNRtyO6+uZyFI9xvwaKiFIvyJg/R6QuNtIkT4FAQ 9E9A==
X-Gm-Message-State: APjAAAWsQDo6RJ3JgER+sDftnTJm57tFA0BsSpmapzFPZM8schLZs7+1 4/StErs2R40VXoYuJpmuL2tNhKtNAGw21rI3g9uB6idQoOk=
X-Google-Smtp-Source: APXvYqxkN2kghFYIgQjUi4BfLMOvPOi7cSqiCP6T1iQjtaeoLn+cNRh3L5qUwtbZd95cYy/0lAxVsrT3BpreA9VmuSw=
X-Received: by 2002:a05:6808:658:: with SMTP id z24mr1151887oih.91.1576559124740; Mon, 16 Dec 2019 21:05:24 -0800 (PST)
MIME-Version: 1.0
References: <CAN3QBScGjeL=yDSW3AOXZrVTGA-czbY2qDrOMQ=gDxAd4d=nYQ@mail.gmail.com> <38b14bf5-b6d9-4d46-ad1d-d26d3376df51@Spark> <CAN3QBSf2Kpu3Pd_FYmA7BCHJ=uWu9DnEEaYdQwGDDs26NmbJQg@mail.gmail.com> <CABNhwV1-yRcK18JsJbAr3e+Hm-35WdmUFZ0mkzwLj5iBD9zWxw@mail.gmail.com> <c8967bfb-5a8e-447d-8e28-314820764f13@Spark> <CAN3QBScyJ5QgmKU8_h62pLF=FQ8y40C3sSRB1TWfKBQfdb1Mkw@mail.gmail.com>
In-Reply-To: <CAN3QBScyJ5QgmKU8_h62pLF=FQ8y40C3sSRB1TWfKBQfdb1Mkw@mail.gmail.com>
From: Nat Kao <lekao@pyxisworks.org>
Date: Tue, 17 Dec 2019 13:05:13 +0800
Message-ID: <CAN3QBSdFVCBQVPVc2Ax0i2EgMrGqzSCj7YpsUUE2m3HiM9AcyA@mail.gmail.com>
To: spring@ietf.org
Cc: Nat Kao <lekao@pyxisworks.org>
Content-Type: multipart/alternative; boundary="000000000000990f7f0599df46c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/PKNx4UcK3QdiYIuyamHf926tB2E>
Subject: Re: [spring] Different MSDs for different traffic types on the same headend.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2019 05:05:29 -0000

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 11:14 AM Nat Kao <lekao@pyxisworks.org> 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 <jefftant.ietf@gmail.com>
> 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 <hayabusagsm@gmail.com>om>,
>> 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 <lekao@pyxisworks.org> 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 <jefftant.ietf@gmail.com
>>> <jefftant..ietf@gmail.com>> 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 <lekao@pyxisworks.org>rg>, 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
>>>> spring@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>
>>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> 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: 301 502-1347
>>
>> Email: gyan.s.mishra@verizon.com
>>
>> www.linkedin.com/in/networking-technologies-consultant
>>
>>