Re: [spring] https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services

Eduard Metz <etmetz@gmail.com> Tue, 25 May 2021 12:38 UTC

Return-Path: <etmetz@gmail.com>
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 27F6B3A1175 for <spring@ietfa.amsl.com>; Tue, 25 May 2021 05:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.246
X-Spam-Level:
X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ne7e-vTX3GHw for <spring@ietfa.amsl.com>; Tue, 25 May 2021 05:38:10 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 11D443A11AE for <spring@ietf.org>; Tue, 25 May 2021 05:38:09 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id a2so45807406lfc.9 for <spring@ietf.org>; Tue, 25 May 2021 05:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7pypGhQcDIiJMLLmPz5gIzhQQYUqDBKn5bqb23voCao=; b=sAqEtm2ODZzFncY2OJGClDQao0nPHQZabSHDeNdFt+CSCbiBF29Mov5uvMNP60NAWm bDIMqcaA/e1AIYL2hAGpnHvgS71eKZLI20pDJfr2cyVKcJ5spTSURN/AgCurn63Urbrz G7Eq7IbtwuuJWQAzhKhwXCSrikfYQOMYw7yFBv0ghWKyp3cSw/QZDSdzUi23WZPDjkWB JWEYJd2KgXchg6akEwfmJ79LBVGse4O47k+8Kj6p44BMTUtIjHnlU1MbveAZEBtprrXk DtgTuX80BlLyBFPVG9aRKBwgiXH7R+iZS4IXR+RM6y0nr/HpgqKk08qijXxw11OwI2OK Zy0g==
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=7pypGhQcDIiJMLLmPz5gIzhQQYUqDBKn5bqb23voCao=; b=omXs6DbuWIsL4Fisgqlu4qd21LYnZmjH34jEyym03SMF6fstNjDbG73EveKsVTBFRx YCO/iJUdmo+N8DzcdcIriswid1IOPah4UvgBSYuUexj/HgQPn2cFfF/WH2EYL4HD+ak8 Jg2QC8H79eW6+yrt3feikp41N7B07BElIKsKxubUlHfmisHRf4VOybl3LBphjbwVbnOw mXb4xvwMsEzZPxCnGrVYhyhAbsNW3xDedklZcKdDQsh8yzyzMnd1eWqdM+INErIGktZO 2Se2zqukLduYOd7SCqulYS890Q7p5IlrTE0qboGbKkhLRFmyCKn3/lHjyr7RN4eVIJoI wESQ==
X-Gm-Message-State: AOAM530YsD35U/nuibHVU6wcMbXC733cMC3DYEWnA05+uFb7tsJwSxiE VBgHyESfa21u9mmABx6B1+/BaXn4di/n0U9isG0=
X-Google-Smtp-Source: ABdhPJwmsMJelDtDt8iIrsAN15S1SnL4uc4DACep0pL7doWYE8SMyBDpbJfMhzPplN/H429KVfeXQD00102B7enK72A=
X-Received: by 2002:a19:df45:: with SMTP id q5mr13854930lfj.523.1621946286620; Tue, 25 May 2021 05:38:06 -0700 (PDT)
MIME-Version: 1.0
References: <BN6PR05MB3634E92A4D97BA9BB4FAF87BBE2D9@BN6PR05MB3634.namprd05.prod.outlook.com> <MW3PR11MB4570946685D0AF570B620676C12C9@MW3PR11MB4570.namprd11.prod.outlook.com> <BN6PR05MB36344F3B2B48287E8B2CE9A6BE2C9@BN6PR05MB3634.namprd05.prod.outlook.com> <CAOj+MMEwX79ZhknALsYRg7Gen3TmM4XVEmPhH=C64e7xhLYcAg@mail.gmail.com>
In-Reply-To: <CAOj+MMEwX79ZhknALsYRg7Gen3TmM4XVEmPhH=C64e7xhLYcAg@mail.gmail.com>
From: Eduard Metz <etmetz@gmail.com>
Date: Tue, 25 May 2021 14:37:55 +0200
Message-ID: <CAG=3OHfcBsK8u8EuUM1g_UXX5GoSxB4gZ1U-Xc76Rxz0sjYbug@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Rajesh M <mrajesh@juniper.net>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, "gdawra.ietf@gmail.com" <gdawra.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000042441605c326ccea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/qwiBYRcn0tqZ_Bl7yg0ogI3s9SM>
Subject: Re: [spring] https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services
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, 25 May 2021 12:38:15 -0000

For my understanding, draft-ietf-bess-srv6-services describes this (ch 6):


"  When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation. "

and this,

"  When the BGP route received at an ingress PE is colored with an
   extended color community and is being steered over a valid SRv6
   Policy associated with SID list <S1, S2, S3> as described in
   Section 8 of [I-D.ietf-spring-segment-routing-policy], then the
   effective SR Policy is <S1, S2, S3-Service-SID>.  "


