Re: What is necessity for SRH, and other EH, insertion/removal?

Tom Herbert <tom@herbertland.com> Sat, 07 December 2019 21:38 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A6D12082F for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 13:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 mK2SeltzKMOc for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 13:38:30 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 6994912004A for <ipv6@ietf.org>; Sat, 7 Dec 2019 13:38:29 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id dc19so9033877edb.10 for <ipv6@ietf.org>; Sat, 07 Dec 2019 13:38:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NMescJibEPRzwWcJkbrhrvOCZcM9cWcP9bVKGVEbVdk=; b=pdtZcCCbtp+nDqtvKAlyE0kvqlPR/RTXEQyBoO6PF9aPLPPcG5T1bbUPdzubcVLNqu +JlEEPlv7bijlKzgJ/IVarGIZmoPy1sHRRI0IuifkWUuUqE9xgZlvpXth1YpXWn5kUwO VfctzwnFmbefb4B18TYKIKO2PiZSRggKn6LjvN6ZDKK0pw0aWNNpfhPa3KDXTMxmNlr7 HfyW47kBU2QTWfDs3Ya6fyoO7KXP6Q3y4fOQZ8+LTecogINShC4gf0K+k4QCobD4Wsdd 13VgxWzxFpmR4tdEajmiRTlXuI0eZWa7w2ro5EIol6NulwtmhUrUovq8AVSfKfWC6bAv aZGw==
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=NMescJibEPRzwWcJkbrhrvOCZcM9cWcP9bVKGVEbVdk=; b=U8DCZYPzgTOCgrtOzhbZk/VQKSqnGlTXGVIrF2BMkfn0hFlVMdsrr7aaPFNs3tuYPC mVQTV3zQlPGi37YLWImHErzV39i/jHD2UWWtqrAoPtpevfbTKZez2LWXF5mE409Sv7ub B5nIAmqz2xPa/V8T/Garw2aqGhRpSESV0or1tjHOfVzt2604WzcNQGQDwJj8CdaBQjdZ r+sdtTUaNuC8r0DQGDrGS6Dmr/c1keL3Lh66CkJPLlTfw4pb788LxLtFsB3QPkvFrl/b OktRPsnUPcREFpJVV7Gz5YIKdopNBTJGfheZ3NTDDLc5YMia/9UCP1j9dlhSE6uyMVTU K9wg==
X-Gm-Message-State: APjAAAWWrYfeSFe51amd5dKXw8SJagBDu+lv3XGL31SN53zR87PpXv7f 2UrUOumNm2riXR0TJm6YiOWCl3XGw+vfwHVUlqKlnw==
X-Google-Smtp-Source: APXvYqyVMfMJOWW58aVp/K24eXhzW/IM1pGQQPCWEkGA62NBo4t4W76fW48tTTS917wI0+kd1zj4OTJKhEDhrgWPiuo=
X-Received: by 2002:a17:906:a444:: with SMTP id cb4mr23443531ejb.42.1575754707803; Sat, 07 Dec 2019 13:38:27 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S34vG=L_5nw_FzxHBUy+7tbWH4dhOh8xodOfKf2oOdrarg@mail.gmail.com> <CABNhwV2bEi8TPOfMGhEfdq8+HNY1uhEdq30c9tUtJdOYFq539w@mail.gmail.com> <CABNhwV0e6+sddEzkeesLTum4C+0O+ouDDa7ENy3doB3c1B5pUw@mail.gmail.com> <CABNhwV0CP=wrakHw8Ps5Ge_VhKCXfO3rh9ufYA7PQh4K4b89oA@mail.gmail.com>
In-Reply-To: <CABNhwV0CP=wrakHw8Ps5Ge_VhKCXfO3rh9ufYA7PQh4K4b89oA@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 07 Dec 2019 13:38:14 -0800
Message-ID: <CALx6S366c3MEDw1GDwf5uqd2F_XGbQNgCUUgVBtGzBeXvCueAg@mail.gmail.com>
Subject: Re: What is necessity for SRH, and other EH, insertion/removal?
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009cb7be059923fba2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kHOuNujB7XHnwq-1isCPmtzceh0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2019 21:38:34 -0000

Gyan,

Traffic engineering is not a new concept, and tunneling across a transit
domain has long been an effective method. So the question remains: why
can't that be used in segment routing use case?

So far, no one has said why it won't work. I'm really hoping someone will
stand up and clearly articulate why that or any other alternative doesn't
work such EH insertion is necessary. At that point, we might be able have a
productive discussion about how to move forward.

Tom


