Re: [spring] Understanding the replication draft

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 01 July 2020 23:10 UTC

Return-Path: <jmh@joelhalpern.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 1831A3A0F43 for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 16:10:57 -0700 (PDT)
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 sYOcrYKQi5tW for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 16:10:55 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3673A0F33 for <spring@ietf.org>; Wed, 1 Jul 2020 16:10:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49xxmH1TJYz1p5mN; Wed, 1 Jul 2020 16:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1593645055; bh=3k8Ohlex2wSkjIoCUOfAc1pFZaAu/T7wmbDmIcBg8EM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aBBo+WTrVOtOwxZPG0Iu6mPRgzTz0jgI8aMO+DQPX8iu8vEF1/QriLC4G/Ud8Wu6n CPDdOtLtaTd9nlHH9wULB6UW3SJMYVXeXrQ833du4cW3t3Rx45TdTCCV8syN9OReuP qdPTOxbdcbtV0oSOdm/enNL8TE/a1XCh6oK0kTlg=
X-Quarantine-ID: <xyO8KSdB7diI>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49xxmG1bjqz1p5kV; Wed, 1 Jul 2020 16:10:54 -0700 (PDT)
To: Rishabh Parekh <rishabhp@gmail.com>, Robert Raszuk <robert@raszuk.net>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "spring@ietf.org" <spring@ietf.org>, Joel Halpern Direct <jmh.direct@joelhalpern.com>
References: <94415742-fc4e-1774-bf96-01eac3672bfb@joelhalpern.com> <CABjMoXYCsXb-iP55PsNWHBG187Lm7-2PXfgD3qRn_aD6ppDuMw@mail.gmail.com> <b3aaaa47-af61-6fc0-1086-bfd59efea061@joelhalpern.com> <CABjMoXY5S1Bx3rQM-0eyJfzh9iOgAZoGshs1wFqebnkVZ++G0w@mail.gmail.com> <CAOj+MMFsjRCgbY1V5idoKmqKR7W5gwM7ui7cp6W12GQm0XEHyQ@mail.gmail.com> <AM0PR03MB4499F08DA8589EAEA4A048C29D6C0@AM0PR03MB4499.eurprd03.prod.outlook.com> <CAOj+MMFYcvAUP_Nh_K=6gBMVAQst_+mc0rADn7_j-yO4kyVC2Q@mail.gmail.com> <CABjMoXb2=dO+NgGLSCO8jaOvzroo5gTsBejNPvjPqYHvZKJcDA@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0065c14a-9e1a-ec0f-f1eb-614fd6d6a644@joelhalpern.com>
Date: Wed, 1 Jul 2020 19:10:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CABjMoXb2=dO+NgGLSCO8jaOvzroo5gTsBejNPvjPqYHvZKJcDA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/-5gzcw1YhTEEKZETCcNq0eHmc9A>
Subject: Re: [spring] Understanding the replication draft
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: Wed, 01 Jul 2020 23:10:57 -0000

What I think this draft could use is a description of what the legal and 
illegal ways of constructing the tools are, so that other drafts can 
then properly use the tools.

Yours,
Joel

On 7/1/2020 6:55 PM, Rishabh Parekh wrote:
> Sasha,
> I agree with Robert. Building MDTs for services is covered in a
> separate draft in BESS:
> https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-evpn-sr-p2mp/
> 
> -Rishabh
> 
> On Wed, Jul 1, 2020 at 2:56 PM Robert Raszuk <robert@raszuk.net> wrote:
>>
>> Hi Alexander,
>>
>> Do we really know how to build MDTs as source routed chains ?
>>
>> If that is the goal here IMHO it deserves a whole separate document ....
>>
>> In general when we replicate we take a packet and copy it to interfaces A, B ... Z. That's a local rule I presume executed for flows containing R-SID-n. But we just can't send the packet with identical list of SIDs from that point on any outgoing interface as results will be rather poor.
>>
>> We need custom list for each outbound interface and that is something I am not seeing in the draft. Till this is explained I would keep thinking that building MDTs should be more of as control plane task.
>>
>> Thx.
>> R.
>>
>> On Wed, Jul 1, 2020 at 9:42 PM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> wrote:
>>>
>>> Robert, Rishabh and all,
>>> I concur with Robert but would like to add that Option A woild effectively eliminate the possibility of building MDTs with more than one level using Replication Segments.
>>>
>>> Which is probably not the intent of the draft.
>>>
>>> My 2c.
>>>
>>> Get Outlook for Android
>>>
>>> ________________________________
>>> From: spring <spring-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
>>> Sent: Wednesday, July 1, 2020, 22:27
>>> To: Rishabh Parekh
>>> Cc: Joel Halpern Direct; spring@ietf.org
>>> Subject: Re: [spring] Understanding the replication draft
>>>
>>> Hi Rishabh,
>>>
>>>   > Of course, care must be
>>>> taken to avoid the "explosion" as you describe it. G-SID-2 has to map
>>>> to a unique node; for example, it may be an Anycast-SID that takes
>>>> packet to distinct nodes from each of the downstream node, or the
>>>> downstream nodes can be border nodes connecting to other segment
>>>> routing domains where G-SID-2 resolves to distinct nodes in each
>>>> domain.
>>>
>>> I think you are stretching it too thin.
>>>
>>> See even if G-SID-2 is anycast SID you have zero assurance that physical nodes packets will land on would be at all diverse.
>>>
>>> Likewise crossing domains yet providing identical global SID now to be a different node in each such domain to me is not a realistic example.
>>>
>>> I think we have two options:
>>>
>>> A) Firmly state that replication SID MUST be the last one on the stack
>>>
>>> B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.
>>>
>>> What is currently in the draft seems to be very counterintuitive and IMHO will result in operational difficulties.
>>>
>>> Thx a lot,
>>> R.
>>>
>>>
>>>
>>> ________________________________
>>> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
>>> ________________________________
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>