To map two different prefixes to a different FlexAlgo you could either:
- Select different Service SIDs for the prefixes taken from the respective
locators associated with the different FlexAlgo's. The ingress will apply a
"default" policy and use the advertised Service SID as destination address.
- Select the same SID for the prefixes and color the routes differently.
The policy on the ingress then determines the (additional) SID to be
applied to the packets.

Correct?
Which one to choose is a matter of architecture / design of the network
(and its services), there are tradeoffs that may be different for an
operator.

In both cases it would be 'per VRF' SIDs

If both are valid, this text:

  "  When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update."

May be changed to something along these lines:

  "  When no additional policy applies to the connectivity to the egress
PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.

To reflect "default behaviour" vs other (based on policy), instead of
best-effort vs policy.

cheers,
  Eduard


On Tue, May 18, 2021 at 5:14 PM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Rajesh,
>
> I am afraid you are mixing layers :)
>
> VRF services can be mapped to any color for transport and that color does
> not need to be subject to PHP.  Flexible Algorithm are layer below services
> and are just about transport in the set of closed domains.
>
> If you look at
> https://datatracker.ietf.org/doc/html/draft-hegde-spring-mpls-seamless-sr-02
> page 14 this should be clear that IL red/blue color label can be carried to
> the egress PE and data can be treaded as red/blue also when traversing such
> egress PEs.
>
> We do not need in general to explode service label space/sid.
>
> Thx,
> Robert.
>
>
>
> On Tue, May 18, 2021 at 4:03 PM Rajesh M <mrajesh@juniper.net> wrote:
>
>> Thanks Ketan,
>>
>>
>>
>> My query is
>>
>>
>>
>> If we allocate SRv6 Service SID per-VRF
>>
>> Let’s assume For this VRF locator assigned is 2001:129:1:13::
>>
>> DT4 SID is-2001:129:1:13::4
>>
>> DT6 SID is - 2001:129:1:13::6
>>
>>
>>
>> a) Now how to support Different flex algo for different routes with in a
>> VRF ?
>>
>>
>>
>> For VRF1 Prefix 10.129.0.0 I want to use color 129…this is OK
>>
>>    - BGP Prefix: 10.129.0.0/16
>>    - color: 129
>>    - Service SID:  2001:129:1:13::4 (DT4 SID)
>>
>>
>>
>> For VRF1 Prefix 10.128.0.0 I want to use color 128
>>
>>    - Prefix: 10.128.0.0/16
>>    - color: 128
>>    - Service SID:  ? (I don’t have service SID based upon color 128,
>>    since above allocation is based upon per vrf)
>>
>>
>>
>>
>>
>> Thanks
>>
>> Rajesh
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Ketan Talaulikar (ketant) <ketant@cisco.com>
>> *Sent:* Tuesday, May 18, 2021 5:35 PM
>> *To:* Rajesh M <mrajesh@juniper.net>et>; gdawra.ietf@gmail.com; Clarence
>> Filsfils (cfilsfil) <cfilsfil@cisco.com>om>; robert@raszuk.net;
>> bruno.decraene@orange.com; spring@ietf.org
>> *Subject:* RE:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi Rajesh,
>>
>>
>>
>> The FlexAlgo for SRv6 is described in
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/__;!!NEt6yMaO-gk!Xn4WAWuXx98Jdyu7VzfkC3hjctbWJEnPiTUcj_bAML3F17iJrr77ruwLY3XyBBXQ$>
>> and that would require different SRv6 Locators for the FlexAlgo. When the
>> SRv6 Service SID is allocated from the SRv6 Locator for a FlexAlgo then the
>> service flow will be forwarded along with FlexAlgo path.
>>
>>
>>
>> I am not entirely sure that I got your question though.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>> *From:* Rajesh M <mrajesh@juniper.net>
>> *Sent:* 17 May 2021 12:30
>> *To:* gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <
>> cfilsfil@cisco.com>gt;; Ketan Talaulikar (ketant) <ketant@cisco.com>om>;
>> robert@raszuk.net; bruno.decraene@orange.com; spring@ietf.org
>> *Subject:*
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services
>>
>>
>>
>> Hi All,
>>
>>
>>
>> As per draft
>>
>> “When providing best-effort connectivity to the egress PE, the ingress
>>
>> PE encapsulates the payload in an outer IPv6 header where the
>>
>> destination address is the SRv6 Service SID associated with the
>>
>> related BGP route update.”
>>
>>
>>
>> If we allocate SRv6 Service SID per-VRF then how to support
>> a) Different flex algo with in a VRF ?
>>
>> b) Different flex algo with in a internet (default VRF or global)
>>
>>
>>
>> Thanks
>>
>> Rajesh
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>