Re: [spring] CSID proposed clarifications

Gyan Mishra <hayabusagsm@gmail.com> Sat, 23 October 2021 19:47 UTC

Return-Path: <hayabusagsm@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 6A1323A08EB for <spring@ietfa.amsl.com>; Sat, 23 Oct 2021 12:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3SUwMH8gsrB8 for <spring@ietfa.amsl.com>; Sat, 23 Oct 2021 12:47:21 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 3524D3A08AE for <spring@ietf.org>; Sat, 23 Oct 2021 12:47:21 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id w17so5107504plg.9 for <spring@ietf.org>; Sat, 23 Oct 2021 12:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3A71NEWbrkHtqjmI+tCttXSl2bvuAgqaGIFwFS/KTSg=; b=gA9sG5G6U14VunYJAMMmlq6LmjAlHxo/9+1R9lQ8qSrBppMVO5kE4kueASbCm/mfyE 9BPA55NIKogj6VTfrH6hkS/ED+eiUGhf4yAXt1qxpJ+kvTfnkozdbgF02FOoOzWSRhor wnZedIL/hSGhdNO4GrB2GtHeZ3BEL+7fjQbkhGQ2YuYPizjXUOv4QlbxDMAxBEN1DYmw 8f0g4eAToaBc8OIpxwhNmgxgYY10Ntq0654blHTtbCuIBLyft7UWK928Fk88A29C9Dx9 wNROtO2zL7ohtG2OLgtbwFqvdRMqaA7L1ltn/VyIOlsajxNO2zF1Se9D+CeLyEk6jV/P CWaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3A71NEWbrkHtqjmI+tCttXSl2bvuAgqaGIFwFS/KTSg=; b=sqtB55356PWvHMQwbEhZwQ2ZNGm1ztkBQRzgmxUbyYoZQOE8/CFR24aZLnZoRZA+u+ MeHTc10Ukn5Thee12zvov6QrfA3GdS38Uwu8C/ynafMQJImVnav/AQ2c2Mj0WFvYzquP J0ncae3xkz47ORj3yYi+p+OY7dGC4rH9t3NKPIE33Xje918+Pf1sTDNS2s+LbXfxAN14 NZtb3/vH7nYKJxDjrOaJHdqMv1vHlL09K2QCY8TVFbO8jOwHuck1Gj9avOSm8F+/T62v PeK0ECZDA1LvjEmWmafwUZtml1Gqq9ppdeQwB33uyjDzdLFGbdTXUv4DqgumJT88WY9B g4IA==
X-Gm-Message-State: AOAM532yGIFcMxRef54SJyql+Okro6Kqc9Mvk6UGzArlbY8yHRf65uBU 5BmZ9+5grpM5duL5SzgbVXreDpG3UqqPw8gl3eAd6dDY
X-Google-Smtp-Source: ABdhPJzeIhDffn+iqWAWABuDiThUEMTZoc328T3169xTzjilFBkW0smfPG8fYlASEUD3YB8wG5rKZi081TIoQm1QCuQ=
X-Received: by 2002:a17:90b:1649:: with SMTP id il9mr9031388pjb.167.1635018437111; Sat, 23 Oct 2021 12:47:17 -0700 (PDT)
MIME-Version: 1.0
References: <BN6PR11MB40815FF94A9509B46469A4F4C8B89@BN6PR11MB4081.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB40815FF94A9509B46469A4F4C8B89@BN6PR11MB4081.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 23 Oct 2021 15:47:05 -0400
Message-ID: <CABNhwV3Xm=GsTJOgqd+AxfcB1Obj=pjAawGQcdsy0mthX+2z=A@mail.gmail.com>
To: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>
Cc: SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000025363005cf0a6527"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/171lQNYYjaoGreY8vnUSsg7tx9c>
Subject: Re: [spring] CSID proposed clarifications
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: Sat, 23 Oct 2021 19:47:28 -0000

Darren & Authors

The CSID proposed clarifications looks excellent.

In the current draft revision it was clear that both Next and Replace use
the IPv6 IID portion of the address as the container to index the C-SID
using  Argument portion SRv6 SID,  Next having 16 bit NF and 64 bit
argument, and  Replace having 32 bit NF and 16 bit Argument.

For Replace the Argument is 16 bit followed by 0s section 4.2, is that
correct?    So is the field actually 64 bit that the CSID entires reside?

I agree End.x adj-sid strict path has no change to the SRv6 processing as
the SID in SRH gets copied directly to DA, so no complex indexing of the
SID from Argument portion of SRv6 SID in the SRH.

The difference between End.x and End is End Prefix sid is global in IGP
where End.x is local not in IGP.

Note that the very long strict paths is what requires compression End.x
versus End endpoint behaviors, although both endpoints for overall
compression solution  is  required.

I believe a lot of the contention is with End and not End.x as far as
violation of IPv6 specification, indexing of the CSID within the SRH SID,
argument portion of the address.

The End, prefix sid SRv6 processing is more complicated as the indexed SID
is copied from the SRH Argument portion of the SRv6 address to DA.

Excerpt below from your pseudocode below really helps clarify the exact
differences of the bits within the C-SID container that gets copied  to DA
for End endpoint for both Next and Replace flavors.

