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

Mark Smith <markzzzsmith@gmail.com> Tue, 03 March 2020 21:42 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 28D993A0A73 for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 13:42:15 -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 5GR9PubtVMzT for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 13:42:13 -0800 (PST)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 635C13A0A6B for <spring@ietf.org>; Tue, 3 Mar 2020 13:42:13 -0800 (PST)
Received: by mail-ot1-x336.google.com with SMTP id f21so4597632otp.12 for <spring@ietf.org>; Tue, 03 Mar 2020 13:42:13 -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=VB/EZfp7yakmi5XQqvsndPpM9EgDImIJ9NK3BGBDYlI=; b=P2N5DcJ6x4bGh2zXrUUBOjyEJGHbl/2WZfBUfUAFbueIEp46RCsqTJM3NtFvQjWNI7 vKjZ8DstDfWHqLZJDHGwioNKL/Sf2av2mlOTONqZBTXjmbmncuwJm+hf1L+mPt6TSV/A qv2W7CpcBABh6iadeoh5PHmvE4A1CLT6BQBpeFM58/yAoe8BYrxOXpl6qik6iZIlASOM pPbxqfYMp1NJ981DD99TJ+LEuuMyiGLu66wrIJb6TcZw9J41su1DyYA2lsCgr9jjQIL8 HQAZ+Ga1ywBgv0//HhJzWgUFdoOdJXCYYlMF7MB/2Yai7rXrYKqnqsue3pK56nLXDFT1 Ot8w==
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=VB/EZfp7yakmi5XQqvsndPpM9EgDImIJ9NK3BGBDYlI=; b=h4vD+hqKOQH5LgCL5pX9HPN25F4aFpNdfUqb1VhlFXU4efi8ulz2w4KkT6AvMq5NQI L9hQb4uuyOAQ6soJlkgU66K8fKaAQvVgQI2SJyyxZOCVb9ppmgQbHo0/3D3Ufeii6MMD Bp3WQL5HhzMIt23t66GtXRt1lQRRmGD84RWRdIXjEMQYQyQkGUGCPrR0P4UyPqQuGRph NkosB0q/Qbj9fgwavY2laleIf+36rzb3D21RL+uhu7xAyK/4Wx1m1q8EJN5G7+RrVGcJ c+IvZocmrP0FwrpRRsprpGxUWETclylLcM32CVNidHDShSK8b/+3FgN9gzJ4BF7iylKr Yp2Q==
X-Gm-Message-State: ANhLgQ381KeDuIOUgJBw8rzmJ0zIFHhxGyD94vtueNrfhjWC0dFsSIni RDynEkGsi+9//pFXT9HmedL8lS/pgGrvzJJcBUw=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvV/99Ib8qJLX6nKLwMddVpuB6ch1fsIL8DYCgZ?= =?utf-8?q?6DdcYZNojDqNxnfnvdAMmA5uMk1ItTpBuzVDxlKh0SaGhPo=3D?=
X-Received: by 2002:a05:6830:15c6:: with SMTP id j6mr4595415otr.348.1583271732701; Tue, 03 Mar 2020 13:42: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>
In-Reply-To: <CAOj+MMGE+j7_QnFn-8ZQcU3BKLGEPaXj6hfppxG7-7iFkT3R1g@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 4 Mar 2020 08:42:01 +1100
Message-ID: <CAO42Z2xO5==pTG7XfNsMAWq9Zc0t17yVQbJ8Xzd0pNQt3M0atw@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="00000000000035ed20059ffa2df9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/UwC0WJ5yqVeEU3my59RA_hiEmNE>
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:42:16 -0000

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
>