Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

Gyan Mishra <hayabusagsm@gmail.com> Fri, 30 December 2022 20:20 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64AFC151713 for <idr@ietfa.amsl.com>; Fri, 30 Dec 2022 12:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.984
X-Spam-Level:
X-Spam-Status: No, score=-1.984 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eTqmj7wv-Iy for <idr@ietfa.amsl.com>; Fri, 30 Dec 2022 12:20:38 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B96C14CE2B for <idr@ietf.org>; Fri, 30 Dec 2022 12:20:38 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id df17so11766852qvb.3 for <idr@ietf.org>; Fri, 30 Dec 2022 12:20:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3viLQcYr7WQUoRUtNByTkJIvgvNwmODhkvSTv1Rmed8=; b=jTINpfE8xer79upk/FvUO4Hb642euyVIDWx5zJQ5Yue0+HIXbfC3qTtfAz6K+obzI8 1hcgMQxI4k82CUJRWES2p9QJCdn+hnL6RODB+Lsoo7zI/eaGUfVfJPobjPiIODXbXDzz 7JiZY2TVr0MonqdLxNMBu/luTeu9H+yQhbSTsjCF098eSymDvUVX9+XCvfraxjaJdjfn 3486exlpocwlIx0hRk3o4HfjRTDWQbIVKE9vj+1drqVYNF+HD71+6XKZFo4XS5k81mCe mLp1xp8XDDuwpHgzpyC3lexKaYuDrVwM6cLRNnK7MI/LNkqZOTrwEdUnvAMdk8wNTs/d FMuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3viLQcYr7WQUoRUtNByTkJIvgvNwmODhkvSTv1Rmed8=; b=dF94EzN9anheXmlqKy5cvh7cFsKqMFm/rK5jt7eGLk2s751pC8PH1dSfF1ZGouTyr/ iWO+oCJ4CTsTmnq4Fbqzuu1EJUYk3N6PbMIY5zAUe3tAytBpaDqtz8qWk+S3ILGfeFKm x7kR6IqW5RFHCUEQN34sGl46bOr5dEhLHxt4/mYddjaKWSoXyw5+psrgVCBlKQrqhtgu LTEQCwrcYTVXWSezKMvjFGMspPrNkQ+BFfrShVgOVD9H9bxumQnQFu2Q2U2SJtUZMu+C uQpwZ3TJHoLGFpcNftODtBbMnzKaezl7y3u3o59syYPZMrbRfGzZFiDE4jqb65Nh5+Kr ThTQ==
X-Gm-Message-State: AFqh2kroEhaylag92bHQ6HE2Ra4dSJ/O2k7AYEaIQ+GVkIcvnknOaaCZ +p7ZNvqeRfWVA5xE5sw8xFfA2KUcYECrIykT5XUHe6sW
X-Google-Smtp-Source: AMrXdXu8n+FWHHi0ScSqnpiwdA995wUBZ7J1/nFBhasMsFc0HzkxteE80poUc5rP+p0M/5LXX3NV5rHm3hMxeCerrbQ=
X-Received: by 2002:a05:6214:3784:b0:4da:d0a:b433 with SMTP id ni4-20020a056214378400b004da0d0ab433mr1345019qvb.13.1672431636914; Fri, 30 Dec 2022 12:20:36 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR08MB4872B6B3A9AE7B008463795DB3E99@BYAPR08MB4872.namprd08.prod.outlook.com> <CABNhwV22EvjvWxkVb+geFOfLzej-c_NNSC6zJtRqj8SmG=FyLw@mail.gmail.com> <BL0PR05MB5652D74BD9EEEB3F934A86EED4F09@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5652D74BD9EEEB3F934A86EED4F09@BL0PR05MB5652.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 30 Dec 2022 15:20:25 -0500
Message-ID: <CABNhwV26XLSWnzu_BiGLjVDTSgdLvp6YL1uNpbOYKbd_LPFYbQ@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a1254f05f1115521"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/P3LMtT4sPxRi6ei_1I23yKsgBQU>
Subject: Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2022 20:20:42 -0000

Hi Jeffrey

So in summary what you are saying is normally with MPLS RFC 3032 you push
the label stack before the NLRI encoding since SR Policy TEA color / intent
mapping does not come into play for vanilla mpls label stack domain.

