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

Robert Raszuk <robert@raszuk.net> Tue, 03 March 2020 22:59 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 4E2E03A07D1 for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 14:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 WRWca0B_W114 for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 14:59:40 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 8AD8B3A07F2 for <spring@ietf.org>; Tue, 3 Mar 2020 14:59:40 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id q65so123106oif.4 for <spring@ietf.org>; Tue, 03 Mar 2020 14:59:40 -0800 (PST)
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=ClsF5mnydwfUAdLyWsgaqrGk+761kchsMwjfzNvm40c=; b=LSYfjq9H7wfWg+WMslWHLtTf6QCSDv2gMh1uvGrtfauWDxNt4oZHKoi6LxcUoUqsXZ pEVQUiKghE7dlK+s7NNZBhIi6cP6V36UyGnpN7JqBdB8uSgmoSzXsNEzgq+PfejnrX3x XaZUmBBiUs77e7hVHWOS1e9EMy7NAqQ7qaG1ZT2aKaG8jYHreKx/iDhHu7BNja4vxV1M wUAQ4X+3cK5iXFuLmdeCRyPHR5d/OVdWynX98B/qdlOX/90OIVbDUbxFbJn3C1VeU5ng D5ZZsykgZ14Q0eqSfwMzZj3tHaHOiR4zpfhwhpN4c3gChkhUXvgWNejUMJvfE3Vj8aOn CnoA==
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=ClsF5mnydwfUAdLyWsgaqrGk+761kchsMwjfzNvm40c=; b=Kw1lO5Y3fDusSOWoHmkQP4kgQ/kBPkRDP8/9yNlg7Pa0p/8Zn7pwCivWBId2Nzzm5h bSuPrXyMq5G+HPiHzjoXQTgl8f6ePasqUlP+OIRq2m+2c1Roci+tiL0AGXLpBus6+gem 0WttcVAhw6k0b45H2jG6IG/D2BKuD4kgzS0s8Iyy2ncvKR6HJ8MMM1sdL1TGRuoSkl8C OD2txtTa2MKQY9TZHfayXiaqmfO7ns4hDPg/bUfcFGdvf7OMml4kUxr8opVUUjRMVQ5G gBsS2pKpwcVs7zuyIj5EBUXI6AYWTYkg/ZXSA0UmCOey5w9iZMIcPM07rMK2/6kqVu4G onig==
X-Gm-Message-State: ANhLgQ3W9V+3QhhR3mqmnxh2L33ESqAT0usEJlwQODo34r9lka84agbS Juo4l91PGIwdrI7NM16UmY27kEjhF4BglGEP1IiByA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtB6rWeOYz5k13KIdyIBaG5n3IxHLgu0FLcdqx2?= =?utf-8?q?9tusM29v3SIiPXgtd2AEfLMV716jrpHjrDVV8sHjGFEq7R8=3D?=
X-Received: by 2002:aca:4a11:: with SMTP id x17mr591412oia.146.1583276379836; Tue, 03 Mar 2020 14:59:39 -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>
In-Reply-To: <CAO42Z2yo__BFUq0Rxnsa5H6aNOzJF6dpUCPZ4WiZRfh-jeZNBw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 3 Mar 2020 23:59:31 +0100
Message-ID: <CAOj+MMF=a7hz9NNx_tMY=Z4rvwcDi4GpT2Dxv9-rj=EdGU3OGQ@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
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="00000000000033a5f2059ffb42f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/zs2rbqucNnL6miR9T6p4rLNaqIQ>
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: Tue, 03 Mar 2020 22:59:50 -0000

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