Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Greg Mirsky <gregimirsky@gmail.com> Sun, 17 November 2019 03:39 UTC

Return-Path: <gregimirsky@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 A8A3B12083A; Sat, 16 Nov 2019 19:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 LQU1xv3qlVM4; Sat, 16 Nov 2019 19:39:38 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 8AF21120046; Sat, 16 Nov 2019 19:39:37 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id v8so11020796lfa.12; Sat, 16 Nov 2019 19:39:37 -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=OZNtSI9CKtKOkl7KOc3F16cbQ2HPt3HtheEnqchRlDU=; b=DmBbjVNgaHxBZirhTCA4wuFZfGihhQHq6w4Oskk8Z+BYMlsrwAZAUYRr9me9IhfOXy XeGCTjEYOuTWDBbbxpwCV78KcW4zDQirjJLI59N1pycwZATANBP+y5ezXQBTEzXuueyy FByA5RxakLpG8wfqNBFzcsNdmAMQD1km3sq1/LRg0p71DA7Dp7QX4RyElY24Q0EJWA1Q Lq0yKKDQ5iBBMdg1vRTKnpxldhmSH4V0I+kXYjAHllqIjBTkEhQzXQHq9qEvTEuklsS6 7H1B4ThbGhKOa6lGum7cltZ+MkXZSUWWUJ5MpSy8ttS1514Zcj+ZB0TErLM7L4KYbPrN ynlA==
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=OZNtSI9CKtKOkl7KOc3F16cbQ2HPt3HtheEnqchRlDU=; b=Gwgh5nk5bWfFWY4lo0xwGTf4/EWsFnEwgUwGH1B5lLSVMSFAcxXTRCX2dT5bKGsDBq a59qVbV3tOgGLhsKY+Cn3AnXFLOJylDO08qBWlOPbfVrbOcKzg/crpDFtgN/JUtqrF71 Z5HpQVsqp1jHKSlB1CJzqf/Ce+yb8qB46rOjG73Fmu3w1eUV0xpPvKWa/Z5c13g8WNjw XoFj/V7EoRogUPhqiiKDLlEXekW9GU3JjXb1M+t/wS6VExpQx9P/jG/V9bBLFP6VDd04 98fQxfleqEvvh1RwlgtWQluKremMf9LmHOrUz/huueOozOp42c/2NxrISFePhj6w414w vXbQ==
X-Gm-Message-State: APjAAAUYd18hVSPZoeiTW+lDvpjRUQIfqq73cSqonvue/n7+t/bQ4q3T PrYIeQEuh+pnSpPBzNWvqIIOKYsKEQ5MjLIqCvM=
X-Google-Smtp-Source: APXvYqxjma31q9w+b79Z6dDAm1YrmSQwLNyhGmddZRlAYr2gp6mbCDTuu/WA2TNQ6pZROIe+ikSyQS7crzdt/2blV0c=
X-Received: by 2002:a05:6512:71:: with SMTP id i17mr11841032lfo.113.1573961975482; Sat, 16 Nov 2019 19:39:35 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMGdzjDyr--zvjmXmjkzzHcuFxEVZKhs_nP87cZPQjW4AQ@mail.gmail.com> <7555D751-34CF-4968-ACD6-580DF8A41341@juniper.net>
In-Reply-To: <7555D751-34CF-4968-ACD6-580DF8A41341@juniper.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 17 Nov 2019 11:39:24 +0800
Message-ID: <CA+RyBmVRyvyW400VXtTXeHkRkFH6YKUXeuPWw5GkvD51BwzmEg@mail.gmail.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Cc: Robert Raszuk <robert@raszuk.net>, "spring@ietf.org" <spring@ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-voyer-spring-sr-replication-segment.authors@ietf.org" <draft-voyer-spring-sr-replication-segment.authors@ietf.org>, "<spring-chairs@tools.ietf.org> (spring-chairs@tools.ietf.org)" <spring-chairs@tools.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000704d30059782944c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/RyF3WYcHTV68xhsr6hxiNXHaA6o>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"
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: Sun, 17 Nov 2019 03:39:42 -0000

Dear All,
I concur with Sasha and John. Intended ingress replication of a particular
flow, though using a unicast destination address, is still a multicast.

Regards,
Greg

On Thu, Nov 14, 2019 at 5:36 AM John E Drake <jdrake=
40juniper.net@dmarc.ietf.org> wrote:

