Re: [spring] “SRV6+” complexity in forwarding

Robert Raszuk <robert@raszuk.net> Thu, 19 September 2019 19:50 UTC

Return-Path: <robert@raszuk.net>
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 CE734120152 for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 12:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 M6u2lEvcCVbr for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 12:50:18 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 8E1E5120129 for <spring@ietf.org>; Thu, 19 Sep 2019 12:50:18 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id 201so4651234qkd.13 for <spring@ietf.org>; Thu, 19 Sep 2019 12:50:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hMi6Ww1mA10wHlGOgzyN9GTzjw1+1UDXchfqie43Iz8=; b=DOaRnA2sO1wJIF0NbPdycrEicOlCUbVJQQh0RgZK+deb24iN12KPSCFiLM5hrO/jGF SSVamvXjjz2rW+o2mpdtRBbDBOzNvWmSg/W626jw85qM24vSdXTRZAHVDDqbhx7ia5Uv UzuREsNBxp0PWIB+Vwc9mQq24OOF3UXhWnzhQqDggMwbFzqKS+15L81Y9CFf02SShRc4 p48JlqAMEXQHXauH04VBZ1Z8AZQ3F3ufAsnGnD9U8DtfL9JUKirJdCXAicM5fleh6whH t3zyAkbv8JiOQnzIbi9WeEWGM7Q9Oo7MJHmFcz0dWUGbm/w/wskuzfAg6CY3AtSka262 aC+g==
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=hMi6Ww1mA10wHlGOgzyN9GTzjw1+1UDXchfqie43Iz8=; b=Q5lBg0GCpuf8oiXkHhvzHSJZUTxwWJjiLA0upaR7oW1HVRHfV7yfxWktRQeSrvymCx zz7o+kCXYchV2xza4+gbVCSiB19PaurguER+9yxUapBRAv/eKjsZMvmJeItAhz7Vh9bm yuVhIVzEs1jWuBezQ/U7IFJj/DMLho7bOEQEsDeUa7NVoah8WLwpHfDYRfMkwm9UyB5T LlTXLcR38SDGc/uE5YOYEOdwX+4UNO8xtw1T0V47LyZVdIUvINOxCcVHfZulOEXp3YUn 3l4xbBpIDXRb9zD2a8AAPsPXips+DobjO4s4DfZlx7sJ6gTfel32E36ESHRWQAiqNcEG XunQ==
X-Gm-Message-State: APjAAAXEgQnKPZCPR3G5lhORETX4CnqLM0S8gidIqo+jn42i8uJIVvKC LweMDAx6kPWwLFuGS4jmTsPjOEWWnXT4VkyYmy9cJA==
X-Google-Smtp-Source: APXvYqxzBGIMzRPX6JNOHQxkFfovgDWhiLAv542caRT5IsWSwrrwrJstdYychOW7UUmH/LiFqDhz2dT9dbE4RJ9qC6Q=
X-Received: by 2002:a37:8547:: with SMTP id h68mr4727432qkd.219.1568922617578; Thu, 19 Sep 2019 12:50:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54632F09C712ADB30138CFA9AEBE0@BYAPR05MB5463.namprd05.prod.outlook.com> <BYAPR19MB3415D21403394F8129A4BAD8FCB90@BYAPR19MB3415.namprd19.prod.outlook.com> <30491F13-C652-45C3-AB2B-95F765FBB4EA@juniper.net> <65C5CB04-3A2F-4F83-A7C8-2045154F93AE@cisco.com> <BYAPR05MB5463EC3250F2A303A3641839AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <91CBADAD-EFE6-46E1-A9D3-DAA111357179@juniper.net> <CAOj+MMGyUFRPDqCBo5SbLX486o_9GLpM6Zxf8KSt1voWiqhkGQ@mail.gmail.com> <E8D473B5-3E8D-4339-9A79-0CAE30750A55@juniper.net> <CAOj+MMFOy5PyTo=jPJkVrQOctdWjsTbD=7ix-2n89vodKzT3gQ@mail.gmail.com> <2F604D74-51CF-4F2F-AEA9-1CBDEEA9B9F7@gmail.com> <F09C2D09-D769-4817-AF73-97D6ED1BC4BF@lapishills.com> <201909120857387140042@chinatelecom.cn> <1568259664564.62561@bell.ca> <CAO42Z2wQ_8GEE+=nAMFBj+ape9Vf7fARVoOwGdCiUxdffkyXgw@mail.gmail.com> <BYAPR05MB5463A04B05B4BD6AA294F7F0AEB00@BYAPR05MB5463.namprd05.prod.outlook.com> <6EA6F7C0-BEB2-4749-A6AB-62B1337213B2@cisco.com> <BYAPR05MB5463426F1668202EE5F183EFAE8F0@BYAPR05MB5463.namprd05.prod.outlook.com> <634900D2-FBCE-47CF-8907-C8B9CB3A4102@cisco.com> <CALx6S34=Tw-u4Hz-07-Rs-GjsungkqnD_fMoQnGc17u3VJhY1g@mail.gmail.com> <CAFqxzqYr7g2jzwJrhvjL_DXYZsDzbzqx01cy0zB1aBweDde1XQ@mail.gmail.com> <CAO42Z2yrjwRMykWxmEo5=18fMvuZdMtuyz5g1p=8oSzp_ro9Vw@mail.gmail.com> <52FDA21F-E860-45E2-846A-43B969DEDC87@juniper.net> <CAOj+MMFjCcQt7FLf9NjfEKruEYktU0iJEs8Q+qFG8Pjkt7jDaA@mail.gmail.com> <9EA2D501-4382-4071-A89C-8C593B66E2F1@juniper.net> <CA+b+ERmnw412sboPtMow6=WUFK_FW2iO+rQxOu4dQ0yV2cuukQ@mail.gmail.com> <CAA8Zg7G-Aa+mVWxax3EqJOs9V7T8Bu=mfvng8Om9bEw59D7Orw@mail.gmail.com> <CAOj+MMFuQqMcGdjLT0piyuyUNpgLka7Pn5suA+LRi+rzFeKwow@mail.gmail.com> <CAA8Zg7HtdoMtzqg6o04TjAnyg8NUaoijVi40NoUPeERcycGssA@mail.gmail.com>
In-Reply-To: <CAA8Zg7HtdoMtzqg6o04TjAnyg8NUaoijVi40NoUPeERcycGssA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 19 Sep 2019 21:50:08 +0200
Message-ID: <CAOj+MMF7X2nar9TkvWc2LunwdL2A6pfzpvROeZ3XfCGcv4zBZQ@mail.gmail.com>
To: Reji Thomas <rejithomas.d@gmail.com>
Cc: Robert Raszuk <rraszuk@gmail.com>, Rob Shakir <robjs@google.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, Dirk Steinberg <dirk@lapishills.com>, "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, Tarek Saad <tsaad.net@gmail.com>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004d1d9c0592ed4397"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/z8rin7cZZ4TCY4HYtNsZINtlJHw>
Subject: Re: [spring] “SRV6+” complexity in forwarding
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: Thu, 19 Sep 2019 19:50:22 -0000