However with SR-MPLS with SR Policy the TEA endpoint 2 tuple comes into
play {color, endpoint}.  So now the core routers need to see the RFC 9012
TEA for the egress PE tunnel endpoint termination for the SR policy and
since the BGP update has all the common path attributes per update packing
we have the TEA sub TLV is in the same packet as the service label and so
now we need NLRI encoding before the label stack is pushed onto the packet
so the core router see the TEA tunnel endpoint info.  So this same concept
update to RFC 9012 is applicable as well for inter-as steering to sites
connected to the core steering past the core tunnel endpoint egress PE to
the connected sites.  In that particular case would it be a CSC
hierarchical VRF backbone carrier and customer carrier and in that case
between the ASs you would have inter-as PE-PE link so the other side of
PE-PE inter-as link would be the source PE for steering within the site 1
or 2.  So this would be like a seamless SR use case inter-as coloring to
intent  mapping or translation per AS hop if the coloring is different per
AS hop.  Also the L3 VPN service label NLRI encoding SAFI 128  would be
extended end to end per inter-as options.

Below stick diagram

Site 1                            Core                  Site 2

PE1 - P - PE2 — PE3 - P - PE4 — PE5 - P - PE6

PE2-PE3 and PE4-PE5 are inter-as L3 vpn links / inter-as TE links

The SR source  node in each AS for the SR policy AS hop stitching for the
end to end path built by the stateful PCE would be ..

Left to Right

PE1, PE3, PE5

Right to Left

PE6, PE4, PE2

So in the case going left to right LSP  where Site 2 PE5 is not capable of
pushing the label stack, would it be PE4 not PE3 that would provide a proxy
service acting as a source node to push the label stack onto the packet.
If this is within the same administrative domain, option C  end to end LSP
it’s  possible to leverage a different PE in another domain to push the
label stack.  However if it’s between administrative domains option B
stitched LSP then you would more than likely not be able to leverage a PE
in another domain to push the label stack.

Thanks

Gyan

