Re: [bess] Questions to draft-dawra-bess-srv6-services-02
Gyan Mishra <hayabusagsm@gmail.com> Thu, 03 October 2019 23:03 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487D91200E0; Thu, 3 Oct 2019 16:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4bVgiHE9CAO3; Thu, 3 Oct 2019 16:03:34 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 6A3FA120059; Thu, 3 Oct 2019 16:03:34 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id w2so4113867qkf.2; Thu, 03 Oct 2019 16:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CojSJ12siTTbsrMBcP1CdfvmIKXLHx8pCjLwfyit6rw=; b=Yl/eIlcSDtcPVRGztuV2hLBoomnmn+Z6loSdfU4VVvaaVr8rOW0huK8jPWK1ch9O2D ORqUYiRby/NCMw5wKZfm8o3oM/mP8YAd33LGCEIKJhNQhu+ZP7HSpueE0qSeKasdMqU5 5RoDjGeU/8XNVFRgGPut9SK8SmS2RcDGxk8zC73nIJNJ3oDTsoq5lj5Z8u5zpABI5o6c yiuLhE7IJ/2aAhaeXGqDNCWMCCV7h8whKQGSsrt3agpmuCXBajXDwj0iCHUJ6jy9IEX0 Gp87UupbrwosV6VFAFKEcOEu8eKjg7Ax5QzWkQZRt0tthdroncTnfytr6ZQIvoimaF00 1j8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CojSJ12siTTbsrMBcP1CdfvmIKXLHx8pCjLwfyit6rw=; b=Gylv5BIGwZrqAZjiIY7Nu/YdpDzq1a5ns6Z+PqaxSqbLlmmn8MsNJlchudY/HcfzsX zIYOQvHlV9Q8dkFKpjJ4GLPEljaX1N5hvgh0q1Fp4LDG/31/377Gc7nbQSUTvN/pDvBV nqOyTXajo3P5WHgXcQMzJVWykQMt2woqi2UueSufqpCb7puB9jJeVcG/kk/P9bZGxQXm TkrNwk4m/RQs9bZHnSc0rGMh82kbTJiBPfgDSEyfXsVD161VOrQA5WmxmfIczMF+rWcf 6vo6ruVZJ8TVssSgeuPFLHtD8F78yhXCD5BEMSMmHKp3sQ36nWVkUw4707UYXIeZBgOk W8Jg==
X-Gm-Message-State: APjAAAWo5vbRFY5z+rrg3DMCQyDCoLvmZjVooLd4iRgd+ten+JYs+Uu9 EEHL1P7BfR+N0qkTPoV27puSjZwCxM4=
X-Google-Smtp-Source: APXvYqzOEPRZoEUj4mQCk9H37MnWv+eC5xnttboiS/0Y2/YTc+qijdB5qWIIOG0gmIND0KuVo81scQ==
X-Received: by 2002:a37:4ecb:: with SMTP id c194mr7020620qkb.126.1570143813154; Thu, 03 Oct 2019 16:03:33 -0700 (PDT)
Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id b192sm2053391qkg.39.2019.10.03.16.03.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 16:03:32 -0700 (PDT)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-65FFF380-5985-43FE-B492-0FBF9ABC2D6D"
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <CAOj+MMFDEYP8BHpJ-jhX4dgbvLa-OaROFo4SUMmKm6cp-tq2tw@mail.gmail.com>
Date: Thu, 03 Oct 2019 19:03:31 -0400
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, "bess@ietf.org" <bess@ietf.org>, "draft-dawra-bess-srv6-services@ietf.org" <draft-dawra-bess-srv6-services@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <889CD032-17F0-4E2C-9DD0-3C30DBA34E7F@gmail.com>
References: <CH2PR13MB3574E3933B00BA7CD0867495859F0@CH2PR13MB3574.namprd13.prod.outlook.com> <CAOj+MMFDEYP8BHpJ-jhX4dgbvLa-OaROFo4SUMmKm6cp-tq2tw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/SpoIKrVfC8xNslNEOYobJ2Qx6Ho>
Subject: Re: [bess] Questions to draft-dawra-bess-srv6-services-02
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 23:03:38 -0000
Hi Robert In-line question Sent from my iPhone > On Oct 3, 2019, at 11:01 AM, Robert Raszuk <robert@raszuk.net> wrote: > > Hi Linda, > > Nope. Nodes except egress have any reason to look at VPN label. That label has only local significance on egress. > > Thx, > R. Robert From an operator perspective ease of implementation and migration is critical to deployment. So just as with SR-MPLS where you can prefer SR over mpls and it’s a swap of the “topmost label” in the label stack and all VPN services label at the bottom of the stack remain unchanged. Drawing an analogy to SRv6 scenario that would it be exactly the same it sounds like that L3 VPN vpn label remains intact for vpnv4 vpnv6 scenario and IP native native IPv4 / IPv6 encapsulation IP/MPLS remains the same no change and it’s just the “topmost” label gets swapped out from either legacy mpls LDP/TE to either SR-MPLS or now SRv6 topmost label. The services bottom label are only imposed by ingress PE as with legacy mpls and per SRv6 End SID programming is either PSP or USP popped similar to legacy mpls PHP UHP and VPN label is then processed by the egress PE identical to how it’s done with SR-MPLS or legacy mpls. So from an operator perspective such as Verizon that does make it attractive and an easy swap out migration or new green field implementation to migrate to SRv6 as all the customer Edge PE-CE protocols and encapsulation VPN related services L3 VPN. MVPN EVPN PBB VPWS e-tree e-lan e-line does not change for any services bottom labels. Is that true and if so that is a major design concern for migration of customers to a SRv6 core. With SR-TE now we would have native TE capabilities with SRv6 over SR-MPLS so that we can individually color each per vpn flow to an SR-TE tunnel over SRv6 core. I am stating that correctly that is the major benefit of SRv6 over SR-MPLS. Gyan Verizon Communications Cell phone 301 502-1347 > >> On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar <linda.dunbar@futurewei.com> wrote: >> Robert, >> >> >> >> Thank you very much for the explanation. >> >> With the L3VPN case, there are nodes between Egress and Ingress PEs that do look into the VPN label carried by the packets for VRF & IP lookup, correct? >> >> I was just confused of the statement about “all nodes between Egress & Ingress PE are SR unaware plain IP forwarding nodes”. >> >> >> >> Thanks, >> >> >> >> Linda >> >> >> >> From: Robert Raszuk <robert@raszuk.net> >> Sent: Thursday, October 03, 2019 3:50 AM >> To: Linda Dunbar <linda.dunbar@futurewei.com> >> Cc: draft-dawra-bess-srv6-services@ietf.org; bess@ietf.org >> Subject: Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 >> >> >> >> Linda, >> >> >> >> SRv6 services is just a general term used here. Imagine one of such service is L3VPN. VPN label (or pointer to it) is needed to be carried somewhere in the packet as address space may be overlapping between VPN customers and simple IP lookup will not be sufficient to determine VRF or exit interface. >> >> >> >> One option which has been done and deployed is to encode it natively in the packet and on ingress simply apply prodecures of IPv4 or IPv6 encapsulation - RFC4797 and RFC7510 >> >> >> >> The other new option is to take the VPN label or VPN demux value and encode it in SRH or in DO. >> >> >> >> Now which option to choose is left for the operator to decide likely depending on a lot of other factors involved. >> >> >> >> Thx, >> >> R. >> >> >> >> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar <linda.dunbar@futurewei.com> wrote: >> >> I support WG adoption of the draft, with the following questions. Hope authors can help to explain: >> >> >> >> Section 1 Introduction states that the underlay between the Ingress and Egress only needs to support plain IPv6 >> >> Forwarding. Those plain IPv6 routers don't need to understand the SR policies encoded in the payload, correct? >> >> Why need Ingress PE to encapsulate the policy sent by egress PE if all the nodes between them are plain IPv6 routers? >> >> >> >> Which PE is to enforce the SR policy? >> >> If the policies are for the egress to enforce, why can't the egress PE simply enforce the policy instead of asking ingress node to encapsulate the policy in the packet header? Which has the drawback of extra header bits in packets. >> >> >> >> Linda Dunbar >> >> >> >> >> >> From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> >> Date: Friday, September 27, 2019 at 4:00 AM >> To: "draft-dawra-bess-srv6-services@ietf.org" <draft-dawra-bess-srv6-services@ietf.org>, "bess@ietf.org" <bess@ietf.org> >> Subject: WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 >> Resent-From: <alias-bounces@ietf.org> >> Resent-To: <gdawra.ietf@gmail.com>, <cfilsfil@cisco.com>, <pbrisset@cisco.com>, Swadesh Agrawal <swaagraw@cisco.com>, <daniel.voyer@bell.ca>, <daniel.bernier@bell.ca>, <dws@steinberg.net>, <robert@raszuk.net>, <bruno.decraene@orange.com>, <satoru.matsushima@g.softbank.co.jp>, <zhuangshunwan@huawei.com>, <jorge.rabadan@nokia.com> >> Resent-Date: Friday, September 27, 2019 at 4:00 AM >> >> >> >> Hello, >> >> >> >> This email begins a two-weeks WG adoption poll for draft-dawra-bess-srv6-services-02 [1] . >> >> >> >> Please review the draft and post any comments to the BESS working group list. >> >> >> >> We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> >> >> If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. >> >> Currently, there are no IPR disclosures against this document. >> >> >> >> If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. >> >> >> >> This poll for adoption closes on Friday 11th October 2019. >> >> >> >> Regards, >> >> Matthew and Stephane >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/ >> >> >> >> >> > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess
- [bess] Questions to draft-dawra-bess-srv6-service… Linda Dunbar
- Re: [bess] Questions to draft-dawra-bess-srv6-ser… Robert Raszuk
- Re: [bess] Questions to draft-dawra-bess-srv6-ser… Gyan Mishra
- Re: [bess] Questions to draft-dawra-bess-srv6-ser… Robert Raszuk
- Re: [bess] Questions to draft-dawra-bess-srv6-ser… Gyan Mishra
- Re: [bess] Questions to draft-dawra-bess-srv6-ser… Gyan Mishra