Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Mark Smith <markzzzsmith@gmail.com> Wed, 04 March 2020 00:10 UTC

Return-Path: <markzzzsmith@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 98B173A08E2 for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 16:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=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 POACfX1745K5 for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 16:10:19 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 8B7343A08E4 for <spring@ietf.org>; Tue, 3 Mar 2020 16:10:14 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id l12so248464oil.9 for <spring@ietf.org>; Tue, 03 Mar 2020 16:10:14 -0800 (PST)
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=o+Q0yALsSm7HgmH1buOrxHCH2nkI5FmoIsumFE+S07o=; b=fN7k2sHspmVFfpyHmZLYYhzRgJ6S926hmeUokGQrVMNUEWgBi1ES5Yofv9wCsAQNIN +hquD8eKkmN05hjrKZ8S9VnxKhvGiF6WOEydMlnXYpaJZBUJ/plUxMW3LCCu57oWwDxG LSMo1OnF2ecobTUQDU98bSgBDWbZ9KRBU2rRsBkksp0X6/UcLPPVG44B3uIPkO1vFG1q mKiuQkzbngTtjQpg3WAz6LKyZWhbTMod0U33+BtXvTgF4pWIaft2CP/rH1OvSkb7aROd M6WaqdTY5vlch1OdsCrUUJN74koJeCnO1KgldHeHUcJAz/PeudcDkCM7Np13PgK4la0/ N79w==
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=o+Q0yALsSm7HgmH1buOrxHCH2nkI5FmoIsumFE+S07o=; b=UEGKpkjVlADiRXaGeLP3sEF5TvSMquBIpDXc0tSu/BK4KL3rrS2tN+AFsNxd+nAkBk OpKSCT5v8N9capDsHW8xnIADlrRGZ9C1OabSXzu4GzuIBO745fVQ7OHU1BbGJgSIB1dx T3mCmTLiKJOCyVYmbIBIlUDefiCm2GfZKBmmipMW0js00AKgVXKOom7bFfKEJqkjJqKM /BZOrxHzYwu4NpaS+ytGZR7tMs3LDbwJmQGQpd/wOPv7SGNIyptr8VOxuIZXkVS5Jo6N 7PyTjeLnrIUXWV6ly0KJkg3aG1ayk9R+XIL2PpIbEvlRo1cXDKe93PYy8f5V3AtvU41q Gu3A==
X-Gm-Message-State: ANhLgQ2NA+muPHWr2Wp1xyHsII++2gQo1fsQWZFYWLJdY4cP5NJzJoyo gfvB4ZHTnaX1UTFvhDurozDQaQbbtLw9q0aI8PM=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvgEoTjnPB2x0YlKvWftOI12M6oYuy1Dqsq0u94?= =?utf-8?q?9jyqIoj+I61fKIk3Yb/52nef162EOZLiX8ntDqfpaH/lEQQ=3D?=
X-Received: by 2002:aca:4306:: with SMTP id q6mr50609oia.54.1583280612305; Tue, 03 Mar 2020 16:10:12 -0800 (PST)
MIME-Version: 1.0
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E?= <3e2da3a5-5d1b-10a0-aeb4-320c57584241@nokia.com> =?utf-8?q?=3C8259d37e-b460-5f76-1ce6-b0d026bccf6b=40gont=2Ecom=2Ear=3E_=3C2?= =?utf-8?q?0143=5F1583250558=5F5E5E7C7E=5F20143=5F390=5F3=5F53C29892C8575842?= =?utf-8?q?99CBF5D05346208A48DD80E6=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Einf?= =?utf-8?q?ra=2Eftgroup=3E?= =?utf-8?q?=3C5d693a5e-baa0-6ffb-4e39-2695795b7413=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3C7501=5F1583255845=5F5E5E9125=5F7501=5F499=5F1=5F53C29892C85758?= =?utf-8?q?4299CBF5D05346208A48DD84FF=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Ei?= =?utf-8?q?nfra=2Eftgroup=3E?= =?utf-8?q?=3Cfc5bf8d9-073f-2eff-6041-e1610bf6e116=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3CDM6PR05MB63484795948C4901C9B7A548AEE40=40DM6PR05MB6348=2Enampr?= =?utf-8?q?d05=2Eprod=2Eoutlook=2Ecom=3E?= <CAOj+MMGE+j7_QnFn-8ZQcU3BKLGEPaXj6hfppxG7-7iFkT3R1g@mail.gmail.com> <CAO42Z2xO5==pTG7XfNsMAWq9Zc0t17yVQbJ8Xzd0pNQt3M0atw@mail.gmail.com> <CAOj+MMFHxbPrFvRG_AOKeO65cfoUaVQdPgpt+e_M1UxqVVE-YA@mail.gmail.com> <CAO42Z2yo__BFUq0Rxnsa5H6aNOzJF6dpUCPZ4WiZRfh-jeZNBw@mail.gmail.com> <CAOj+MMF=a7hz9NNx_tMY=Z4rvwcDi4GpT2Dxv9-rj=EdGU3OGQ@mail.gmail.com>
In-Reply-To: <CAOj+MMF=a7hz9NNx_tMY=Z4rvwcDi4GpT2Dxv9-rj=EdGU3OGQ@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 4 Mar 2020 11:10:00 +1100
Message-ID: <CAO42Z2zq1yLRDp3ddJedPCMztS6VdxESb9r-aL7EQpz19eLs4A@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "bruno.decraene" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Martin Vigoureux <martin.vigoureux@nokia.com>
Content-Type: multipart/alternative; boundary="00000000000079ee6c059ffc3ee3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/y4j7iURZ-3QF0UjksM1AFj0WsDE>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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: Wed, 04 Mar 2020 00:10:26 -0000