> Robert,
>
> As Sasha and I have indicated, your position is your own and is not
> consistent with the majority of work on this topic.  I’m fine w/ agreeing
> to disagree.
>
> John
>
> Sent from my iPhone
>
> On Nov 14, 2019, at 2:57 AM, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
> John,
>
> > Your claim that ingress replication is not multicast is, at best, a
> stretch.
>
> I use a very basic and simple rule of thumb ... if address of my packet is
> a multicast address then it is multicast if not it is unicast.
>
> Ref:
> https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
> <https://urldefense.com/v3/__https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml__;!8WoA6RjC81c!QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ$>
>
>
> Solution as described in draft-voyer-spring-sr-replication-segment does
> not seems to be requiring multicast addresses hence it is applicable to
> pure unicast networks.
>
> Thx,
> Robert.
>
>
> On Wed, Nov 13, 2019 at 10:20 PM John E Drake <jdrake@juniper.net> wrote:
>
>> Robert,
>>
>>
>>
>> I’m sorry for the confusion.  My only point was that MVPN provides the
>> reference architecture for dealing w/ multicast using a multiplicity of
>> tunnel types in a consistent manner, as Sasha alluded to in his mention of
>> PMSI.  Your claim that ingress replication is not multicast is, at best, a
>> stretch.
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* Wednesday, November 13, 2019 3:55 PM
>> *To:* John E Drake <jdrake@juniper.net>
>> *Cc:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
>> spring@ietf.org;
>> draft-voyer-spring-sr-replication-segment.authors@ietf.org; <
>> spring-chairs@tools.ietf.org> (spring-chairs@tools.ietf.org) <
>> spring-chairs@tools.ietf.org>
>> *Subject:* Re: [spring] The SPRING WG has placed
>> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
>> Adoption"
>>
>>
>>
>> Hi John,
>>
>>
>>
>> > Further, ingress replication has been part of MVPN since forever.
>>
>>
>>
>> Just curious how is this at all relevant for this discussion ?
>>
>>
>>
>> Do I have to roll out MVPN monster to split my unicast UDP stream to few
>> receivers at selected network point ?
>>
>>
>>
>> And last but not least who said this is at all related to "ingress
>> replication" ??? Ingress to p2mp segment can be at any SR midpoint in the
>> network. Are you suggesting to run MVPN apparatus with manual tree building
>> ? Whow :)
>>
>>
>>
>> Thx,
>>
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 13, 2019 at 9:40 PM John E Drake <jdrake@juniper.net> wrote:
>>
>> Hi,
>>
>>
>>
>> I think Sasha has a valid point.  Further, ingress replication has been
>> part of MVPN since forever.
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Alexander
>> Vainshtein
>> *Sent:* Wednesday, November 13, 2019 9:26 AM
>> *To:* Robert Raszuk <robert@raszuk.net>
>> *Cc:* spring@ietf.org;
>> draft-voyer-spring-sr-replication-segment.authors@ietf.org; <
>> spring-chairs@tools.ietf.org> (spring-chairs@tools.ietf.org) <
>> spring-chairs@tools.ietf.org>
>> *Subject:* Re: [spring] The SPRING WG has placed
>> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
>> Adoption"
>>
>>
>>
>> Robert,
>>
>> Lots of thanks for a prompt response.
>>
>>
>>
>> You seem to imply that a multicast distribution tree that is built, say,
>> by an SDN controller and used, say, to act as a PMSI in the mVPN
>> application, is not really a multicast.  Personally I disagree, but this is
>> a matter of taste and terminology.
>>
>>
>>
>> What looks unambiguous to me is that:
>>
>>    - The WG charter explicitly mentions ingress replication as one of
>>    “new types of segments mapping to forwarding behavior” that “may require
>>    architectural extensions”
>>    - The current architecture document does not cover any such segment
>>    type (whether because such segments have been considered as related to
>>    multicast by the authors, or for some other reason is not all that
>>    important. )
>>
>> Therefore my concern remains unresolved regardless of whether ingress
>> replication is or is not formally considered as multicast.
>>
>>
>>
>> Regards,
>>
>> Sasha
>>
>>
>>
>> Office: +972-39266302
>>
>> Cell:      +972-549266302
>>
>> Email:   Alexander.Vainshtein@ecitele.com
>>
>>
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* Wednesday, November 13, 2019 4:15 PM
>> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>> *Cc:* <spring-chairs@tools.ietf.org> (spring-chairs@tools.ietf.org) <
>> spring-chairs@tools.ietf.org>;
>> draft-voyer-spring-sr-replication-segment.authors@ietf.org;
>> spring@ietf.org
>> *Subject:* Re: [spring] The SPRING WG has placed
>> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
>> Adoption"
>>
>>
>>
>> Sasha,
>>
>>
>>
>> If I have some content and I send it to you and your neighbour as two
>> unicast streams am I suddenly doing multicast ?
>>
>>
>>
>> IMHO N number of replicated unicasts is still not a multicast.
>>
>>
>>
>> Multicast in my definition requires  multicast groups, receiver joins,
>> tree building protocols etc ... and this draft does not suggest any of
>> this. IN contrast it just describes how can we have p2mp unicast
>> distribution ... call it fan out node.
>>
>>
>>
>> Thx,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 13, 2019 at 12:42 PM Alexander Vainshtein <
>> Alexander.Vainshtein@ecitele.com> wrote:
>>
>> Hi all,
>>
>> I have a question regarding adoption of
>> draft-voyer-sr-spring-replication-segment as a SPRING WG document.
>>
>>
>>
>> These concerns are based on the following:
>>
>> 1.       This draft (both based on its title and on its content) deals
>> with local (in the Root node) ingress replication which, in its turn, is
>> one of the issues that could be used for delivery of multicast.
>>
>> 2.       Local ingress replication is mentioned in the SPRING WG Charter
>> as one of the “New types of segments mapping to forwarding behavior”.
>> The charter further says that “Any of the above <*Sasha: New types of
>> segments*> may require architectural extensions”
>>
>> 3.       The current (and, AFAIK, the only existing) Segment Routing
>> Architecture document (RFC 8402
>> <https://urldefense.com/v3/__https:/clicktime.symantec.com/34qM9QogJnh1eY5nZPXYAkA6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402__;JSUlJSU!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU$>)
>> explicitly states in Section 6 that “Segment Routing is defined for
>> unicast. The application of the source-route concept to Multicast is not in
>> the scope of this document”.
>>
>> The combinations of observations above strongly suggests to me that a
>> document defining multicast-related extensions of segment routing
>> architecture should be very useful (if not mandatory) for progressing the
>> Replication Segment draft. From my POV the Replication Segment draft is not
>> (and is not intended to be) such a document.
>>
>>
>>
>> I wonder if there is an intention to produce such a document in the
>> timeframe that could be relevant for discussion of the Replication Segment
>> draft.
>>
>>
>>
>> Nothing in this message should be interpreted as my objection to (or
>> support of) adoption of the Replication Segment draft as a WG document *per
>> se*.
>>
>> Bit I find it difficult to take a position any which way without a clear
>> and commonly agreed upon framework for multicast in segment routing.
>>
>>
>>
>> Regards,
>>
>> Sasha
>>
>>
>>
>> Office: +972-39266302
>>
>> Cell:      +972-549266302
>>
>> Email:   Alexander.Vainshtein@ecitele.com
>>
>>
>>
>> -----Original Message-----
>> From: spring <spring-bounces@ietf.org> On Behalf Of IETF Secretariat
>> Sent: Tuesday, November 12, 2019 7:06 PM
>> To: draft-voyer-spring-sr-replication-segment@ietf.org;
>> spring-chairs@ietf..org; spring@ietf.org
>> Subject: [spring] The SPRING WG has placed
>> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
>> Adoption"
>>
>>
>>
>>
>>
>> The SPRING WG has placed draft-voyer-spring-sr-replication-segment in
>> state Candidate for WG Adoption (entered by Bruno Decraene)
>>
>>
>>
>> The document is available at
>>
>>
>> https://clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-spring-sr-replication-segment%2F
>> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-voyer-spring-sr-replication-segment*2F__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU$>
>>
>>
>>
>> Comment:
>>
>> IPR call:
>>
>>
>> https://clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_stJjBM5K6vr7QYw0HRKf-z0_us
>> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspring*2F_stJjBM5K6vr7QYw0HRKf-z0_us__;JSUlJSUlJQ!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU$>
>>
>>
>>
>> _______________________________________________
>>
>> spring mailing list
>>
>> spring@ietf.org
>>
>>
>> https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs$>
>>
>>
>>
>> ___________________________________________________________________________
>>
>> This e-mail message is intended for the recipient only and contains
>> information which is
>> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
>> received this
>> transmission in error, please inform us by e-mail, phone or fax, and then
>> delete the original
>> and all copies thereof.
>>
>> ___________________________________________________________________________
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3KSi9HHVnunMDQNLd2U3Sij6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk$>
>>
>>
>>
>> ___________________________________________________________________________
>>
>> This e-mail message is intended for the recipient only and contains
>> information which is
>> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
>> received this
>> transmission in error, please inform us by e-mail, phone or fax, and then
>> delete the original
>> and all copies thereof.
>>
>> ___________________________________________________________________________
>>
>> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>