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

Robert Raszuk <robert@raszuk.net> Tue, 03 March 2020 21: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 CCC873A0A8B for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 13:50:59 -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, 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 Qolid4ses0Ib for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 13:50:57 -0800 (PST)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 939CF3A0A86 for <spring@ietf.org>; Tue, 3 Mar 2020 13:50:57 -0800 (PST)
Received: by mail-ot1-x32f.google.com with SMTP id x97so4651170ota.6 for <spring@ietf.org>; Tue, 03 Mar 2020 13:50:57 -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=DgnJm9zMzGMNQrSv/VHIF6eIidjdys9TIZO++onWYgQ=; b=SnBImu0VtpZXOf1GnhKWtqjgaR5WIhAqDdt/DNf2dD4JppQPNkskOmbKOqhr4wEviZ d5YS3M2EAM1G5rsqq+09Hy6py3/fWkzMFQO7jskSkNtD0sfhVmMhYWQS9iOzCay1Wnmi Yhc3fXfBczkNsBB6Pz1jLLnM/J1HyDnqMPLFgVHLrjyGYUhxtWsrERrbTPLx1huppy9K eyFeHqTuL09nj7dXFHQ7ddSjze8whlWGvPPjLhdMvGwBLe39QwOLC/L1jqyuLPv0T7J4 RJy82QlHAFb3U9fdPW78TRcJcdOj2WeoGwnYMbKSKLlvmfh8HMaJpGp3dD0nCk1G+vgd 9upA==
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=DgnJm9zMzGMNQrSv/VHIF6eIidjdys9TIZO++onWYgQ=; b=Cci9bv+P0fFm6fClf6yuaj9Cn2RRbG8TlFLobgIb2+BkH205KR5ySeV+wPrW6njBYv zJPJ54u2FN4sR3wGrkwXWlnO1ypczlot0pwoWzC+1Rbx7QXSMawbEZ/k3QEjAoy7l3dH kOhjtSVeLckVGVUxXUBbXlvnVT0QC3oAuwVFDHTg1zmu9MrbjnIoJyCvgyJo43ARvmQe WdUoyGqehM7RflBTnewOyYs9Ojvj5gaWynK6vbEri9I2eN1Pu4qdf+Ls0JxNoWWSmwSK ulkzcyYAdJH4JrDzTL8H2HJMquL2QaUPU4Ekok8UEF4JjK2W6Bjil/LiFuF2C2yFOZPA 3QMQ==
X-Gm-Message-State: ANhLgQ1ri+Kx75ci1dDqoSjXNLtQpWMko/MdFASaH7TKHie02a2zia1l F9iNFtIe8aLS9t4cfU0aWECdjlyK7oV18Ord0AYXOQ==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuFSXx+bluQaK0EXh5AdaJc1M4MPkCKFuAe9PZR?= =?utf-8?q?iPrM8imX+BpPoUNI1kVBsFYcQjyUkUrla5eIyiK0TCbiQfc=3D?=
X-Received: by 2002:a05:6830:4a6:: with SMTP id l6mr1381715otd.61.1583272256765; Tue, 03 Mar 2020 13:50:56 -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>
In-Reply-To: <CAO42Z2xO5==pTG7XfNsMAWq9Zc0t17yVQbJ8Xzd0pNQt3M0atw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 3 Mar 2020 22:50:47 +0100
Message-ID: <CAOj+MMFHxbPrFvRG_AOKeO65cfoUaVQdPgpt+e_M1UxqVVE-YA@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="0000000000007292d0059ffa4c3c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/TRL8j1Iu1ZLbqbCukQ6MSU9LiMk>
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 21:51:00 -0000

MPLS is not link layer. 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 - 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 :)

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