Hi Reji,

Notice what it says: *" ... explicitly listed intermediate nodes ... "*

CRH which is used in SRv6+ does not explicitly list intermediate nodes so I
do not think the procedures in IPv6 spec apply as the way you interpret
them.

But I am i no way authoritative ... still learning IPv6 and this thread
become great education.

An real example where those procedure apply is documented in RFC6554 which
does put the addresses explicitly.

Many thx,
Robert.








On Thu, Sep 19, 2019 at 9:14 PM Reji Thomas <rejithomas.d@gmail.com> wrote:

> Hi Robert,
>
> >>I do not know what is the difference between IPv6 Destination Address in
> the fixed header and "final destination". Where do you carry "final
> destination" address ?
>
> See Section 4.4 in RFC 8200.  Hope its clear what's the final destination
> and the context in which it is used.
>
>       Segments Left       8-bit unsigned integer.  Number of route
>                           segments remaining, i.e., number of explicitly
>                           listed intermediate nodes still to be visited
>                           before reaching the final destination.
>
>
> Regards
>
> Reji
>
>
> On Thu, Sep 19, 2019 at 10:26 PM Robert Raszuk <robert@raszuk.net> wrote:
>
>> IPv6 fixed header has only one destination address. So TE midpoint is
>> either a packet's destination or not. It can not be both.
>>
>> I do not know what is the difference between IPv6 Destination Address in
>> the fixed header and "final destination". Where do you carry "final
>> destination" address ?
>>
>> Many  thx,
>> R.
>>
>> On Thu, Sep 19, 2019 at 6:17 PM Reji Thomas <rejithomas.d@gmail.com>
>> wrote:
>>
>>> Hi Robert,
>>>
>>>
>>> >>Well the crux of the matter is that you still need to process all EHs at each IPv6 destination which here means each transit node per RFC8200
>>>
>>>
>>>  From RFC 8200 that doesn't seem to be the case or at least as I understand. See  Section 4.1 note 1 and note 3. Am I missing something?
>>>
>>>
>>>
>>> IPv6 header
>>>       Hop-by-Hop Options header
>>>       Destination Options header (note 1)
>>>       Routing header
>>>       Fragment header
>>>       Authentication header (note 2)
>>>       Encapsulating Security Payload header (note 2)
>>>       Destination Options header (note 3)
>>>       Upper-Layer header
>>>
>>>       note 1: for options to be processed by the first destination that
>>>               appears in the IPv6 Destination Address field plus
>>>               subsequent destinations listed in the Routing header.
>>>
>>>       note 2: additional recommendations regarding the relative order of
>>>               the Authentication and Encapsulating Security Payload
>>>               headers are given in [RFC4303 <https://tools.ietf.org/html/rfc4303>].
>>>
>>>       note 3: for options to be processed only by the final destination
>>>               of the packet.
>>>
>>>
>>> Regards
>>> Reji
>>>
>>> On Thu, Sep 19, 2019 at 9:00 PM Robert Raszuk <rraszuk@gmail.com> wrote:
>>>
>>>>
>>>> I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture
>>>>> better. The SRv6+ drafts explain the usecases better FYI.
>>>>>
>>>>
>>>> Well the crux of the matter is that you still need to process all EHs
>>>> at each IPv6 destination which here means each transit node per RFC8200.
>>>> That is regardless what any other spec says ... unfortunately.
>>>>
>>>> Best,
>>>> R.
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>