Comparing the Next and Replace pseudocode below side by side for the
critical copy function of what bits get copied from SRH Argument to DA.

Replace has 1 extra step s32 which helps clearly spell out the difference
between the two flavors difference in replace copying from bottom of
container to top.

I was referencing uSID for Next and G-SID for Replace but there are some
slight differences so this updated pseudocode really helps.

NEXT-C-SID

S.31    Initialize local parameter BitLength to
(CountTrailingZeros(ActiveSegment) +

                                                  AL -
CountTrailingZeros(Argument))

S.32    Initialize local parameter BitIndex to (128 – BitLength)

S.33    Set S[B..B+BitLength-1] to the value of

         ActiveSegment[BitIndex..(BitIndex+BitLength-1)]

S.34  }



S.35  Set IPv6.DA to the value of S

REPLACE-C-SID

S.29  Initialize local parameter BitIndex to (Argument * NF)



S.30  Set S[B..B+BitLength-1] to the value of

       ActiveSegment[BitIndex..(BitIndex+BitLength-1)]

S.32  Set S[B+BitLength..B+BitLength+A-1] to the value of Argument



S.33  Set IPv6.DA to the value of S

Kind Regards

Gyan

On Thu, Oct 14, 2021 at 8:54 AM Darren Dukes (ddukes) <ddukes=
40cisco.com@dmarc.ietf.org> wrote:

> The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar.
>
> In both cases the SID in the IPv6 Destination Address (DA) contains an
> argument,
>
> that argument is used to construct the next SID from the active segment in
>
> the SRH Segment List.
>
>
>
> I believe the following pseudocode is a much better description of their
>
> segment endpoint processing. You’ll notice there is no manipulation of
>
> the bits in the IPv6 DA.
>
>
>
> I propose we replace the pseudocode in the draft with the following,
>
> stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors
>
> of the END behavior (sections 4.1.1 and 4.2.1 respectively).
>
>
>
> Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID
>
> flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and
>
> NEXT-AND-REPLACE-C-SID flavor.
>
>
>
> Comments are appreciated.
>
>
>
> Thanks
>
>   Darren
>
>
>
> *4.1.1.  End with NEXT-C-SID*
>
>
>
> When processing an IPv6 packet that matches a FIB entry locally
>
> instantiated as an End SID with the NEXT-C-SID flavor, the SRH
>
> processing described in Section 4.1 of [RFC8986] is replaced as
>
> follows.
>
>
>
>
>
> S.01 When an SRH is processed {
>
> S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
>
> S.03     Stop processing the SRH, and proceed to process the next
>
>          header in the packet, whose type is identified by
>
>          the Next Header field in the routing header.
>
> S.04  }
>
>
>
> S.05  If (IPv6.HopLimit <= 1) {
>
> S.06     Send an ICMP Time Exceeded message to the Source Address
>
>          with Code 0 (Hop limit exceeded in transit),
>
>          interrupt packet processing, and discard the packet.
>
> S.07  }
>
>
>
> S.08  # Determine the maximum SRH Last Entry
>
> S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)
>
>
>
> S.10  Initialize 128-bit buffer memory S to 0.
>
> S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument
>
>
>
> S.12  If (Argument == 0) {
>
> S.13    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft >
> SRH.LastEntry+1)) {
>
> S.14      Send an ICMP Parameter Problem to the Source Address
>
>            with Code 0 (Erroneous header field encountered)
>
>            and Pointer set to the Segments Left field,
>
>            interrupt packet processing, and discard the packet.
>
> S.15    }
>
>
>
> S.16    Decrement SRH.SegmentsLeft by 1
>
>
>
> S.17    Set S to the value of SRH.SegmentList[SRH.SegmentsLeft]
>
> S.18  }
>
> S.19  Else {
>
> S.20    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft >
> SRH.LastEntry+1)) {
>
> S.21      Send an ICMP Parameter Problem to the Source Address
>
>           with Code 0 (Erroneous header field encountered)
>
>            and Pointer set to the Segments Left field,
>
>            interrupt packet processing, and discard the packet.
>
> S.22    }
>
>
>
> S.23    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common
> locator block)
>
>
>
> S.24    If (SRH.SegmentsLeft > SRH.LastEntry) {
>
> S.25      Initialize local parameter ActiveSegment to the value of DA
>
> S.26    }
>
> S.27    Else {
>
> S.28      Initialize local parameter ActiveSegment to the value
>
> S.29       of SRH.SegmentList[SRH.SegmentsLeft]
>
> S.30    }
>
>
>
> S.31    Initialize local parameter BitLength to
> (CountTrailingZeros(ActiveSegment) +
>
>                                                   AL -
> CountTrailingZeros(Argument))
>
> S.32    Initialize local parameter BitIndex to (128 – BitLength)
>
>
>
> S.33    Set S[B..B+BitLength-1] to the value of
>
>          ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
>
> S.34  }
>
>
>
> S.35  Set IPv6.DA to the value of S
>
>
>
> S.36  Decrement IPv6.HopLimit by 1
>
>
>
> S.37  Submit the packet to the egress IPv6 FIB lookup for transmission
>
>        to the new destination.
>
> S.38 }
>
>
>
> *4.1.1.1 Upper layer header processing*
>
>
>
> The upper-layer header processing described in Section 4.1.1 of
>
> [RFC8986] is replaced as follows.
>
>
>
> S.01  Initialize local parameter Argument to the value of IPv6.DA.Argument
>
> S.02  If (Argument != 0) {
>
>         # In this case, the SRH was not added by source
>
>         # The source compressed it into the active segment in IPv6.DA
>
>         # Build a pseudo header from the active segment in the IPv6.DA for
> use
>
>       # during processing.
>
> S.03    Initialize a 24-byte local SRH in memory to 0’s for use below
>
> S.04    Set SRH.MaxHdrLen to 3
>
> S.05    Set SRH.RoutingType to 4
>
> S.06    Set SRH.SegmentsLeft to 0
>
> S.07    Set SRH.SegmentList[0] to the value of IPv6.DA
>
>
>
> S.08    Process the SRH as per section 4.1.1,
>
> S.09     noting such processing is limited to the pseudo SRH
>
> S.10     since Argument is not 0.
>
> S.11  }
>
>
>
> S.12  If (Upper-Layer header type is allowed by local configuration) {
>
> S.13    Proceed to process the Upper-Layer header
>
> S.14  } Else {
>
> S.15    Send an ICMP Parameter Problem to the Source Address
>
>          with Code 4 (SR Upper-layer Header Error)
>
>          and Pointer set to the offset of the Upper-Layer header,
>
>          interrupt packet processing, and discard the packet.
>
> S.16  }
>
>
>
>
>
>
>
> *4.2.1.  End with REPLACE-C-SID*
>
>
>
> When processing an IPv6 packet that matches a FIB entry locally
>
> instantiated as an End SID with the REPLACE-C-SID flavor, the SRH
>
> processing described in Section 4.1 of [RFC8986] is replaced as
>
> follows.
>
>
>
> S.01 When an SRH is processed {
>
> S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
>
> S.03    Stop processing the SRH, and proceed to process the next
>
>         header in the packet, whose type is identified by
>
>         the Next Header field in the routing header.
>
> S.04  }
>
>
>
> S.05  If (IPv6.HopLimit <= 1) {
>
> S.06    Send an ICMP Time Exceeded message to the Source Address
>
>         with Code 0 (Hop limit exceeded in transit),
>
>         interrupt packet processing, and discard the packet.
>
> S.07  }
>
>
>
> S.08  # Determine the maximum SRH Last Entry
>
> S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)
>
>
>
> S.10  Initialize 128-bit buffer memory S to 0.
>
> S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument
>
> S.12  Initialize local parameter ActiveSegment to
> SRH.SegmentList[SRH.SegmentsLeft]
>
>
>
> S.13  If (Argument == 0) {
>
> S.14    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft >
> SRH.LastEntry+1)) {
>
> S.15      Send an ICMP Parameter Problem to the Source Address
>
>           with Code 0 (Erroneous header field encountered)
>
>           and Pointer set to the Segments Left field,
>
>           interrupt packet processing, and discard the packet.
>
> S.16    }
>
>
>
> S.17    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common
> locator block)
>
>
>
> S.18    Decrement SRH.SegmentsLeft by 1
>
>
>
> S.19    Set Argument to (128 / NF - 1)
>
> S.20  }
>
> S.21  Else {
>
> S.22    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry))
> {
>
> S.23      Send an ICMP Parameter Problem to the Source Address
>
>           with Code 0 (Erroneous header field encountered)
>
>           and Pointer set to the Segments Left field,
>
>           interrupt packet processing, and discard the packet.
>
> S.24    }
>
>
>
> S.25    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common
> locator block)
>
>
>
> S.26    Decrement Argument by 1
>
> S.27  }
>
>
>
> S.28  Initialize local parameter BitLength to the value of NF
>
>
> S.29  Initialize local parameter BitIndex to (Argument * NF)
>
>
>
> S.30  Set S[B..B+BitLength-1] to the value of
>
>        ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
>
> S.32  Set S[B+BitLength..B+BitLength+A-1] to the value of Argument
>
>
>
> S.33  Set IPv6.DA to the value of S
>
> S.34  Decrement IPv6.HopLimit by 1
>
>
>
> S.35  Submit the packet to the egress IPv6 FIB lookup for transmission
>
> S.36   to the new destination.
>
> S.37 }
>
>
>
> *4.2.1.1.  Upper layer header processing*
>
>
>
> The upper-layer header processing described in Section 4.1.1 of [RFC8986]
> is unchanged and reproduced below.
>
>
>
> S.01  If (Upper-Layer header type is allowed by local configuration) {
>
> S.02    Proceed to process the Upper-Layer header
>
> S.03  } Else {
>
> S.04    Send an ICMP Parameter Problem to the Source Address
>
>         with Code 4 (SR Upper-layer Header Error)
>
>         and Pointer set to the offset of the Upper-Layer header,
>
>         interrupt packet processing, and discard the packet.
>
> S.05  }
>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<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*