On Wed, 4 Mar 2020, 09:59 Robert Raszuk, <robert@raszuk.net> wrote:

>
> You are right Mark ... I fully admit I have no clue what so ever about
> "IPv6 being a virtual MAC layer in SR" nor " IPv6 being used as a virtual
> link layer".
>

I didn't say you had no clue.

Saying things like "MPLS is not link layer." suggests you think I have no
clue, and that makes this conversation a waste of time.



> I was only talking about MPLS on which topic I think I still have a little
> bit of remaining knowledge.
>
> Thx a lot,
> Robert
>
>
> On Tue, Mar 3, 2020 at 11:43 PM Mark Smith <markzzzsmith@gmail.com> wrote:
>
>>
>>
>> On Wed, 4 Mar 2020, 08:50 Robert Raszuk, <robert@raszuk.net> wrote:
>>
>>>
>>> MPLS is not link layer.
>>>
>>
>> I did not say that. I described how MPLS uses link-layers.
>>
>>
>> It is Layer 2.5 if you really want to squeeze it to OSI.
>>>
>>
>>> Regardless of IPv4, IPv6 or MPLS MACs are replaced at each L3 hop
>>>
>>
>> IPv6 is your virtual MAC layer in SR. Then there is a MAC layer below
>> that IPv6 virtual MAC layer.
>>
>> You're not thinking about tunnels being virtual links and performing
>> link-layer operations on them in the context of the upper protocol - MPLS
>> or SR.
>>
>>
>> - but that has nothing to do with MPLS PHP. MPLS PHP is the result of LDP
>>> signalling implicit null label from adjacent LSR.
>>>
>>> And perhaps it may avoid unnecessary statements if you would read my
>>> entire note :)
>>>
>>
>> I did.
>>
>> You don't seem to fully understand the idea of IPv6 being used as a
>> virtual link layer, and then how an upper IPv6 layer should treat and
>> consider the lower IPv6 layers.
>>
>> Clue: the upper IPv6 layer should not be aware that there is an IPv6
>> "link layer" below it. There is another link layer below the virtual lower
>> IPv6 link layer, and that is another clue - there isn't always just one one
>> link layer instance - tunnelling introduces more link-layers, stacked on
>> top of each other, and that isn't limited to two - you can tunnel inside a
>> tunnel inside a tunnel. That gets confusing and complicated however once
>> you learn how to think within a layer, ignoring the others momentarily, it
>> then can be coped with.
>>
>> You need to read and consider this Internet Draft. I wish it had existed
>> 20 years ago.
>>
>> IP Tunnels in the Internet Architecture
>>
>>
>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10
>>
>> Regards,
>> Mark.
>>
>>
>>
>>> Best,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 3, 2020 at 10:42 PM Mark Smith <markzzzsmith@gmail.com>
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> On Wed, 4 Mar 2020, 07:11 Robert Raszuk, <robert@raszuk.net> wrote:
>>>>
>>>>> Hi Ron,
>>>>>
>>>>> >   MPLS PHP is a clear case of de-encapsulation.
>>>>>
>>>>> Purely looking at technical aspect that is not true at all.
>>>>>
>>>>
>>>> Ron is correct.
>>>>
>>>>
>>>>
>>>>> MPLS PHP does not remove label stack. MPLS PHP is just used to pop
>>>>> last label. After MPLS PHP packets continue with remaining label stack to
>>>>> the egress LSR (example L3VPN PE).
>>>>>
>>>>
>>>> When an MPLS packet is forwarded through an LSR, with any operation at
>>>> all performed on the label stack (including none), is the link layer header
>>>> (literally) preserved during that operation?
>>>>
>>>> If the ingress and egress LSR links are both Ethernet, does the LSR
>>>> ingress frame's SA and DA match the post LSR processing Ethernet frame's SA
>>>> and DA?
>>>>
>>>> If you believe they do, how can MPLS work going from an Ethernet link
>>>> on one side of an LSR to a PPP (or Frame Relay, etc.) on the other side?
>>>> Clearly an Ethernet frame can't travel over a PPP etc. link.
>>>>
>>>> At every MPLS LSR along the LSP the link layer frame is replaced, with
>>>> new SA and DA, even if the link layer encapsulation is the same.
>>>>
>>>> The label stack is carried from ingress to egress, possibility modified
>>>> by an operation such as pop. However the link layer encapsulation is never
>>>> carried "through" the LSR.
>>>>
>>>> PSP as described in SR NP is not the same as PHP in MPLS.
>>>>
>>>> Modelling this operation in RFC 8200 compliant IPv6, there would be
>>>> discrete and distinct IPv6 in IPv6 tunnels between each SR router in the SR
>>>> domain, and there would not be an Routing Headers in the outer tunnel IPv6
>>>> packet. The EH chain ("stack") would be carried been discrete ingress and
>>>> egress IPv6 in IPv6 tunnels, possibly modified, however the ingress tunnel
>>>> outer header would be replaced at each SR router.
>>>>
>>>> These distinct tunnels between SR routers wouldn't necessarily have to
>>>> be preconfigured. If the SR routers are directly link layer attached, then
>>>> the outer tunnel header IPv6 addressing could be the mandatory interface
>>>> Link Local addresses - which IGPs are already using to identify and track
>>>> neighbours.
>>>>
>>>> For SR, there would have to be an EH that carries the SIDs list,
>>>> however it would be a Destination Options EH, not a routing header. It
>>>> would be a Destination Option because it is processed at the destination
>>>> addesss of the outer tunnel header.
>>>>
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>>
>>>>
>>>>> >  I don't think that you can compare MPLS PHP with SRv6 PSP
>>>>>
>>>>> But I agree with that. Both operations have very little in common from
>>>>> packet's standpoint or forwarding apect. Well maybe except "penultimate"
>>>>> word :)
>>>>>
>>>>> Kind regards,
>>>>> R.
>>>>>
>>>>>
>>>>> On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica <rbonica=
>>>>> 40juniper.net@dmarc.ietf.org> wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP
>>>>>> is a clear case of de-encapsulation. We do that all the time. In SRv6 PSP,
>>>>>> we are removing something from the middle of a packet. That is quite a
>>>>>> different story.
>>>>>>
>>>>>>
>>>>>>                                                                 Ron
>>>>>>
>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> spring@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>
>>>>