On Fri, Dec 30, 2022 at 10:12 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Gyan,
>
>
>
> Please see zzh> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Gyan Mishra
> *Sent:* Thursday, December 29, 2022 10:47 PM
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* idr@ietf.org
> *Subject:* Re: [Idr] WG adoption of
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to
> 1/13/2023
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> I read the draft and have questions related to the reason for the two new
> Segment sub-tlv to encode a segment list in compact format.
>
>
>
> I read through the thread on the comments from Robert and I have similar
> questions which I will reiterate to help get to the goal or objective of
> the draft which is confusing to the reader.
>
>
>
> Let’s first understand and agree on the label stack encoding for MPLS and
> SR-MPLS.
>
>
>
> Let’s start with standard MPLS Label Stack RFC 3032.  So with RFC 3032 you
> have transport label TL and then the L2 or L3 VPN service labels Bottom of
> Stack labels with S bit set.
>
>
>
> RFC 6790 defines the Entropy label EL and Entropy Label Indicator ELI
> encoded {TL, ELI, EL, SL} where SL is the service label with S bit set.
>
>
>
> The way I read RFC 8660 SR-MPLS section 2.7 the label stack for steering
> is imposed on the packet where the TL would normally be placed on the SR
> source node once the SR Policy BSID is popped and the Candidate path
> defining the SID list is bound to the forwarding plane.
>
>
>
> RFC 8662 SR Entropy Label section 4 shows the ERLD and in this case you
> can see as well the SR label stack imposed on the packet once the BSID is
> popped on the source node TL is now replaced with SR label stack {SR label
> stack, ELI, EL, SL}  where SL is the service label.
>
>
>
> So now if we agree on the MPLS and SR-MPLS label stack encoding we can
> discuss the draft further below.
>
>
>
> Section 1 talks about traffic steering after the tunnel endpoint.  SR
> policy defines a 2 tuple {color, endpoint} so the endpoint is the egress PE
> loopback tunnel endpoint which is defined in the TEA for SR Policy.
> Section 8.4 of RFC 9256 defines the per destination SR policy color /
> intent mapping where egress PE endpoint signals VPN overlay TEA color to
> ingress PE SR policy color to intent mapping to instantiate the steering
> path.
>
>
>
> Section 1
>
>
>
> Specifically, the label stack in the sub-TLV is to be pushed BEFORE any
> other labels are pushed. This may sound counter-intuitive, in that if a
> label stack (e.g. for Segment Routing) is to be used to steer traffic to
> the tunnel endpoint, the stack should be pushed AFTER other labels (e.g.
> the label embedded in the NLRI).¶
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-idr-tunnel-encapsulation-label-stack-01*section-1-3__;Iw!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0XSa3EzzQ$>
>
>
>
> Why would this be different for SR-MPLS as compare to MPLS and from the
> above review of the label stack encoding as SR-MPLS is reusing the MPLS
> data plane the label stack encoding should be the same.
>
>
>
> AFAIK I think the SR label stack should still be pushed before the NLRI
> labels are pushed. Why would that be any different??
>
>
>
> I don’t understand the statement below.  Steering is from the SR source
> node to egress PE loopbacks tunnel endpoint. What other steering is there
> past the egress PE tunnel endpoint?
>
> Zzh> If you’re talking about steering TO the (core/base) tunnel endpoint
> (which is the egress PE), you need to push the corresponding label AFTER
> you push the NLRI (service) label (so that the core routers see the tunnel
> label instead of service label). That’s why I said it is counter-intuitive
> to push the labels BEFORE pushing service label, and why we need to clarify
> it is for steering AFTER the endpoint.
>
> Zzh> For traffic steering AFTER the endpoint, it is explained as following
> in the draft:
>
>                  controller
>
>                 .          .
>
>                .            .
>
>     site1 --- PE1 -------- PE2 --- site2
>
>
>
>    Two sites are connected to two PEs respectively, and traffic steering
>
>    is desired within each site not just among the PEs.  While PE2 could
>
>    push the label stack used for steering within site2, there may be
>
>    situations where PE2 is not a device capable of pushing a large label
>
>    stack so PE1 is tasked with pushing the label stack that is used
>
>    after the tunnel end point PE2, within site2.
>
>
>
> Zzh> Notice the red text “within site2” (i.e., AFTER tunnel endpoint
> PE2). Note that the service label mentioned earlier could mean “pop and
> switch out of an interface”, which means there could be labels after that
> service label, which were pushed BEFORE the service label was pushed.
>
>
>
> Two sites are connected to two PEs respectively, and traffic steering is
> desired within each site not just among the PEs. While PE2 could push the
> label stack used for steering within site2, there may be situations where
> PE2 is not a device capable of pushing a large label stack so PE1 is tasked
> with pushing the label stack that is used after the tunnel end point PE2,
> within site2.
>
>
>
> All PEs in the SR domain are ingress/egress PE thus all PEs as they can
> all be source nodes they would have to be capable of pushing the label
> stack onto the packet.  In most SR deployments a stateful PCE is used and
> the source node is programmed to push the label stack onto the packet by
> the stateful PCE.  In this stateful PCE case the SR source node instructed
> by the PCE still has to push the label stack for steering onto the packet.
> So if an SDN controller / PCE is used the same predicament the source node
> still as instructed by the SDN controller has to push the label stack onto
> the packet for steering.
>
>
>
> So no matter what the SR source node has to be capable of pushing the
> label stack onto the packet.
>
>
>
> Zzh> Please see purple text above and notice the word “large”.
>
> Zzh> Also note that I did not come up with this use case or corresponding
> mechanism. I found it counter-intuitive and want to document what I found
> out by offline email inquries, so that it will help other people and so
> that the feature could be more widely used.
>
> Zzh> Jeffrey
>
>
>
> I have more questions but I think this is a good start and will help steer
> tbe discussion.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Fri, Dec 23, 2022 at 1:37 PM Susan Hares <shares@ndzh.com> wrote:
>
> This begins a 3 week WG adoption and IPR call for
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01.txt
>
>
> https://datatracker.ietf.org/doc/draft-zzhang-idr-tunnel-encapsulation-label-stack/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-idr-tunnel-encapsulation-label-stack/__;!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0W1VfX5mA$>
>
>
>
> The Authors should send an IPR statement regarding this draft.
>
>
>
>
>
>    RFC 9012 defines an MPLS Label Stack sub-TLV for Tunnel Encapsulation
>
>    Attribute, and specifies that it is to be pushed BEFORE other labels.
>
>    This document clarifies the use case for that, defines a new Tunnel
>
>    Label Stack sub-TLV for a label stack to be pushed AFTER other labels
>
>    (e.g., the label embedded in the NLRI for a labeled address family,
>
>    and/or the stack in an MPLS Label Stack sub-TLV), and defines two new
>
>    Segment sub-TLVs to encode a segment list in a compact format.
>
>
>
> The IDR shepherd for this draft is Jie Dong.
>
>
>
> Cheerily, Sue
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0XfNuqLTw$>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!HzeO33AdrD3O3NiFWMBgU3A6fRX950PEEJLfXjbSy0Y6UvoF1tjn5eJwjO6e6YCEq4nK9ENqhKlCa0WSFAsGuQ$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*