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

Mark Smith <markzzzsmith@gmail.com> Tue, 03 March 2020 22:43 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 CEB2C3A040B for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 14:43:33 -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 Gbs9jPhrTmzV for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 14:43:32 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 34C563A0405 for <spring@ietf.org>; Tue, 3 Mar 2020 14:43:32 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id j5so61763otn.10 for <spring@ietf.org>; Tue, 03 Mar 2020 14:43:32 -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=J4FgTPhcBAOONvdr6LkE3kzDLRse2UOktDgGi+3hrAQ=; b=Gs3YYja2NXGK76ztXvn+B/Bst1Oa2Hf1i26rM7EOuVLoeSIWbdMNDFSfosxBvF1T43 CAVn397ipazt25Y5nkeSQBzW9v7OHoXAeCxkM9FHh3ymVEmxlQ25fajiAH8Si2LtKAng iQsEJ4J1aZSNx3OkaTCRKyQUBp02kSucbo0Fl3Y4ykQpQ9b7Erx1xUEoT0hCa0LhhA0f +PJWUKtqRDqJBMpT0i35OzW6PWnMCyplVCNpNqQ9LEV3gsDoyriVGOl9dRDQslpPZqhG Rd0g2QZA+5xl+2ELBxbPptK3shJbWOnagP0d4O+9IqVZc6zZ5grIbWGIsw4fq/9u80p5 8HNw==
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=J4FgTPhcBAOONvdr6LkE3kzDLRse2UOktDgGi+3hrAQ=; b=sdzDekikoWIMRlLy9YxDGC5Z3cPUJgfPS3p7vczmaoJ3ar6D8LoIvLGnmFZ2JRauLq dlDrR0OuMX7o2wLufe+2quKIT6vhg9QRgHFE3/oK8MvL4jpMUXNJ1/fjOzejquqzhMpg NU3E8V+3D4qaU5pbF0jMARqsCkg+lvTuiY1AIfTKUjYAyJx11sPGfSQriCEkhg72PEa8 cofi5igu2Ehrq1DSxhcYU4gqSu/EQoVgDvBQ2oFcWWz3l2oFxfFGQB+7mz8cibbkvXbR b1FmS941NqT11Bm+2twSPr9m0viwAVp4Ei+EBara+loTY/WGG5FcH3Gd0SwTLcc2HWCl 8R3Q==
X-Gm-Message-State: ANhLgQ30Z2dxbZamcTeD6r/MaCCClCUrXrJ+WdtrB8bcFXpo4kO+GeiC LncRJ8fAqnRi2DE92EqQa1bBeWsU399+4JE3LDE=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvaL9vxPUlaqeoqUE1RJGIY4s/u5CGhSMBToH9Q?= =?utf-8?q?xrFO5XDZR8W2JdBkSEg83dJ/yKBuytw0MISRGQaumgKJbew=3D?=
X-Received: by 2002:a9d:6204:: with SMTP id g4mr133479otj.94.1583275411466; Tue, 03 Mar 2020 14:43:31 -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>
In-Reply-To: <CAOj+MMFHxbPrFvRG_AOKeO65cfoUaVQdPgpt+e_M1UxqVVE-YA@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 4 Mar 2020 09:43:19 +1100
Message-ID: <CAO42Z2yo__BFUq0Rxnsa5H6aNOzJF6dpUCPZ4WiZRfh-jeZNBw@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="0000000000007b6c59059ffb0875"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/wvqtZalb8Ig69BRAjcCAM9JSFnM>
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:43:34 -0000

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