On Sat, Dec 7, 2019, 1:15 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
>
> Because SRv6 is touted to be the Swiss Army knife so to speak for any use
> case requiring traffic engineering that’s where it gets much more
> complicated with EH insertion and violation of RFC 8200.
>
> Cheers,
>
> Gyan
>
> On Sat, Dec 7, 2019 at 4:00 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>> Not to confuse the subject but this is an email  I had sent to
>> Spring/6man/BESS WGs related to comment on inter AS considerations “inter
>> domain” and that we should be able to apply the same Inter-AS L3 vpn
>>  features since its truly a bgp service construct overlay on top of the
>> SRv6 domain.
>>
>> To that end with TEAS WG as well we with traffic engineering IP TE we are
>> looking at taking the RSVP
>> feature and benefits and applying then to SRv6 as well as SR-MPLS to both
>> SR-TR and Ti-LFA.
>>
>> That is reason I think why the concepts of PSP was being applied to the
>> SRv6 specification.
>>
>> Post below:
>>
>> Here are some details related to existing Inter domain MPLS which has
>> come a long ways since inception decades ago.
>>
>> Inter AS options A, B, C & CSC
>> https://tools.ietf.org/html/rfc4364#section-10
>>
>> Inter AS option AB
>> https://datatracker.ietf.org/doc/draft-mapathak-interas-ab/
>>
>> Inter AS Option A:  Back to back VRF native IP.  Subinterface VRF per
>> customer VPN. LSP terminates on each ASBR PE router.  No BGP-LU (labeled
>> switched unicast) which requires importing of loopback FEC of all PEs
>> between each AS.  Simple and works if isolation is required between
>> providers.  Does not scale. Multicast Is simple as MVPN profiles do not
>> need to match as PIM over the NNI inter AS link glues the two MVPN domains
>> together.
>>
>> Inter AS Option B: Segmented LSP with single VPNV4 BGP session over inter
>> AS link.  Highly scalable.  RT filtering is enabled by default on all PEs
>> so has to be disabled on ASBR PE. Retain RT policy applied can filter and
>> RTs and don’t have to accept all RTs. Multicast MVPN profiles must match
>> between SPs as recursive-FEC and this the LMDT(labeled multicast
>> distribution tree) is end to end and not a segmented LSP as is with
>> unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for
>> LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  No
>> BGP-LU (labeled switched unicast) which requires importing of loopback FEC
>> of all PEs between each AS.
>>
>> Inter AS Option C: End to End LSP with BGP-LU (label switched unicast)
>> enabled on inter AS link data plane path.  All SP PE loopback FEC
>> destinations  must be exchanged imported between SPs and iBGP-LU PE to RR
>> for SP loops exchanged to have label binding when advertised over eBGP LU
>> inter AS. VPNV4 peering next-hop-unchanged for control plane update so end
>> to end LSP can build between any to any PE between SPs. Multicast MVPN
>> profiles must match between SPs as recursive-FEC and this the LMDT(labeled
>> multicast distribution tree) is end to end and not a segmented LSP as is
>> with unicast.  Option C offloads the ASBR PE having to maintain the L3 VPN
>> FIB.
>>
>> Inter AS Option AB Hybrid of Option A and B with single control plane
>> VPNV4 peer as is with Option B and VRF data plane isolation sub interfaces
>> per customer VRF.  Scales well as control plane is provided via single BGP
>> peer. AB provides additional security with VRF isolation feature.  No
>> importing of PE FEC loopback as this is a segmented LSP with 3 segments. Multicast
>> MVPN profiles must match between SPs as recursive-FEC and this the
>> LMDT(labeled multicast distribution tree) is end to end and not a segmented
>> LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer
>> to come up for LDP router-id label binding.ASBR PE must maintain all the L3
>> VPN FIBs.
>>
>> Of the 4 inter AS options available today with MPLS Option A very simple
>> and seamless and works well if you have a minimal number of VRFs.  Option B
>> and AB both are highly scalable and AB works well if security is a
>> concern.  Option C is a good option for enterprises as well as service
>> providers that have a close trust relationship.
>>
>> In your introduction section can you provide some details I have
>> mentioned of the existing MPLS inter domain options.  As you mentioned the
>> importing of millions of prefixes that would only be with Option C and it
>> would only be a million if each provider had a million PE loopback to
>> import.
>>
>> As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide
>> BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to
>> use the traditional mpls inter as options.
>>
>> As for SRv6 since it uses the IPv6 data plane as far as inter domain that
>> can be stitched with SRv6 using Option B style but IPv6 dataplane in place
>> of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4 VPNV6
>> would ride on top.  I guess you could do Option C style and advertise the
>> PE FEC loopbacks between domains for an end to end SID list similar to an
>> end to end LSP do the PSP PHP would not happen until you hit the last or
>> next to last node in the chain of domains.
>>
>> My guess is with both SRv6 and SR-MPLS you could literally take all for
>> inter AS options and use them as the bottom service BGP label would be the
>> same it’s just that you are swapping out the MPLS topmost label MPLS IPv4
>> data plane with SRv6 IPv6 data plane.
>>
>> Thank you
>>
>> Gyan
>>
>>
>>
>>
>>
>> On Sat, Dec 7, 2019 at 3:40 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>
>>>
>>>
>>> Tom
>>>
>>> Since we are drawing similarities between MPLS and SR both have the
>>> domain concept.
>>>
>>> The big difference between SR and MPLS is that each MPLS router
>>> maintains state in the P and PE nodes where with SR each PE or P along the
>>> source routed path does not maintain state.
>>>
>>> That is where with SR the source routing function on the ingress PE node
>>> of the SR domain created the source routed SR label stacking path with
>>> SR-MPLS topmost label.  In IPv6 forwarding plane case with SRv6 is
>>> accomplished with the SRH routing header type 4 which has the Segment list.
>>> So with SRv6 the one hop prior to egress node of the SRv6 domain being the
>>> PSP node end “egress P”in MPLS terms and the last  hop node in the USP
>>> scenario is the “egress PE” last node in the SRv6 domain.
>>>
>>> PHP in MPLS came about historically as with older MPLS routers instead
>>> of putting the burden on the last node to pop all labels “ultimate” hopping
>>> with explicit null the default behavior has always been for all vendors to
>>> do the PHP function.
>>>
>>>
>>> There are use cases primarily for QOS and maintaining EXP scheduling in
>>> the last hop from PE to P the concept of “pipe node” came about which is
>>> the explicit null option which allows the topmost label to be maintained on
>>> the last hop to the egress PE.
>>>
>>> I agree that that with SRv6 we are dealing with the IPv6 data plane and
>>> not MPLS data plane so its truly like apple and oranges.
>>>
>>> However from a functional scenario in reality SPs can now deploy SRv6
>>> core replacement of the legacy MPLS LDP label switching.
>>>
>>> From an SP core L3 VPN perspective the BGP AFI vpnv4 vpnv6 ipv4 IPv6 all
>>> AFI/SAFI can now sit right on top of this new IPv6 data plane model with
>>> SRv6.
>>>
>>> I believe from the BESS working group it has been mentioned that China
>>> SPs has 7+ deployments of SRV6.
>>>
>>> So as you enter a domain you perform MPLS imposition or now SRH eh
>>>  insertion and when you exit the domain you do PHP/UHP for MPLS or PSP/USP
>>> for SRv6.
>>>
>>> Hope this helps clarify in bridging the gap between WGs 6man, Spring,
>>> BESS, LSR, RTG, MPLS.
>>>
>>> Cheers,
>>>
>>> Gyan
>>>
>>> On Sat, Dec 7, 2019 at 12:17 PM Tom Herbert <tom@herbertland.com> wrote:
>>>
>>>> Pulling this out into a separate thread. Pertinent questions are:
>>>>
>>>> Why is extension header insertion and removal at necessary?
>>>>
>>>> Why isn't the proposed alternative of IPIP encapsulation sufficient?
>>>> (where the encapsulating headers contain the extension headers that
>>>> would otherwise be inserted)
>>>>
>>>> Please note, I'm asking for the technical justification of the
>>>> protocol design, saying that it's necessary because it's already being
>>>> deployed isn't useful in this regard.
>>>>
>>>> Tom
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>> --
>>>
>>> Gyan S. Mishra
>>>
>>> IT Network Engineering & Technology
>>>
>>> Verizon Communications Inc. (VZ)
>>>
>>> 13101 Columbia Pike FDC1 3rd Floor
>>>
>>> Silver Spring, MD 20904
>>>
>>> United States
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mishra@verizon.com
>>>
>>> www.linkedin.com/in/networking-technologies-consultant
>>>
>>> --
>>
>> Gyan S. Mishra
>>
>> IT Network Engineering & Technology
>>
>> Verizon Communications Inc. (VZ)
>>
>> 13101 Columbia Pike FDC1 3rd Floor
>>
>> Silver Spring, MD 20904
>>
>> United States
>>
>> Phone: 301 502-1347
>>
>> Email: gyan.s.mishra@verizon.com
>>
>> www.linkedin.com/in/networking-technologies-consultant
>>
>> --
>
> Gyan S. Mishra
>
> IT Network Engineering & Technology
>
> Verizon Communications Inc. (VZ)
>
> 13101 Columbia Pike FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
> www.linkedin.com/in/networking-technologies-consultant
>
>