From nobody Thu May 3 13:58:16 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA7D1201F2 for ; Thu, 3 May 2018 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FoNld_3n5HTg for ; Thu, 3 May 2018 13:58:11 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 14A69126CC7 for ; Thu, 3 May 2018 13:58:11 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id m18-v6so27990034lfb.0 for ; Thu, 03 May 2018 13:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=No4IaK79kxuzI30IrInlIkpQP/4JiLsxmaA42nLXzl4=; b=tPDde7HK8s0Ig1ubAIJ5bqLWleJqiEyQockOuB50ED9/mkLF6Tzy1VpYEkPBcPzlxg mSVB8XRQss0/RO59zfhQwE4igsdnpibRRqJcddxso43EHicngqGPvekc5jiW33m3nOv4 UWlXbUPXvKsX5SVtZ+U1dllSTgQNeY4fYeUWFGjFceynL0niK0bvg0Usn1Khr85NbYYU CRTt5omvZR8i6qPnFEiylyhJcB+11rawxEaccwRquoUSCf1SXkcE4GcFvQaiEoKvIOt/ CcqvctCTsk2rJLjqIYa2aqy4bygkrUjw3mIX78GTJ6c1MyuZAiKvhEZDIJuibJebXAsg eWIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=No4IaK79kxuzI30IrInlIkpQP/4JiLsxmaA42nLXzl4=; b=iQ74JMBVrdbYMmu6l7AXg8X9WtqvlsQCAb3LQQp4stNfYu1xhRwiGxqOGJVtm0gKWS 2kyzp3t7TDhlFT7UXva4+/cvQ8bngHU6k45sutVdijdx3Lj0PfAEzJnXO5WUNBEy97gK TJoQRTdfGW9mHXWibut2iNRSbw4tCMpFZhurDOs4+EeWR2NVPoWWoLJUFfi+TtqJ/4fg K+HXbvPy2+AMjkYGacnJguKrRvlZNP2L1HqCin140aZFrUoPfk40aL1QqAze2D58kXFc EiAzmDeuFBXEhTr5eS5o3kCKZcRH0ysS1qWGvS9P67eXbsWE7yM6n3oqbMTFo4QFtlJP TpDw== X-Gm-Message-State: ALQs6tCIJUyC7fLdoEidE/h0Hy7QU8/7km2mNb7VDjOc6W4ZgnTnrKPI fWygYsMeOGSXtzbu2CuQN9MIo+PYy3oX6Xui6Ns= X-Google-Smtp-Source: AB8JxZr4xZ4v9FRvcrPgZQOOKME/XwI3oQA/o4JfXbkGv6ICuG+PNrL6TPOF0WKEj7TuENwUtJkFV83Z3/PhgXCIaqk= X-Received: by 2002:a2e:8246:: with SMTP id j6-v6mr7927718ljh.72.1525381089274; Thu, 03 May 2018 13:58:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.133.13 with HTTP; Thu, 3 May 2018 13:58:08 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Thu, 3 May 2018 13:58:08 -0700 Message-ID: To: Stig Venaas Cc: Tony Przygienda , BIER WG Content-Type: multipart/alternative; boundary="000000000000f93234056b537501" Archived-At: Subject: Re: [Bier] draft-venaas-bier-mtud X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 20:58:14 -0000 --000000000000f93234056b537501 Content-Type: text/plain; charset="UTF-8" Hi Stig, sorry for such long delay to respond. I think that in closing in Section 3 we've anticipated the idea of SMTU: o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU value for discovery or use it as MTU for this BIER sub-domain to reach BFERs; I agree with you suggestion to add to PMTUD draft text about ECMP environment. Section 3 describes the PMTUD mechanism and I think it is the most appropriate place. Please consider text I'd like to add: OLD TEXT A BFIR selects a set of BFERs for the specific multicast distribution. Such a BFIR determines, by explicitly controlling subset of targeted BFERs and transmitting series of probe packets, the MTU of that multicast distribution tree. NEW TEXT A BFIR selects a set of BFERs for the specific multicast distribution. Such a BFIR determines, by explicitly controlling subset of targeted BFERs and transmitting series of probe packets, the MTU of that multicast distribution tree. In case of ECMP, BFIR MAY test each path by variating the value in Entropy field. There are many scenarios that may trigger BFIR to re-running PMTUD. We refered to them as "locally defined" in o a BFIR MUST have a locally defined of PMTUD probe retransmission procedure. Appreciate your consideration, comments. Regards, Greg On Thu, Mar 29, 2018 at 9:56 AM, Stig Venaas wrote: > Hi > > On Wed, Mar 28, 2018 at 10:16 PM, Greg Mirsky > wrote: > > Hi Stig, > > thank you for your kind consideration of my comments. I think that > > Thanks, I appreciate your feedback as well. > > > sub-domain MTUD and PMTUD methods are complementary (I'd characterize > > sub-domain method as "conservative" rather than "pessimistic" :) ). > > Yes, conservative sounds better, thanks! > > I agree the solutions can be complimentary. In a very diverse network > with a few "thin" links, and with flows with big packets that are > unlikely to hit the think links, PMTUD might be better. One > possibility could be that for a new flow one starts with what is the > sub-doman MTU (SDMTU), then one can optionally infrequently perform > PMTU probing to see if the flow MTU (FMTU) is indeed larger than the > SD MTU. If an FMTU > SDMTU is detected, one can allow the FMTU to be > used for that particular flow and do more frequent probing in case the > FMTU should become smaller due to receiver/topology changes. > > My main concern with FMTU probing is that there can be packet drops > when the actual MTU is reduced and until the next probe is sent. Hence > one need to do fairly frequent probing. By knowing the SDMTU, one can > avoid the frequent probing in some cases, as I wrote above. > > > Couple notes on use cases you've mentioned: > > > > yes, when a new receiver added, PMTUD to it may be performed; > > I think this is important as the MTU might change whenever the > receiver set changes. In traditional multicast I would call it the > Tree MTU. With BIER we don't have any explicit trees, so a Flow MTU > might be a better term. > > > in the ECMP environment PMTUD will use the same Entropy field value as > the > > flow for which the MTU to be discovered. > > Right. I was initially thinking that if different flows had the same > receiver set, there was no need to probe for each of the flows, but at > least with ECMP one would need to probe for each entropy value being > used. The easiest is probably to just do the probing for each flow. > > I think it would be good to have more text in the PTMUD draft > explaining the above. Also, some discussion about the probe frequency. > How it is helpful to use a high frequency, but there is a trade-off (I > think) between how quickly you need to discover a lower MTU and the > scale (the number of flows that you need to probe). > > Stig > > > > > Regards, > > Greg > > > > On Thu, Mar 29, 2018 at 1:14 AM, Stig Venaas wrote: > >> > >> Hi > >> > >> I can certainly work on the wording. Perhaps the more important > >> discussion, which you also brought up, is whether it is worth doing a > >> pessimistic MTU in the sense that it is sub-domain wide, rather than a > >> path MTU that can be more optimal. One problem with path MTU and > >> multicast, is that it changes as the receiver set changes. For a > >> particular (S,G) an ingress router needs to consider the path MTU > >> towards each of the egress routers. This means that you need to > >> discover the path MTU at least each time a new receiver is added (a > >> new BIER bit is set) for the (S,G). Also, at any time there can be a > >> routing change lowering the MTU, and packets would get dropped until > >> the new path MTU is discovered. > >> > >> A sub-domain MTU is more pessimistic, but I think it is more robust > >> than probing. There is less risk of packet drops (from when actual > >> path MTU is reduced and until it is discovered by a probe), and there > >> is no need of rediscovering path MTU each time a new receiver is > >> added. It is also easier to implement. > >> > >> I'm also wondering how probing is supposed to work with ECMP. Would > >> the ingress router need to do a new probe each time it encapsulates > >> packets with a new entropy? > >> > >> Stig > >> > >> > >> > >> > >> > >> On Mon, Mar 19, 2018 at 10:33 AM, Greg Mirsky > >> wrote: > >> > Dear Authors, et. al, > >> > I understand the idea of aggregating MTU in the given BIER sub-domain > >> > but > >> > I'm concerned that if there are interfaces with significantly > different > >> > MTUs, that the proposed approach may result in lower MTU being > enforced > >> > on > >> > paths capable of larger MTU. The BIER PMTUD draft does provide per > path > >> > information. > >> > > >> > Regards, > >> > Greg > >> > > >> > On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda > > >> > wrote: > >> >> > >> >> Comments: > >> >> > >> >> a) " > >> >> Every BIER router, for each sub-domain with at least > >> >> one local BIER interface in the sub-domain, per the above > definition > >> >> of a BIER interface, determines the largest payload that can be > sent > >> >> BIER encapsulated out of any of its BIER interfaces in the sub- > >> >> domain. > >> >> " > >> >> > >> >> The language here is unclear. Is that the MIN(all used subdomain > >> >> interface > >> >> MTUs) ? If so, then it makes sense. > >> >> > >> >> b) May merit a section saying that albeit this is much lighter-weight > >> >> than > >> >> I-D.ietf-bier-path-mtu-discovery of course it can be widely > pessimistic > >> >> since it always picks up the smallest link in the whole subdomain > >> >> > >> >> c) "MTU in octets" is seriously underspecified. We have ether mtu, > link > >> >> mtu, interface mtu and so on. The draft should specifiy what the > >> >> precise way > >> >> is to advertise the "BIER MTU" here IMO ... > >> >> > >> >> --- tony > >> >> > >> >> _______________________________________________ > >> >> BIER mailing list > >> >> BIER@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/bier > >> >> > >> > > >> > > >> > _______________________________________________ > >> > BIER mailing list > >> > BIER@ietf.org > >> > https://www.ietf.org/mailman/listinfo/bier > >> > > > > > > --000000000000f93234056b537501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stig,
sorry for such long delay to respond.
I think that in closing in Section 3 we've anticipated the idea of S= MTU:
=C2=A0 =C2=A0o=C2=A0 a BFR MAY use defined per BIER sub= -domain MTU value as initial MTU
=C2=A0 =C2=A0 =C2=A0 value for d= iscovery or use it as MTU for this BIER sub-domain to
=C2=A0 =C2= =A0 =C2=A0 reach BFERs;

I agree with you sug= gestion to add to PMTUD draft text about ECMP environment. Section 3 descri= bes the PMTUD mechanism and I think it is the most appropriate place. Pleas= e consider text I'd like to add:
OLD TEXT
=C2=A0 =C2=A0A BFIR selects a set of BFERs for the specific multicast
=C2=A0 =C2=A0distribution.=C2=A0 Such a BFIR determines, by explicitly c=
ontrolling
=C2=A0 =C2=A0subset of targeted BFERs and transmitting serie=
s of probe packets,
=C2=A0 =C2=A0the MTU of that multicast distribution=
 tree.
NEW TEXT
=C2=A0 =C2=A0A BFIR selects a se= t of BFERs for the specific multicast
=C2=A0 =C2=A0distribution.= =C2=A0 Such a BFIR determines, by explicitly controlling
=C2=A0 = =C2=A0subset of targeted BFERs and transmitting series of probe packets,
=C2=A0 =C2=A0the MTU of that multicast distribution tree. In case o= f ECMP, BFIR
=C2=A0 =C2=A0MAY test each path by variating t= he value in Entropy field.

There are many scenario= s that may trigger BFIR to re-running PMTUD. We refered to them as "lo= cally defined" in
=C2=A0 =C2=A0o=C2=A0 a BFIR MUST have= a locally defined of PMTUD probe retransmission
=C2=A0 =C2=A0 = =C2=A0 procedure.


Appreciate = your consideration, comments.

Regards,
G= reg

On= Thu, Mar 29, 2018 at 9:56 AM, Stig Venaas <stig@venaas.com> w= rote:
Hi

On Wed, Mar 28, 2018 at 10:16 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> Hi Stig,
> thank you for your kind consideration of my comments. I think that

Thanks, I appreciate your feedback as well.

> sub-domain MTUD and PMTUD methods are complementary (I'd character= ize
> sub-domain method as "conservative" rather than "pessim= istic" :) ).

Yes, conservative sounds better, thanks!

I agree the solutions can be complimentary. In a very diverse network
with a few "thin" links, and with flows with big packets that are=
unlikely to hit the think links, PMTUD might be better. One
possibility could be that for a new flow one starts with what is the
sub-doman MTU (SDMTU), then one can optionally infrequently perform
PMTU probing to see if the flow MTU=C2=A0 (FMTU) is indeed larger than the<= br> SD MTU. If an FMTU > SDMTU is detected, one can allow the FMTU to be
used for that particular flow and do more frequent probing in case the
FMTU should become smaller due to receiver/topology changes.

My main concern with FMTU probing is that there can be packet drops
when the actual MTU is reduced and until the next probe is sent. Hence
one need to do fairly frequent probing. By knowing the SDMTU, one can
avoid the frequent probing in some cases, as I wrote above.

> Couple notes on use cases you've mentioned:
>
> yes, when a new receiver added, PMTUD to it may be performed;

I think this is important as the MTU might change whenever the
receiver set changes. In traditional multicast I would call it the
Tree MTU. With BIER we don't have any explicit trees, so a Flow MTU
might be a better term.

> in the ECMP environment PMTUD will use the same Entropy field value as= the
> flow for which the MTU to be discovered.

Right. I was initially thinking that if different flows had the same=
receiver set, there was no need to probe for each of the flows, but at
least with ECMP one would need to probe for each entropy value being
used. The easiest is probably to just do the probing for each flow.

I think it would be good to have more text in the PTMUD draft
explaining the above. Also, some discussion about the probe frequency.
How it is helpful to use a high frequency, but there is a trade-off (I
think) between how quickly you need to discover a lower MTU and the
scale (the number of flows that you need to probe).

Stig

>
> Regards,
> Greg
>
> On Thu, Mar 29, 2018 at 1:14 AM, Stig Venaas <stig@venaas.com> wrote:
>>
>> Hi
>>
>> I can certainly work on the wording. Perhaps the more important >> discussion, which you also brought up, is whether it is worth doin= g a
>> pessimistic MTU in the sense that it is sub-domain wide, rather th= an a
>> path MTU that can be more optimal. One problem with path MTU and >> multicast, is that it changes as the receiver set changes. For a >> particular (S,G) an ingress router needs to consider the path MTU<= br> >> towards each of the egress routers. This means that you need to >> discover the path MTU at least each time a new receiver is added (= a
>> new BIER bit is set) for the (S,G). Also, at any time there can be= a
>> routing change lowering the MTU, and packets would get dropped unt= il
>> the new path MTU is discovered.
>>
>> A sub-domain MTU is more pessimistic, but I think it is more robus= t
>> than probing. There is less risk of packet drops (from when actual=
>> path MTU is reduced and until it is discovered by a probe), and th= ere
>> is no need of rediscovering path MTU each time a new receiver is >> added. It is also easier to implement.
>>
>> I'm also wondering how probing is supposed to work with ECMP. = Would
>> the ingress router need to do a new probe each time it encapsulate= s
>> packets with a new entropy?
>>
>> Stig
>>
>>
>>
>>
>>
>> On Mon, Mar 19, 2018 at 10:33 AM, Greg Mirsky <gregimirsky@gmail.com>
>> wrote:
>> > Dear Authors, et. al,
>> > I understand the idea of aggregating MTU in the given BIER su= b-domain
>> > but
>> > I'm concerned that if there are interfaces with significa= ntly different
>> > MTUs, that the proposed approach may result in lower MTU bein= g enforced
>> > on
>> > paths capable of larger MTU. The BIER PMTUD draft does provid= e per path
>> > information.
>> >
>> > Regards,
>> > Greg
>> >
>> > On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda <tonysietf@gmail.com>
>> > wrote:
>> >>
>> >> Comments:
>> >>
>> >> a)=C2=A0 "
>> >> Every BIER router, for each sub-domain with at least
>> >>=C2=A0 =C2=A0 one local BIER interface in the sub-domain, = per the above definition
>> >>=C2=A0 =C2=A0 of a BIER interface, determines the largest = payload that can be sent
>> >>=C2=A0 =C2=A0 BIER encapsulated out of any of its BIER int= erfaces in the sub-
>> >>=C2=A0 =C2=A0 domain.
>> >> "
>> >>
>> >> The language here is unclear. Is that the MIN(all used su= bdomain
>> >> interface
>> >> MTUs) ? If so, then it makes sense.
>> >>
>> >> b) May merit a section saying that albeit this is much li= ghter-weight
>> >> than
>> >> I-D.ietf-bier-path-mtu-discovery of course it can be= widely pessimistic
>> >> since it always picks up the smallest link in the whole s= ubdomain
>> >>
>> >> c) "MTU in octets" is seriously underspecified.= We have ether mtu, link
>> >> mtu, interface mtu and so on. The draft should specifiy w= hat the
>> >> precise way
>> >> is to advertise the "BIER MTU" here IMO ...
>> >>
>> >> --- tony
>> >>
>> >> _______________________________________________
>> >> BIER mailing list
>> >> BIER@ietf.org
>> >> https://www.ietf.org/mailman/listin= fo/bier
>> >>
>> >
>> >
>> > _______________________________________________
>> > BIER mailing list
>> > BIER@ietf.org
>> > https://www.ietf.org/mailman/listinfo/b= ier
>> >
>
>

--000000000000f93234056b537501-- From nobody Tue May 8 10:48:28 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3741273B1 for ; Tue, 8 May 2018 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 URCjCScvpKsr for ; Tue, 8 May 2018 10:48:24 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 94FA11270AB for ; Tue, 8 May 2018 10:48:24 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w48Hi5GB029142 for ; Tue, 8 May 2018 10:48:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=0ieVgi1phoMXhrHXz3j7P++he73o+tjccgxEtXbiu+Q=; b=N79tyl4JUYZY5erow3YnFk9lbHNQCungTvvkMdw/C7oTYU2NvihCqOgqFB3QG/TLO8C5 3FPgOOOlJC+5G0t7neM4rvkIXpmB8OotXMrlypjentvz6YnN2eV/D3Crp+/b41KvigZU vnGySqT7zsmutaXpCSEhwynaZpK5p5Umf6mGENMIFXpg+JLnd6+SifPXrzg/xiLjclp5 zrNgELKweX6j4QI/rzr/n9Y7K80MGukiAq84MDhAXG/IanG63MobEGM/Bxa8ZSFCMNIg 21Bp/0m/MnXqXcRz1h1I4EMzWI1/bVymwRhdOB4zII8ItZ9Lt6kGFmgjEtqFJl+KJLG8 BQ== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0019.outbound.protection.outlook.com [207.46.163.19]) by mx0a-00273201.pphosted.com with ESMTP id 2hufger58k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 08 May 2018 10:48:24 -0700 Received: from BN3PR05MB2642.namprd05.prod.outlook.com (10.166.72.18) by BN3PR05MB2689.namprd05.prod.outlook.com (10.166.74.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.755.10; Tue, 8 May 2018 17:48:22 +0000 Received: from BN3PR05MB2642.namprd05.prod.outlook.com ([fe80::cda1:8355:9f97:ed82]) by BN3PR05MB2642.namprd05.prod.outlook.com ([fe80::cda1:8355:9f97:ed82%5]) with mapi id 15.20.0755.012; Tue, 8 May 2018 17:48:22 +0000 From: "Jeffrey (Zhaohui) Zhang" To: BIER WG Thread-Topic: draft-ietf-bier-idr-extensions questions & comments Thread-Index: AdPm8swyuDA9rqv9RbKmroaZX6kKYg== Date: Tue, 8 May 2018 17:48:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR05MB2689; 7:8zANXeXUA264QFy9teEC4TS8zouELh+rhMMxC1ZqyEyPnCYhFHLVRxmj10tGPsdWEVkgDVZk8czNfGprZ+vv3eDSVPTOSQPaKAEGlvh1z9hK3Hl3RyYaUoXxgRnO+/sJPf4StPtQV4p+T/aKi68NI1MfPqJ902a3ukzzsFnpGjHlztdCDJyDPqf4N/Q0vvcSKTp3X5373ovfF10YCQ7+tukCvL15Yn1bvGacdyc/TWEgXSXSSMoKtcsshkIv5uku x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BN3PR05MB2689; x-ms-traffictypediagnostic: BN3PR05MB2689: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN3PR05MB2689; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2689; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39380400002)(346002)(39860400002)(366004)(189003)(199004)(25584004)(14454004)(2900100001)(9686003)(55016002)(53936002)(105586002)(86362001)(8936002)(478600001)(74316002)(106356001)(6506007)(66066001)(305945005)(25786009)(7696005)(8676002)(81156014)(59450400001)(81166006)(5660300001)(186003)(486006)(6436002)(102836004)(26005)(6916009)(3846002)(97736004)(6116002)(7736002)(5250100002)(2906002)(5890100001)(68736007)(3280700002)(99286004)(33656002)(476003)(3660700001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2689; H:BN3PR05MB2642.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: XfMN+UnZWeHNoRJtkQCHrxOJvofyLgDbv/PswozCzMscnjQCMhjkcknNM0nbBPInwlR1+Xdp4oLPwI0bV+/CJwHA/TtqaQL4uyTQFIMeh3e85Y4bWa3r1EXPAGi6ph24CU/ERpVm+0eepkbdqP1ctmdCrWefxEcnD+SNop9p43LatjAeKNtGOKtLXJUqbLOh spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9c7763ee-425b-4650-5d06-08d5b50be470 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9c7763ee-425b-4650-5d06-08d5b50be470 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 17:48:22.4317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2689 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-08_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805080170 Archived-At: Subject: [Bier] draft-ietf-bier-idr-extensions questions & comments X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:48:26 -0000 Hi, I have some questions and comments on this. With the following DC scenario, These extensions are applicable in those multi-tenant data centers where BGP instead of IGP is used as an underlay [RFC7938]. Since many EBGP sessions may be used inside the DC, do we still want the fo= llowing on EACH EBGP session? An implementation that supports the BIER attribute MUST support a per-EBGP-session policy, that indicates whether the attribute is enabled or disabled for use on that session. The BIER attribute MUST NOT be sent on any EBGP peers for which the session policy is not configured. If an BIER attribute is received on a BGP session for which session policy is not configured, then the received attribute MUST be treated exactly as if it were an unrecognised non-transitive attribute. That is, "it MUST be quietly ignored and not passed along to other BGP peers". Seems that the policy is only needed on sessions to peers OUTSIDE the BIER = domain. 4. Originating BIER Attribute An implementation that supports the BIER attribute MUST support a policy to enable or disable the creation of the BIER attribute and its attachment to specific BGP routes. An implementation MAY disable the creation of the BIER attribute unless explicitly configured to do so otherwise. A BGP speaker MUST only attach the locally created BIER attribute to a BGP UPDATE message in which at least one of its BFR-prefixes is contained in the NLRI What does the last sentence in the above paragraph mean? When would a route= r has more than one BFR-prefixes? Say a router has 5 local prefixes with on= e being the BIER prefix. Does it advertise one update with the BIER attribu= te or does it advertise two updates and only the one with the BIER prefix c= arry the attribute? The document should have a section describing how BIRT/BIFT entries are bui= lt. Jeffrey From nobody Tue May 8 13:27:43 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243012EAB1 for ; Tue, 8 May 2018 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 AHr0_hY71Wjh for ; Tue, 8 May 2018 13:27:38 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 9664F12EAB0 for ; Tue, 8 May 2018 13:27:37 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id o123-v6so47758164lfe.8 for ; Tue, 08 May 2018 13:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Kg4ZCAUBmpRTZ1cNnwkIWy2QQOW4SIjUAiPu2tTXLko=; b=Oql1+y3jEKNSAcsw+6ZOeneKucqZo972HcbmXmFZFfYzy0VMJ9KulPUf6OjtntoUyE c/5OnZeteAlMcE7FjhLLULi81x1AjlJN9/sPTLVadXlARns+PHmXMqfxDzskBDt1dsPM /rMwgMzSFi801039D0aoT2HJGAoZSK1mfJSVb0n87pKZFXMRYrDmUP2HhTvKCFDgodHY jX3BdPKqj1uXJy/vI/GBzZwvRkV/aMNxKbyPdG75sFJYf5JO4X2m2tXrTaHSjAHTUXrU 5uP4UaMrxFNIsmp7AnncpRweWFvaWnxQoDR99prxEes8Fbzu3CwzEzeYcURaVI3LJgiZ IfDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Kg4ZCAUBmpRTZ1cNnwkIWy2QQOW4SIjUAiPu2tTXLko=; b=H8LRpwJAAJHBUfRe3ypCHHrKAy/4i8bzfy8s9mDIGAjv9W9WZ3LvPHy7WUnCd3tQfd G1w9FeNFDCxOQBnfh+I+LuNQaqDqLUnsZ7tyfZqmE6rrz+x32o2H8xnf9XVpKxZALZk0 EMQkgzt2RnjVF+0Q8uJdjUJEWxzAbOnk4u9Cf9SaSpVfuezSQVNfkF+8Y5WGb72Nu2LN LUMEQgtyXFT12UKFTmPGlUMQREe76D7Xo9P0SpmqnKouzDAtZdMClQ2ypkwPmOJq6iIt o5nifAhXRvjVZ8636MJ46BMhpznHlIwbZf/ZgOACLuWCy9HYz3s7HOjm+FfMk49St6QJ W1Kg== X-Gm-Message-State: ALQs6tCEQq9dr7C53/sedywY1Q+AX6z5xbhK7eKMNchvmB0LqiTEANYL /+nyU0ngmjlqfPRbJ1qnKqs7iJKHfW0UBDNYES8= X-Google-Smtp-Source: AB8JxZpSFsWe9LNUFCfP2y2hxjFUECp6cbXilSKuzMk3Sx5fGZdOT4qoHvr+JOiFm5RHMFTXaPi2zE+IaQGPyhSN+9g= X-Received: by 2002:a19:1d84:: with SMTP id d126-v6mr28060805lfd.100.1525811255500; Tue, 08 May 2018 13:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.133.13 with HTTP; Tue, 8 May 2018 13:27:34 -0700 (PDT) In-Reply-To: References: <20180403223613.GA1612@faui40p.informatik.uni-erlangen.de> From: Greg Mirsky Date: Tue, 8 May 2018 13:27:34 -0700 Message-ID: To: BIER WG Content-Type: multipart/alternative; boundary="000000000000e0e6fa056bb79d27" Archived-At: Subject: [Bier] Fwd: draft-ietf-bier-path-mtu-discovery-03 comments X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 20:27:42 -0000 --000000000000e0e6fa056bb79d27 Content-Type: text/plain; charset="UTF-8" Now with correct BIER WG list ---------- Forwarded message ---------- From: Greg Mirsky Date: Tue, May 8, 2018 at 12:15 PM Subject: Re: draft-ietf-bier-path-mtu-discovery-03 comments To: Toerless Eckert Cc: draft-ietf-bier-path-mtu-discovery@ietf.org, bier@ief.org Hi Toerless, thank you for the review, your thoughtful comments. Please find my answers, notes in-line and tagged GIM>>. Regards, Greg On Tue, Apr 3, 2018 at 3:36 PM, Toerless Eckert wrote: > Quite nice. Almost makes me not hate PMTUD ;-) > > Would suggest to add two explanatory things > > 1) Abstract > > Sentence like "PMTUD for BIER as described here is significantly easier > than PMTUD for IP multicast, because it leverages unique properties of > BIER" > GIM>> How about OLD TEXT This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. NEW TEXT This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer that leverages unique properties of the BIER architecture. > > > 2) Add section "comparison with PMTUD for IP multicast" > GIM>> I couldn't find any reference to PMTUD for IP multicast neither RFC, nor an implementation. Without such source comparison, I'm afraid, may look like speculation. Third paragraph in Section 2 points to some of the problems that you've detailed. Perhaps we can let the reader to uncover the challlenges of PMTUD in IP multicast. What do you think? > > Summarize the claim from abstract, e.g.: > > a) The network/transport stack of sender in IP multicast has usually no > clear > understanding who their receivers are, so it is more difficult to > figure out when to re-probe. > > b) Senders in IP multicast can not target any subset of receivers to probe > their > MTU. In BIER this is at the core of the BIER forwarding mechnism. > > c) Midpoints in IP multicast with an MTU issue have even less chance to > know > what subset of receivers is south of the adjacenc with MTU issues (the > sender > could have application layer mechanisms to know all receivers). In BIER > this > knowledge is immediately available from the bitstring of the packet > causing the issue. > > d) IP multicast trees can be arbitrarily large, which together with b) and > c) > has resulted in so many IP Multicast PMTUD that there is no standards > IP multicast > PMTUD discovery mechanism. > > In addition to the solutions to a)..c) that BIER provides, the number > of receivers > for every packet is also limited to the BSL. > > Or something similar fixing whatever might be wrong or missing in above. > > Cheers > Toerless > --000000000000e0e6fa056bb79d27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now with correct BIER WG list
---------- Forwarded message ----------
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, May 8, 2018 at= 12:15 PM
Subject: Re: draft-ietf-bier-path-mtu-discovery-03 commentsTo: Toerless Eckert <tte@cs.fau.de= >
Cc: = draft-ietf-bier-path-mtu-discovery@ietf.org, bier@ief.org


Hi Toerless,
thank y= ou for the review, your thoughtful comments. Please find my answers, notes = in-line and tagged GIM>>.

Regards,
Greg

On Tue, Apr 3, 2018 at 3:36 PM, Toerless Eckert <tte@cs.fau.de&= gt; wrote:
Quit= e nice. Almost makes me not hate PMTUD ;-)

Would suggest to add two explanatory things

1) Abstract

Sentence like "PMTUD for BIER as described here is significantly easie= r
than PMTUD for IP multicast, because it leverages unique properties of BIER= "
GIM>> How about
OLD TEXT=
=C2=A0 =C2=A0This document describes Path Maximum Transmission U= nit Discovery
=C2=A0 =C2=A0(PMTUD) in Bit Indexed Explicit Replic= ation (BIER) layer.=C2=A0
NEW TEXT
=C2=A0 =C2=A0Th= is document describes Path Maximum Transmission Unit Discovery
= =C2=A0 =C2=A0(PMTUD) in Bit Indexed Explicit Replication (BIER) layer that = leverages=C2=A0
=C2=A0 =C2=A0unique properties of the BIER archit= ecture.


2) Add section "comparison with PMTUD for IP multicast"
GIM>> I couldn't find any reference to PMTUD f= or IP multicast neither RFC, nor an implementation. Without such source com= parison, I'm afraid, may look like speculation. Third paragraph in Sect= ion 2 points to some of the problems that you've detailed. Perhaps we c= an let the reader to uncover the challlenges of PMTUD in IP multicast. What= do you think?

Summarize the claim from abstract, e.g.:

a) The network/transport stack of sender in IP multicast has usually no cle= ar
=C2=A0 =C2=A0understanding who their receivers are, so it is more difficult= to figure out when to re-probe.

b) Senders in IP multicast can not target any subset of receivers to probe = their
=C2=A0 =C2=A0MTU. In BIER this is at the core of the BIER forwarding mechni= sm.

c) Midpoints in IP multicast with an MTU issue have even less chance to kno= w
=C2=A0 =C2=A0what subset of receivers is south of the adjacenc with MTU iss= ues (the sender
=C2=A0 =C2=A0could have application layer mechanisms to know all receivers)= . In BIER this
=C2=A0 =C2=A0knowledge is immediately available from the bitstring of the p= acket causing the issue.

d) IP multicast trees can be arbitrarily large, which together with b) and = c)
=C2=A0 =C2=A0has resulted in so many IP Multicast PMTUD that there is no st= andards IP multicast
=C2=A0 =C2=A0PMTUD discovery mechanism.

=C2=A0 =C2=A0In addition to the solutions to a)..c) that BIER provides, the= number of receivers
=C2=A0 =C2=A0for every packet is also limited to the BSL.

Or something similar fixing whatever might be wrong or missing in above.
Cheers
=C2=A0 =C2=A0 Toerless


--000000000000e0e6fa056bb79d27-- From nobody Wed May 9 14:44:42 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD49129C51 for ; Wed, 9 May 2018 14:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 hv3XTB1BBE5N for ; Wed, 9 May 2018 14:44:38 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 22817129C6B for ; Wed, 9 May 2018 14:44:38 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a8-v6so821973wmg.5 for ; Wed, 09 May 2018 14:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F0/cJ5F2+rP0b8t8SqDPQFfcIuzFt5DXEF6U4VeTvhM=; b=PQEzxewah2lw580bO5kGZQsqtD41UJ8tsrAfZG3pXTj28MKZmq5deb5gwhW0X8STZH VNYHneFWtfv1zRgdyvxxixzl7cD5mxOTB727d2NWSDJ2izIJ6p1ZXdFXi2BslHnMlzM1 DrBRIhtqcKo4BMCsE8Z4K8SeOKMVRwhTejw0J3LH9fKBTJz6WsI66G/kxdTLcoDZn8qm jZjtWWWhOVTTq2YliRIMy1D0sNXnv4mlzReEQzEmH5nmOiYhouddQ/fm0cL64ontuvc1 ZEvUwe2hK58bfXdd737R60McsPoBr+riyQuU9bV6UkjumfL7DMFuLvjcPerWcL1kAbo5 TPWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F0/cJ5F2+rP0b8t8SqDPQFfcIuzFt5DXEF6U4VeTvhM=; b=DJPDDXKsgHh7JiLAMe504BZbeG6VKWSRIPS0XCzSfe/b9FnZ3u53uj+Un5PTaExazf MtA3ZTm2xmDyAPFfsfF3kiME94zgp09cSL4DHBDzT5ULSrImEolPD0JmeU6Kac3zQM74 mgIXikXf5H5e3sygW/fnuQshtWns2br7FK/0nIdNe+Ux9L7kue0FXSAm/TfWV5a8henr 7/Jyi0dvcgC70dYgmNo1GhwXrSMBQtWo2iO6Fn3MO8yb5J1thJZT7y9KQfMth4Tl2pSi XtSRk6jMRqTlkROLCEjeGGhaFEhGA41q1ytDvI6ZROEzwaRWd1QBo9801xOtxKvKRxJF fxpg== X-Gm-Message-State: ALQs6tA3MaDF03G9/lKgon/EfSLai2qDPmxvSy50wvPqm2rfChPl5TI7 J2o7El/R+focLCXVvEW7gazYO/oTD7Tdw11MmatgDQ== X-Google-Smtp-Source: AB8JxZoExO6cdWL15nM9PUuOlclPdt+7mmC0cSc5eiPJmdMK4/es/LWxh9dGedyi06q9YHPJsGZfjUp2skb9nEVxR5E= X-Received: by 2002:a50:a245:: with SMTP id 63-v6mr64136410edl.295.1525902276475; Wed, 09 May 2018 14:44:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.167.196.7 with HTTP; Wed, 9 May 2018 14:44:36 -0700 (PDT) In-Reply-To: References: From: Stig Venaas Date: Wed, 9 May 2018 14:44:36 -0700 Message-ID: To: Greg Mirsky Cc: Tony Przygienda , BIER WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Bier] draft-venaas-bier-mtud X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 21:44:40 -0000 Hi Greg This looks good. I completely missed that the PMTUD draft mentioned BIER sub-domain MTU. Thanks, I'll update my draft soon, and I can then also reference this discussion in your draft. Stig On Thu, May 3, 2018 at 1:58 PM, Greg Mirsky wrote: > Hi Stig, > sorry for such long delay to respond. > I think that in closing in Section 3 we've anticipated the idea of SMTU: > o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU > value for discovery or use it as MTU for this BIER sub-domain to > reach BFERs; > > I agree with you suggestion to add to PMTUD draft text about ECMP > environment. Section 3 describes the PMTUD mechanism and I think it is the > most appropriate place. Please consider text I'd like to add: > OLD TEXT > > A BFIR selects a set of BFERs for the specific multicast > distribution. Such a BFIR determines, by explicitly controlling > subset of targeted BFERs and transmitting series of probe packets, > the MTU of that multicast distribution tree. > > NEW TEXT > A BFIR selects a set of BFERs for the specific multicast > distribution. Such a BFIR determines, by explicitly controlling > subset of targeted BFERs and transmitting series of probe packets, > the MTU of that multicast distribution tree. In case of ECMP, BFIR > MAY test each path by variating the value in Entropy field. > > There are many scenarios that may trigger BFIR to re-running PMTUD. We > refered to them as "locally defined" in > o a BFIR MUST have a locally defined of PMTUD probe retransmission > procedure. > > > Appreciate your consideration, comments. > > Regards, > Greg > > On Thu, Mar 29, 2018 at 9:56 AM, Stig Venaas wrote: >> >> Hi >> >> On Wed, Mar 28, 2018 at 10:16 PM, Greg Mirsky >> wrote: >> > Hi Stig, >> > thank you for your kind consideration of my comments. I think that >> >> Thanks, I appreciate your feedback as well. >> >> > sub-domain MTUD and PMTUD methods are complementary (I'd characterize >> > sub-domain method as "conservative" rather than "pessimistic" :) ). >> >> Yes, conservative sounds better, thanks! >> >> I agree the solutions can be complimentary. In a very diverse network >> with a few "thin" links, and with flows with big packets that are >> unlikely to hit the think links, PMTUD might be better. One >> possibility could be that for a new flow one starts with what is the >> sub-doman MTU (SDMTU), then one can optionally infrequently perform >> PMTU probing to see if the flow MTU (FMTU) is indeed larger than the >> SD MTU. If an FMTU > SDMTU is detected, one can allow the FMTU to be >> used for that particular flow and do more frequent probing in case the >> FMTU should become smaller due to receiver/topology changes. >> >> My main concern with FMTU probing is that there can be packet drops >> when the actual MTU is reduced and until the next probe is sent. Hence >> one need to do fairly frequent probing. By knowing the SDMTU, one can >> avoid the frequent probing in some cases, as I wrote above. >> >> > Couple notes on use cases you've mentioned: >> > >> > yes, when a new receiver added, PMTUD to it may be performed; >> >> I think this is important as the MTU might change whenever the >> receiver set changes. In traditional multicast I would call it the >> Tree MTU. With BIER we don't have any explicit trees, so a Flow MTU >> might be a better term. >> >> > in the ECMP environment PMTUD will use the same Entropy field value as >> > the >> > flow for which the MTU to be discovered. >> >> Right. I was initially thinking that if different flows had the same >> receiver set, there was no need to probe for each of the flows, but at >> least with ECMP one would need to probe for each entropy value being >> used. The easiest is probably to just do the probing for each flow. >> >> I think it would be good to have more text in the PTMUD draft >> explaining the above. Also, some discussion about the probe frequency. >> How it is helpful to use a high frequency, but there is a trade-off (I >> think) between how quickly you need to discover a lower MTU and the >> scale (the number of flows that you need to probe). >> >> Stig >> >> > >> > Regards, >> > Greg >> > >> > On Thu, Mar 29, 2018 at 1:14 AM, Stig Venaas wrote: >> >> >> >> Hi >> >> >> >> I can certainly work on the wording. Perhaps the more important >> >> discussion, which you also brought up, is whether it is worth doing a >> >> pessimistic MTU in the sense that it is sub-domain wide, rather than a >> >> path MTU that can be more optimal. One problem with path MTU and >> >> multicast, is that it changes as the receiver set changes. For a >> >> particular (S,G) an ingress router needs to consider the path MTU >> >> towards each of the egress routers. This means that you need to >> >> discover the path MTU at least each time a new receiver is added (a >> >> new BIER bit is set) for the (S,G). Also, at any time there can be a >> >> routing change lowering the MTU, and packets would get dropped until >> >> the new path MTU is discovered. >> >> >> >> A sub-domain MTU is more pessimistic, but I think it is more robust >> >> than probing. There is less risk of packet drops (from when actual >> >> path MTU is reduced and until it is discovered by a probe), and there >> >> is no need of rediscovering path MTU each time a new receiver is >> >> added. It is also easier to implement. >> >> >> >> I'm also wondering how probing is supposed to work with ECMP. Would >> >> the ingress router need to do a new probe each time it encapsulates >> >> packets with a new entropy? >> >> >> >> Stig >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Mar 19, 2018 at 10:33 AM, Greg Mirsky >> >> wrote: >> >> > Dear Authors, et. al, >> >> > I understand the idea of aggregating MTU in the given BIER sub-domain >> >> > but >> >> > I'm concerned that if there are interfaces with significantly >> >> > different >> >> > MTUs, that the proposed approach may result in lower MTU being >> >> > enforced >> >> > on >> >> > paths capable of larger MTU. The BIER PMTUD draft does provide per >> >> > path >> >> > information. >> >> > >> >> > Regards, >> >> > Greg >> >> > >> >> > On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda >> >> > >> >> > wrote: >> >> >> >> >> >> Comments: >> >> >> >> >> >> a) " >> >> >> Every BIER router, for each sub-domain with at least >> >> >> one local BIER interface in the sub-domain, per the above >> >> >> definition >> >> >> of a BIER interface, determines the largest payload that can be >> >> >> sent >> >> >> BIER encapsulated out of any of its BIER interfaces in the sub- >> >> >> domain. >> >> >> " >> >> >> >> >> >> The language here is unclear. Is that the MIN(all used subdomain >> >> >> interface >> >> >> MTUs) ? If so, then it makes sense. >> >> >> >> >> >> b) May merit a section saying that albeit this is much >> >> >> lighter-weight >> >> >> than >> >> >> I-D.ietf-bier-path-mtu-discovery of course it can be widely >> >> >> pessimistic >> >> >> since it always picks up the smallest link in the whole subdomain >> >> >> >> >> >> c) "MTU in octets" is seriously underspecified. We have ether mtu, >> >> >> link >> >> >> mtu, interface mtu and so on. The draft should specifiy what the >> >> >> precise way >> >> >> is to advertise the "BIER MTU" here IMO ... >> >> >> >> >> >> --- tony >> >> >> >> >> >> _______________________________________________ >> >> >> BIER mailing list >> >> >> BIER@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/bier >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > BIER mailing list >> >> > BIER@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/bier >> >> > >> > >> > > > From nobody Tue May 29 11:02:47 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558D312EB3D; Tue, 29 May 2018 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 XpuemPAAwD08; Tue, 29 May 2018 11:02:43 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10F612EAAA; Tue, 29 May 2018 11:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UEWMtSgc/CUEN8gBnFqYvGASO3wovzN/2dRF04J3ZCE=; b=i1n+M+mD8SEDQV9Jz/gYLSdryHMIHai4iXQnnYliYhGv7/YVsZFpzYiBYJekietwneNxMVDzFpWoWGGqHVaIEgIzryyNNGTexp7SXzYAfp2zTmdjnj/3dF/ORqNimu60GFnjixsTnorm6oBht4/cFkDVJOzblAEGSXJ1DgpS38Q= Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com (10.168.137.146) by VI1PR0701MB2256.eurprd07.prod.outlook.com (10.169.137.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Tue, 29 May 2018 18:02:37 +0000 Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8]) by VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8%9]) with mapi id 15.20.0820.010; Tue, 29 May 2018 18:02:37 +0000 From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" To: "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Thread-Topic: draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3A== Date: Tue, 29 May 2018 18:02:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hooman.bidgoli@nokia.com; x-originating-ip: [135.245.20.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2256; 7:DTlTKaAD01ynzd1gOEZYK9+5ZBpe7niVVusmdqomk/tD0aSFdc0te1111l6WEzsgZvaWW9/2miEjS6LAIdEG6I23sYnPKCUi3CQ1UtySJ5xrpXoZJt6xJIrtkqnDPykyNoeYwRBvSOz8fSPsU0shyQAisjmBUObOTZlL8ffr7ztWACR95qtW+6gdHvdWEyUq/tuKTUx6MJGUHLce02/NcOY02svqmpVpjQxCKihPPh3S3CPmdj141glrGzIIkq1M x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:VI1PR0701MB2256; x-ms-traffictypediagnostic: VI1PR0701MB2256: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(11241501184)(806099)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2256; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2256; x-forefront-prvs: 0687389FB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(396003)(39380400002)(366004)(189003)(199004)(7736002)(4743002)(5250100002)(316002)(97736004)(33656002)(14454004)(105586002)(106356001)(86362001)(3660700001)(9686003)(478600001)(3280700002)(55016002)(6306002)(54896002)(6436002)(99286004)(2906002)(53936002)(7696005)(3846002)(5660300001)(790700001)(6116002)(450100002)(102836004)(25786009)(26005)(6506007)(476003)(81166006)(2501003)(2900100001)(81156014)(486006)(8936002)(110136005)(8676002)(186003)(66066001)(74316002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2256; H:VI1PR0701MB2351.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gFdP1QteiUZyDNlOe2JiqvhjG/yFbUn/swMqGjlsJxA/JkqLcw88Qd/9rcP0cVH2e2CegdwWOuIab4onipHyscD48rr2jD+qUekq7G3BRH1BhKh2QVNocKozOfRMuEPpvIEsLbztziSg2+hBQ7N9TASsUgs/WUeRln6VQmZCsAdxwyJ3QoN9cEDYA0GJIiOMetT6bkripyPYmEVmla3XCagGvrPLzGAUnKt2cyHRyR4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2351D2157D61560AD491A885916D0VI1PR0701MB2351_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6eb399dd-1b06-4ad1-a974-08d5c58e5c9f X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6eb399dd-1b06-4ad1-a974-08d5c58e5c9f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 18:02:37.1857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2256 Archived-At: Subject: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:02:46 -0000 --_000_VI1PR0701MB2351D2157D61560AD491A885916D0VI1PR0701MB2351_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, Chairs, et al Section 2.1. "If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAs "MUST" contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet. Should we change the "MUST" to "SHOULD" , if the reason for assigning 2 lab= els is only for detecting IPv4 vs. IPv6 then I would imagine after the labe= l pointing to the VRF, the IP header of the payload can achieve the same re= sult. Regards Hooman --_000_VI1PR0701MB2351D2157D61560AD491A885916D0VI1PR0701MB2351_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors, Chairs, et al<= /o:p>

 

Section 2.1. =

 

  &n=
bsp;   “If the two routes do not have the same Address Family Identifier
      (AFI) value, then their respective=
 PTAs “MUST” contain different
      MPLS label values.  This ensu=
res that when an egress PE receives a
 
      data packet with the given label, =
the egress PE can infer from the
      label whether the payload is an IP=
v4 packet or an IPv6 packet.

 

 

Should we change the “MUS= T” to “SHOULD” , if the reason for assigning 2 labels is = only for detecting IPv4 vs. IPv6 then I would imagine after the label point= ing to the VRF, the IP header of the payload can achieve the same result.

 

Regards

 

Hooman

 

 

--_000_VI1PR0701MB2351D2157D61560AD491A885916D0VI1PR0701MB2351_-- From nobody Tue May 29 19:29:53 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75712EBE7; Tue, 29 May 2018 19:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 rMe_yLOql3Ic; Tue, 29 May 2018 19:29:49 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DB012EBBF; Tue, 29 May 2018 19:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T512JMfgdzTgy+vwnACx6eHFRJNUihAFp0w42CzbcsE=; b=fTFsNbpKN+VG/tzjv6Jg/Ao9RHmk6x9h7DKXnP8FkxQx7m97Rp1Y4zoLACdyLS69Lf1mku1Vhp29r7OodMLc81TAcSv2/jNeH2qMVKNEXTV11Qgvtfv/nDZsBdMfxu9sYW4q/BmwXjUhCYDeGuUbFlqKCYQyWTNi3pa/4eosaTo= Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com (10.168.155.146) by AM5PR0701MB1811.eurprd07.prod.outlook.com (10.167.216.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Wed, 30 May 2018 02:29:46 +0000 Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192]) by AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192%5]) with mapi id 15.20.0820.010; Wed, 30 May 2018 02:29:45 +0000 From: "Dolganow, Andrew (Nokia - SG/Singapore)" To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Thread-Topic: draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA Date: Wed, 30 May 2018 02:29:45 +0000 Message-ID: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.dolganow@nokia.com; x-originating-ip: [131.228.32.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1811; 7:LfkejlyvsDWCG4zPBMxoeWsAlyMMi5oFWr/F0pXARscZ3cn0Fq/0lgt4X7XYTGvzkhjRiWB+mE/+RrhDx92E5Rual2j4B+CJPv2jFAEiBq+1syezAycdZZlsY6gfTLn4wRH5Pmq6U78Q+nOe5AhXFtTR7vBzUdL2HevxVjPkvVI1+STuME4475f2uf04HQkzgSCXH0dIV6ixn9Mm+rg/MS7lMthGD2rVtc4UdYSHkarfMG9VTGmA1xd3gAFHiWKr x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(39380400002)(366004)(189003)(199004)(53936002)(2501003)(5250100002)(97736004)(6512007)(6306002)(83716003)(54896002)(66066001)(3660700001)(7736002)(99286004)(446003)(2900100001)(3280700002)(14454004)(4743002)(6246003)(229853002)(82746002)(450100002)(5660300001)(110136005)(58126008)(33656002)(316002)(86362001)(26005)(6486002)(53546011)(478600001)(6506007)(2906002)(476003)(2616005)(36756003)(76176011)(6116002)(3846002)(8676002)(25786009)(81166006)(81156014)(11346002)(486006)(106356001)(102836004)(6436002)(8936002)(105586002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1811; H:AM5PR0701MB2867.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(2017052603328)(7193020); SRVR:AM5PR0701MB1811; x-ms-traffictypediagnostic: AM5PR0701MB1811: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(138986009662008)(82608151540597)(85827821059158)(109105607167333)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB1811; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB1811; x-forefront-prvs: 0688BF9B46 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8h2DB2iS96Je5rkvQ0cprpWW2uUZso4ODFsB7l8tWlaauQVqL7U4dnoVbkDMIClgWMywwWSyrzsbdqpueShv263xL+gk/bwoMWdy14BUYn5Vtl5x2PQClrDlJcmtigFyNug5JivBWEBGfBSGyaHaXn0EGwuonERuhDS6GLlpiR5nWZS/gH6TBBATdTqbaKaI2h+V3UGwpITiWgKS98w62SoOsSDlZXxOWgpDHgDrtrI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9FF3AF9F7E5A48DB9F87E8ADDAB5790Enokiacom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4960738e-979f-4c30-1253-08d5c5d5354c X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4960738e-979f-4c30-1253-08d5c5d5354c X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2018 02:29:45.4746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1811 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 02:29:52 -0000 --_000_9FF3AF9F7E5A48DB9F87E8ADDAB5790Enokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgdGhpcyBzaG91bGQgbm90IGJlIE1VU1QuDQoNCkFuZHJldw0KDQpGcm9tOiBIb29tYW4g QmlkZ29saSA8aG9vbWFuLmJpZGdvbGlAbm9raWEuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBNYXkg MzAsIDIwMTggYXQgMjowMiBBTQ0KVG86ICJkcmFmdC1pZXRmLWJpZXItbXZwbkBpZXRmLm9yZyIg PGRyYWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnPiwgQklFUiBXRyA8YmllckBpZXRmLm9yZz4s ICJiaWVyLWNoYWlyc0BpZXRmLm9yZyIgPGJpZXItY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDog ZHJhZnQtaWV0Zi1iaWVyLW12cG4NClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9y Zz4NClJlc2VudC1UbzogRXJpYyBSb3NlbiA8ZXJvc2VuQGp1bmlwZXIubmV0PiwgPG1hc2l2YWt1 QGNpc2NvLmNvbT4sIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+LCBBbmRyZXcgRG9sZ2Fub3cgPGFu ZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+LCBUb25pIFByenlnaWVuZGEgPHByekBqdW5pcGVyLm5l dD4NClJlc2VudC1EYXRlOiBXZWRuZXNkYXksIE1heSAzMCwgMjAxOCBhdCAyOjAyIEFNDQoNCkhp IEF1dGhvcnMsIENoYWlycywgZXQgYWwNCg0KU2VjdGlvbiAyLjEuDQoNCg0KICAgICAg4oCcSWYg dGhlIHR3byByb3V0ZXMgZG8gbm90IGhhdmUgdGhlIHNhbWUgQWRkcmVzcyBGYW1pbHkgSWRlbnRp Zmllcg0KDQogICAgICAoQUZJKSB2YWx1ZSwgdGhlbiB0aGVpciByZXNwZWN0aXZlIFBUQXMg4oCc TVVTVOKAnSBjb250YWluIGRpZmZlcmVudA0KDQogICAgICBNUExTIGxhYmVsIHZhbHVlcy4gIFRo aXMgZW5zdXJlcyB0aGF0IHdoZW4gYW4gZWdyZXNzIFBFIHJlY2VpdmVzIGENCg0KDQoNCiAgICAg IGRhdGEgcGFja2V0IHdpdGggdGhlIGdpdmVuIGxhYmVsLCB0aGUgZWdyZXNzIFBFIGNhbiBpbmZl ciBmcm9tIHRoZQ0KDQogICAgICBsYWJlbCB3aGV0aGVyIHRoZSBwYXlsb2FkIGlzIGFuIElQdjQg cGFja2V0IG9yIGFuIElQdjYgcGFja2V0Lg0KDQoNClNob3VsZCB3ZSBjaGFuZ2UgdGhlIOKAnE1V U1TigJ0gdG8g4oCcU0hPVUxE4oCdICwgaWYgdGhlIHJlYXNvbiBmb3IgYXNzaWduaW5nIDIgbGFi ZWxzIGlzIG9ubHkgZm9yIGRldGVjdGluZyBJUHY0IHZzLiBJUHY2IHRoZW4gSSB3b3VsZCBpbWFn aW5lIGFmdGVyIHRoZSBsYWJlbCBwb2ludGluZyB0byB0aGUgVlJGLCB0aGUgSVAgaGVhZGVyIG9m IHRoZSBwYXlsb2FkIGNhbiBhY2hpZXZlIHRoZSBzYW1lIHJlc3VsdC4NCg0KUmVnYXJkcw0KDQpI b29tYW4NCg0KDQo= --_000_9FF3AF9F7E5A48DB9F87E8ADDAB5790Enokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUNBO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5ncmV5DQoJe21zby1zdHlsZS1uYW1lOmdyZXk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFncmVlIHRoaXMgc2hvdWxkIG5vdCBiZSBNVVNU LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+SG9vbWFuIEJpZGdvbGkgJmx0O2hvb21hbi5iaWRnb2xpQG5va2lh LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXkgMzAsIDIwMTggYXQgMjow MiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7ZHJhZnQtaWV0Zi1iaWVyLW12cG5AaWV0Zi5vcmcm cXVvdDsgJmx0O2RyYWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnJmd0OywgQklFUiBXRyAmbHQ7 YmllckBpZXRmLm9yZyZndDssICZxdW90O2JpZXItY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDti aWVyLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ZHJhZnQtaWV0Zi1i aWVyLW12cG4gPGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj5FcmljIFJvc2VuICZsdDtlcm9zZW5AanVu aXBlci5uZXQmZ3Q7LCAmbHQ7bWFzaXZha3VAY2lzY28uY29tJmd0OywgJmx0O2FsZHJpbi5pZXRm QGdtYWlsLmNvbSZndDssIEFuZHJldyBEb2xnYW5vdyAmbHQ7YW5kcmV3LmRvbGdhbm93QG5va2lh LmNvbSZndDssIFRvbmkgUHJ6eWdpZW5kYSAmbHQ7cHJ6QGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxi PlJlc2VudC1EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXkgMzAsIDIwMTggYXQgMjowMiBBTTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+SGkgQXV0aG9ycywgQ2hhaXJzLCBldCBhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlv biAyLjEuIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SWYgdGhlIHR3byByb3V0ZXMgZG8gbm90IGhhdmUgdGhlIHNhbWUgQWRkcmVzcyBGYW1pbHkg SWRlbnRpZmllcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKEFGSSkg dmFsdWUsIHRoZW4gdGhlaXIgcmVzcGVjdGl2ZSBQVEFzIOKAnE1VU1TigJ0gY29udGFpbiBkaWZm ZXJlbnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMgbGFiZWwg dmFsdWVzLiZuYnNwOyBUaGlzIGVuc3VyZXMgdGhhdCB3aGVuIGFuIGVncmVzcyBQRSByZWNlaXZl cyBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZGF0YSBwYWNrZXQgd2l0aCB0aGUgZ2l2ZW4gbGFiZWwsIHRoZSBlZ3Jlc3MgUEUgY2FuIGlu ZmVyIGZyb20gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsYWJl bCB3aGV0aGVyIHRoZSBwYXlsb2FkIGlzIGFuIElQdjQgcGFja2V0IG9yIGFuIElQdjYgcGFja2V0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+U2hvdWxkIHdlIGNoYW5nZSB0aGUg4oCcTVVTVOKAnSB0byDigJxTSE9VTETigJ0gLCBpZiB0 aGUgcmVhc29uIGZvciBhc3NpZ25pbmcgMiBsYWJlbHMgaXMgb25seSBmb3IgZGV0ZWN0aW5nIElQ djQgdnMuIElQdjYgdGhlbiBJIHdvdWxkIGltYWdpbmUgYWZ0ZXIgdGhlIGxhYmVsIHBvaW50aW5n IHRvIHRoZSBWUkYsIHRoZSBJUCBoZWFkZXIgb2YNCiB0aGUgcGF5bG9hZCBjYW4gYWNoaWV2ZSB0 aGUgc2FtZSByZXN1bHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5I b29tYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9FF3AF9F7E5A48DB9F87E8ADDAB5790Enokiacom_-- From nobody Tue May 29 23:57:03 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9312D7F3; Tue, 29 May 2018 23:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 oDt6f0MdZ5AD; Tue, 29 May 2018 23:56:58 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA03D12711D; Tue, 29 May 2018 23:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2042; q=dns/txt; s=iport; t=1527663418; x=1528873018; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5v6tDVQ9/NBlp6UJ/mRkG101rgoGQo9VUKJ7DzSYlYA=; b=d07I0fWHPOBDni1wTRDt4mycSSQxp1FOgjbwewLCM3PMDS+rJ/NUy9RO QSUsivoIZP4YaG5SZjTpfBrOZYFfhas38IfEG9ufVomZfMwyzU/xfb5Zq rMMtrjvpJcF9x02FBYhhccu+8jSb2+rAkq6XNahtOYHQ4ZDZqWjd9xJKV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAQBPSQ5b/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQmbRIog3eIY4xXAQEGgSiBD4cGji0LGAuESQKCODgUAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEBAgEBASFLCwULCxEDAQIBAgImAgIhBigIBhODIgK?= =?us-ascii?q?BZwMIBQgPpTaCHIcODYEsgWMFgQmIOYEHgQ8kgmmCT0IBAYFggwAwgiQCmDg?= =?us-ascii?q?sCYtfgwGNBoo3hAGCLQIEBgUCEwGBWCGBUk0jFTsqAYIYPopShUA9MI9+AQE?= X-IronPort-AV: E=Sophos;i="5.49,459,1520899200"; d="scan'208";a="4123521" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2018 06:56:55 +0000 Received: from ams-iwijnand-88113.cisco.com (ams-iwijnand-88113.cisco.com [10.60.202.94]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w4U6utpM000831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 May 2018 06:56:55 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: IJsbrand Wijnands In-Reply-To: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> Date: Wed, 30 May 2018 08:56:54 +0200 Cc: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> To: "Dolganow, Andrew (Nokia - SG/Singapore)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 06:57:01 -0000 Hi Hooman, Andrew, Not all HW is capable (or desirable) to look at the IP header to = determine the IP version and this might also have a performance impact. = If we make it SHOULD, we might also introduce interoperability problems = where vendor A uses two labels and vendor B uses the IP header. I think we should keep this as MUST. Thx, Ice. > On 30 May 2018, at 04:29, Dolganow, Andrew (Nokia - SG/Singapore) = wrote: >=20 > Agree this should not be MUST. > =20 > Andrew > =20 > From: Hooman Bidgoli > Date: Wednesday, May 30, 2018 at 2:02 AM > To: "draft-ietf-bier-mvpn@ietf.org" , = BIER WG , "bier-chairs@ietf.org" > Subject: draft-ietf-bier-mvpn=20 > Resent-From: > Resent-To: Eric Rosen , , = , Andrew Dolganow , = Toni Przygienda > Resent-Date: Wednesday, May 30, 2018 at 2:02 AM > =20 > Hi Authors, Chairs, et al > =20 > Section 2.1.=20 > =20 > =E2=80=9CIf the two routes do not have the same Address Family = Identifier > (AFI) value, then their respective PTAs =E2=80=9CMUST=E2=80=9D = contain different > MPLS label values. This ensures that when an egress PE receives = a > =20 > data packet with the given label, the egress PE can infer from = the > label whether the payload is an IPv4 packet or an IPv6 packet. > =20 > =20 > Should we change the =E2=80=9CMUST=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D = , if the reason for assigning 2 labels is only for detecting IPv4 vs. = IPv6 then I would imagine after the label pointing to the VRF, the IP = header of the payload can achieve the same result. > =20 > Regards > =20 > Hooman > =20 > =20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Wed May 30 06:29:46 2018 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8C612DA22; Wed, 30 May 2018 06:29:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-bier-ospf-bier-extensions@ietf.org, Reshad Rahman , aretana.ietf@gmail.com, bier-chairs@ietf.org, rrahman@cisco.com, bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152768698423.27675.10805226855774164233.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2018 06:29:44 -0700 Archived-At: Subject: [Bier] Eric Rescorla's No Objection on draft-ietf-bier-ospf-bier-extensions-17: (with COMMENT) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 13:29:45 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-bier-ospf-bier-extensions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS From nobody Wed May 30 07:18:03 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E4126B72; Wed, 30 May 2018 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 T1hQNUSYFcwx; Wed, 30 May 2018 07:17:58 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0134.outbound.protection.outlook.com [104.47.2.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBFB9126CC7; Wed, 30 May 2018 07:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bIu4EsgH3l6ycavEZIzzZRhSTCfMdlc6vdpNo7xVbYo=; b=aM2T6PzexqGavyYJeVK++BXoqw1MCnlNFuYno/QobRjstnwg7XkzB7NYUWPkMb1bPspaJ22n+PJwrr808k32Dnzh3rGoMAZ0ccoH0Z9oZnVRPjVzS91D43qQgzlZKSEybB+u1G5G7wCBSC/O/Q61u7RIb+4mo9f2PnZIEqZ08D4= Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com (10.168.137.146) by VI1PR0701MB2461.eurprd07.prod.outlook.com (10.168.139.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Wed, 30 May 2018 14:17:55 +0000 Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8]) by VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8%9]) with mapi id 15.20.0820.010; Wed, 30 May 2018 14:17:54 +0000 From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" To: IJsbrand Wijnands , "Dolganow, Andrew (Nokia - SG/Singapore)" CC: "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysA== Date: Wed, 30 May 2018 14:17:54 +0000 Message-ID: References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> In-Reply-To: <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2461; 7:PgOombfrCfyKYZ8ZSpUsJKo7fzCriAYzu8vIDbfREcDXH9CxG7lapFtRlGP44BP0tiWCuP3EUynoyr1YZByJe6PK4O8JF2Nik8jqOywA7lQBtGvbnMVFDnOJSx/g9A+hmOwBZnh8B+/eMiTMDFf5Ow8OXCgrKYEE1/a6Zhkk2PT3lR84o9rSjDM1A/S1dLdXTy2DAxblC0U6SbiHcfw9gtlmmz1AJFp4S2tzMeGilAB0J4CLd0qmrdptDbdPBr4K x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(39860400002)(39380400002)(376002)(13464003)(199004)(189003)(105586002)(9686003)(6306002)(86362001)(2906002)(305945005)(106356001)(2900100001)(3660700001)(81166006)(33656002)(55016002)(81156014)(3280700002)(6436002)(476003)(229853002)(5660300001)(8676002)(11346002)(486006)(446003)(5250100002)(7736002)(478600001)(14454004)(6636002)(966005)(74316002)(97736004)(3846002)(6116002)(4326008)(102836004)(110136005)(53546011)(68736007)(99286004)(53936002)(6246003)(54906003)(6506007)(8936002)(316002)(26005)(66066001)(25786009)(76176011)(186003)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2461; H:VI1PR0701MB2351.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:VI1PR0701MB2461; x-ms-traffictypediagnostic: VI1PR0701MB2461: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hooman.bidgoli@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(85827821059158)(109105607167333)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2461; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2461; x-forefront-prvs: 0688BF9B46 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: iKzmxmzCq5IBggkWxFYn1B+ZH4lB2TdASEWmB2hPp03L3UflW+ygI0u7k98kqGjXcpH+FkWCCvYIXSMqkwdZfw+4smdRH4oi6bLWUxsdfXLD2z/w/vzThEi/G/hse+YtWOaCgkq4PE29lGZ2jul8uDccZ2QsQcb7L8d5sC4H8dWDpznaUfWIJte32jFdN8xXzhx3G/fR6OXAFuIklmIdLfew6heXlnO+Ie6+Qfy9vimLxvhr6m+OFewXWRYuVYsa spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 73578790-0a3c-448d-dc4b-08d5c63822cf X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73578790-0a3c-448d-dc4b-08d5c63822cf X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2018 14:17:54.6078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2461 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:18:02 -0000 VGhhbmtzIEljZSENCg0KSSBiZWxpZXZlIHRoZXNlIHR5cGUgb2YgbGltaXRhdGlvbnMgYXJlIG5v dCBCSUVSIHNwZWNpZmljLCBhcyBhbiBleGFtcGxlIHVuaWNhc3QgVlBOIGxhYmVsIHBlciByb3V0 ZSwgc3VibmV0IG9yIHZyZi4NCg0KSSBhbSBzdXJlIGRpZmZlcmVudCBIVyB3aWxsIGhhdmUgZGlm ZmVyZW50IGxpbWl0YXRpb25zIChpLmUuIHdoYXQgaWYgc29tZSBvZiB0aGVtIG5lZWQgbGFiZWwg cGVyIElQTUMgc3RhdGU/KS4gQmVpbmcgbmV3IHRvIHRoaXMgcHJvY2VzcyBJIGFtIG5vdCBzdXJl IGhvdyBpZXRmIGhhbmRsZXMgdGhpcyBvciBldmVuIGlmIGEgSFcgbGltaXRhdGlvbiBzaG91bGQg YWZmZWN0IGEgZHJhZnQuDQoNClRoYXQgc2FpZCBJIHRoaW5rIGZyb20gQklFUiBhbmQgbXVsdGlj YXN0IHRlY2hub2xvZ3kgcGVyc3BlY3RpdmUgcHVyZWx5LCBhc3NpZ25pbmcgMiBsYWJlbCBmb3Ig aXB2NCBhbmQgaXB2NiBhZGRyZXNzIGZhbWlseSBpcyBub3QgbmVjZXNzYXJ5LiBNYXliZSBIVyBs aW1pdGF0aW9ucyBzaG91bGQgYmUgaGFuZGxlZCBiYXNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbj8g IA0KDQpSZWdhcmRzDQoNCkhvb21hbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSUpzYnJhbmQgV2lqbmFuZHMgW21haWx0bzppY2VAY2lzY28uY29tXSANClNlbnQ6IFdlZG5l c2RheSwgTWF5IDMwLCAyMDE4IDI6NTcgQU0NClRvOiBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAt IFNHL1NpbmdhcG9yZSkgPGFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+DQpDYzogQmlkZ29saSwg SG9vbWFuIChOb2tpYSAtIENBL090dGF3YSkgPGhvb21hbi5iaWRnb2xpQG5va2lhLmNvbT47IGRy YWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnOyBCSUVSIFdHIDxiaWVyQGlldGYub3JnPjsgYmll ci1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQmllcl0gZHJhZnQtaWV0Zi1iaWVyLW12 cG4NCg0KSGkgSG9vbWFuLCBBbmRyZXcsDQoNCk5vdCBhbGwgSFcgaXMgY2FwYWJsZSAob3IgZGVz aXJhYmxlKSB0byBsb29rIGF0IHRoZSBJUCBoZWFkZXIgdG8gZGV0ZXJtaW5lIHRoZSBJUCB2ZXJz aW9uIGFuZCB0aGlzIG1pZ2h0IGFsc28gaGF2ZSBhIHBlcmZvcm1hbmNlIGltcGFjdC4gSWYgd2Ug bWFrZSBpdCBTSE9VTEQsIHdlIG1pZ2h0IGFsc28gaW50cm9kdWNlIGludGVyb3BlcmFiaWxpdHkg cHJvYmxlbXMgd2hlcmUgdmVuZG9yIEEgdXNlcyB0d28gbGFiZWxzIGFuZCB2ZW5kb3IgQiB1c2Vz IHRoZSBJUCBoZWFkZXIuDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGtlZXAgdGhpcyBhcyBNVVNULg0K DQpUaHgsDQoNCkljZS4NCg0KDQo+IE9uIDMwIE1heSAyMDE4LCBhdCAwNDoyOSwgRG9sZ2Fub3cs IEFuZHJldyAoTm9raWEgLSBTRy9TaW5nYXBvcmUpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29t PiB3cm90ZToNCj4gDQo+IEFncmVlIHRoaXMgc2hvdWxkIG5vdCBiZSBNVVNULg0KPiAgDQo+IEFu ZHJldw0KPiAgDQo+IEZyb206IEhvb21hbiBCaWRnb2xpIDxob29tYW4uYmlkZ29saUBub2tpYS5j b20+DQo+IERhdGU6IFdlZG5lc2RheSwgTWF5IDMwLCAyMDE4IGF0IDI6MDIgQU0NCj4gVG86ICJk cmFmdC1pZXRmLWJpZXItbXZwbkBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtYmllci1tdnBuQGlldGYu b3JnPiwgQklFUiBXRyA8YmllckBpZXRmLm9yZz4sICJiaWVyLWNoYWlyc0BpZXRmLm9yZyIgPGJp ZXItY2hhaXJzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBkcmFmdC1pZXRmLWJpZXItbXZwbiANCj4g UmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KPiBSZXNlbnQtVG86IEVyaWMg Um9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD4sIDxtYXNpdmFrdUBjaXNjby5jb20+LCA8YWxkcmlu LmlldGZAZ21haWwuY29tPiwgQW5kcmV3IERvbGdhbm93IDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEu Y29tPiwgVG9uaSBQcnp5Z2llbmRhIDxwcnpAanVuaXBlci5uZXQ+DQo+IFJlc2VudC1EYXRlOiBX ZWRuZXNkYXksIE1heSAzMCwgMjAxOCBhdCAyOjAyIEFNDQo+ICANCj4gSGkgQXV0aG9ycywgQ2hh aXJzLCBldCBhbA0KPiAgDQo+IFNlY3Rpb24gMi4xLiANCj4gIA0KPiAgICAgICDigJxJZiB0aGUg dHdvIHJvdXRlcyBkbyBub3QgaGF2ZSB0aGUgc2FtZSBBZGRyZXNzIEZhbWlseSBJZGVudGlmaWVy DQo+ICAgICAgIChBRkkpIHZhbHVlLCB0aGVuIHRoZWlyIHJlc3BlY3RpdmUgUFRBcyDigJxNVVNU 4oCdIGNvbnRhaW4gZGlmZmVyZW50DQo+ICAgICAgIE1QTFMgbGFiZWwgdmFsdWVzLiAgVGhpcyBl bnN1cmVzIHRoYXQgd2hlbiBhbiBlZ3Jlc3MgUEUgcmVjZWl2ZXMgYQ0KPiAgDQo+ICAgICAgIGRh dGEgcGFja2V0IHdpdGggdGhlIGdpdmVuIGxhYmVsLCB0aGUgZWdyZXNzIFBFIGNhbiBpbmZlciBm cm9tIHRoZQ0KPiAgICAgICBsYWJlbCB3aGV0aGVyIHRoZSBwYXlsb2FkIGlzIGFuIElQdjQgcGFj a2V0IG9yIGFuIElQdjYgcGFja2V0Lg0KPiAgDQo+ICANCj4gU2hvdWxkIHdlIGNoYW5nZSB0aGUg 4oCcTVVTVOKAnSB0byDigJxTSE9VTETigJ0gLCBpZiB0aGUgcmVhc29uIGZvciBhc3NpZ25pbmcg MiBsYWJlbHMgaXMgb25seSBmb3IgZGV0ZWN0aW5nIElQdjQgdnMuIElQdjYgdGhlbiBJIHdvdWxk IGltYWdpbmUgYWZ0ZXIgdGhlIGxhYmVsIHBvaW50aW5nIHRvIHRoZSBWUkYsIHRoZSBJUCBoZWFk ZXIgb2YgdGhlIHBheWxvYWQgY2FuIGFjaGlldmUgdGhlIHNhbWUgcmVzdWx0Lg0KPiAgDQo+IFJl Z2FyZHMNCj4gIA0KPiBIb29tYW4NCj4gIA0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJJRVIgbWFpbGluZyBsaXN0DQo+IEJJRVJAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQoNCg== From nobody Wed May 30 07:41:50 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAFA12EAA4; Wed, 30 May 2018 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 YHeZiBF0YMOy; Wed, 30 May 2018 07:41:46 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E145112EABF; Wed, 30 May 2018 07:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=670; q=dns/txt; s=iport; t=1527691306; x=1528900906; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LRut1pWpPKPDBkuYGCvmWPOs7ZyxrcmYQAh2674mvO4=; b=jS/EE+NnbOWqM5eaMSiE1gkV3++rClG1PEzNW6YZKTFKX/k02EiPsXmX gEnE6YRpPEPMRNw+4I/Eh6fI4Ysqz2+b0+RDHzwlbQVOIxg7fLArLeyEI O7QfkEUn+HRSg8iE2tHvV0qHzE9fwrSlCFxBQ1poSAZuhqTlIoOFS5vha A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AgAUtw5b/xbLJq1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGFExKEH4hjjEkDBQGBBx0EgQ+VNAuEbAKCPTcVAQIBAQE?= =?us-ascii?q?BAQECbCiFKQEEASNWBQsLGgImAgJXBoM1gXQFCKVEghyIRYFogQqIOYEHgQ8?= =?us-ascii?q?kDIJdhEgrgwAwgiQCmGUJjmCBLYtfjj+CLQIEBgUCEwGBVyKBUk0jFWUBghk?= =?us-ascii?q?9gWIXjhk9kEYBAQ?= X-IronPort-AV: E=Sophos;i="5.49,460,1520899200"; d="scan'208";a="4190483" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2018 14:41:43 +0000 Received: from ams-iwijnand-88113.cisco.com (ams-iwijnand-88113.cisco.com [10.60.202.94]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w4UEfhNl012717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 May 2018 14:41:43 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: IJsbrand Wijnands In-Reply-To: Date: Wed, 30 May 2018 16:41:42 +0200 Cc: "Dolganow, Andrew (Nokia - SG/Singapore)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:41:48 -0000 Hooman, > That said I think from BIER and multicast technology perspective = purely, assigning 2 label for ipv4 and ipv6 address family is not = necessary. Maybe HW limitations should be handled base on the = implementation? =20 For interoperability reasons, we should have only one way to support = this. You don=E2=80=99t want to end up in a situation where the sending = router sends the packet with the assumption that the egress router will = look at the IP header, while the egress router was expecting the label = to identify the IP version. I don=E2=80=99t see any benefit in trying to support this with a single = label value. Thx, Ice. From nobody Wed May 30 10:17:55 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937C6126CE8; Wed, 30 May 2018 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 H-gA8f1bxsy0; Wed, 30 May 2018 10:17:51 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F40C12D96C; Wed, 30 May 2018 10:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+NIBq3YIFGzE6Jtqw+X+wCwPV2q6uCofOHexgxWCy9s=; b=bsOzV6NGN8Tl3E5Uf4EzmyIeqOM7U0MAduNzV9oOwr/AKzXZcP7v+0WXMdWXcw9Z44lZYnbvG7pdTACqMZqyYoOEasczx99PG7nuyWJQHU8TfmbNRf3ylb6oM5ue5Eb3+y11K4Y1CsXXkeuUTuRIIwmfAbG/2wLwsqZL4cFLmGc= Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com (10.168.137.146) by VI1PR0701MB1951.eurprd07.prod.outlook.com (10.167.209.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Wed, 30 May 2018 17:17:47 +0000 Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8]) by VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8%9]) with mapi id 15.20.0820.010; Wed, 30 May 2018 17:17:47 +0000 From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" To: IJsbrand Wijnands CC: "Dolganow, Andrew (Nokia - SG/Singapore)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysIAA62wA///+9+A= Date: Wed, 30 May 2018 17:17:47 +0000 Message-ID: References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> In-Reply-To: <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB1951; 7:XvsKE3RPfWmBM+JutN9ISMxZ4U3EKCVpATQR09ye5iZNrCy2ua4U/gEIfQ/b7neY7ucbuh62Wcg8vzGzHyZhkB+CbUseaT9ZLMmpG5SXgJi1c6XbjRlCvtuLk5pCM67adDmAzw4K4wD6/g6PEHMOmFmJl2OI+fCj4imqIW8L7Eqx9ZTOKkiG0Pu+RPRKutfeZET94yL0m2XHQMlfUzP0dDwschtekS3rxKHRt/yV0qEOxHO79lvhn3toieU8X/0o x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(366004)(376002)(396003)(13464003)(189003)(199004)(3846002)(105586002)(6116002)(93886005)(74316002)(9686003)(2900100001)(54906003)(14454004)(2906002)(3280700002)(305945005)(106356001)(316002)(33656002)(66066001)(26005)(7736002)(5250100002)(68736007)(55016002)(4326008)(99286004)(7696005)(186003)(8936002)(97736004)(6436002)(229853002)(6506007)(53546011)(102836004)(25786009)(76176011)(3660700001)(478600001)(6246003)(6916009)(11346002)(486006)(53936002)(5660300001)(81156014)(81166006)(446003)(8676002)(476003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB1951; H:VI1PR0701MB2351.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:VI1PR0701MB1951; x-ms-traffictypediagnostic: VI1PR0701MB1951: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hooman.bidgoli@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(109105607167333)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB1951; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB1951; x-forefront-prvs: 0688BF9B46 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: U+xlqUiSbmP9ot8NwEhpjlU1eZt8qZdk5hdScUzFBy3fa2hFrSF4FXPrfcE9AJp/Sy3vwACALFwK2/HsZD2aIf+2s76XRnHsPTJroVuQVn9zJRfQsZC90WxA5/GfVE6ngr4eO6JZutTGmNJ/kC78U6etm5oFLKdulY7UD4TRRQEz7vJJw2UBTxh4DHWuccL6QRKo3IxQnQkraxbHuD67Mw6v+4yrTlyYJ9Gvg/BNPMg5X3XgGsC5xW7wZdn0j/w9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a660d5b9-e10b-4bf7-2062-08d5c65143ba X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a660d5b9-e10b-4bf7-2062-08d5c65143ba X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2018 17:17:47.2334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1951 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 17:17:54 -0000 SGkgSWNlDQoNCj4gSSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiB0cnlpbmcgdG8gc3VwcG9y dCB0aGlzIHdpdGggYSBzaW5nbGUgbGFiZWwgdmFsdWUuDQoNClRoZSBiZW5lZml0IGlzIHRoZSBz YXZpbmcgaW4gdGhlIGxhYmVsIHNwYWNlLg0KDQpSZWdhcmRzDQoNCkhvb21hbg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUpzYnJhbmQgV2lqbmFuZHMgW21haWx0bzppY2VA Y2lzY28uY29tXSANClNlbnQ6IFdlZG5lc2RheSwgTWF5IDMwLCAyMDE4IDEwOjQyIEFNDQpUbzog QmlkZ29saSwgSG9vbWFuIChOb2tpYSAtIENBL090dGF3YSkgPGhvb21hbi5iaWRnb2xpQG5va2lh LmNvbT4NCkNjOiBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHL1NpbmdhcG9yZSkgPGFuZHJl dy5kb2xnYW5vd0Bub2tpYS5jb20+OyBkcmFmdC1pZXRmLWJpZXItbXZwbkBpZXRmLm9yZzsgQklF UiBXRyA8YmllckBpZXRmLm9yZz47IGJpZXItY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0JpZXJdIGRyYWZ0LWlldGYtYmllci1tdnBuDQoNCkhvb21hbiwNCg0KPiBUaGF0IHNhaWQgSSB0 aGluayBmcm9tIEJJRVIgYW5kIG11bHRpY2FzdCB0ZWNobm9sb2d5IHBlcnNwZWN0aXZlIHB1cmVs eSwgYXNzaWduaW5nIDIgbGFiZWwgZm9yIGlwdjQgYW5kIGlwdjYgYWRkcmVzcyBmYW1pbHkgaXMg bm90IG5lY2Vzc2FyeS4gTWF5YmUgSFcgbGltaXRhdGlvbnMgc2hvdWxkIGJlIGhhbmRsZWQgYmFz ZSBvbiB0aGUgaW1wbGVtZW50YXRpb24/ICANCg0KRm9yIGludGVyb3BlcmFiaWxpdHkgcmVhc29u cywgd2Ugc2hvdWxkIGhhdmUgb25seSBvbmUgd2F5IHRvIHN1cHBvcnQgdGhpcy4gWW91IGRvbuKA mXQgd2FudCB0byBlbmQgdXAgaW4gYSBzaXR1YXRpb24gd2hlcmUgdGhlIHNlbmRpbmcgcm91dGVy IHNlbmRzIHRoZSBwYWNrZXQgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBlZ3Jlc3Mgcm91 dGVyIHdpbGwgbG9vayBhdCB0aGUgSVAgaGVhZGVyLCB3aGlsZSB0aGUgZWdyZXNzIHJvdXRlciB3 YXMgZXhwZWN0aW5nIHRoZSBsYWJlbCB0byBpZGVudGlmeSB0aGUgSVAgdmVyc2lvbi4NCg0KSSBk b27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiB0cnlpbmcgdG8gc3VwcG9ydCB0aGlzIHdpdGggYSBz aW5nbGUgbGFiZWwgdmFsdWUuDQoNClRoeCwNCg0KSWNlLg0KDQo= From nobody Wed May 30 17:10:19 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31CF12EAB5; Wed, 30 May 2018 17:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 I3HrH_Oobemq; Wed, 30 May 2018 17:10:13 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10100.outbound.protection.outlook.com [40.107.1.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3791B12EA67; Wed, 30 May 2018 17:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IA2B8h8inQzs2AvkRetdxnzOlLpKLjfe1MndunxTX4Q=; b=n+k9fulTRw06sZXiJSQVP63QP3EyWyhwKkagF0LxGn1xQ3nRweY8GLyCzJyf214O3745Y6upqttswu2xGBuBr28sP6lvrFhZjJD6qfitj77DobeaTCz9LA9V6Lip2IP794Zqj9kICNKk5MdPfY3h5plJp5Qev4JVHvIov2Os1MM= Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com (10.168.155.146) by AM5PR0701MB2307.eurprd07.prod.outlook.com (10.169.152.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Thu, 31 May 2018 00:10:10 +0000 Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192]) by AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192%5]) with mapi id 15.20.0820.010; Thu, 31 May 2018 00:10:09 +0000 From: "Dolganow, Andrew (Nokia - SG/Singapore)" To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , IJsbrand Wijnands CC: "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysIAA62wA///+9+CAAJ/buw== Date: Thu, 31 May 2018 00:10:09 +0000 Message-ID: References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.dolganow@nokia.com; x-originating-ip: [40.67.250.101] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2307; 7:qPYeDTZ5Ia+Tdhu6a1bcB64j+jKUpIELPff0kFVnteREDTGkiHxayrfvzOKzF1qOfgFQ/BLWI/7ubmxwsgcP1aetvW0xIZl8bpFe98ug1Cu4glIk6GdaheYsdub96gINhgCsATZV/V77uaCcegeT2yrzd8cE1PFSzO4IIpCFNQK5AwtQJCpkS79pbv1LuYOwWHqIuQSx61ZNjRMl9iM5rFPsejp7phvLyJkeDWPU9wGh6l4q7ML8Kg4RqDlAibgI x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(39380400002)(346002)(366004)(39860400002)(396003)(199004)(189003)(13464003)(2906002)(102836004)(99286004)(76176011)(7736002)(6506007)(3280700002)(3660700001)(53546011)(81166006)(6306002)(74316002)(53936002)(446003)(11346002)(54896002)(9686003)(8676002)(236005)(106356001)(81156014)(105586002)(3846002)(6246003)(86362001)(7696005)(5250100002)(606006)(6116002)(229853002)(5003630100001)(68736007)(316002)(33656002)(110136005)(45080400002)(2900100001)(54906003)(4326008)(66066001)(8936002)(6436002)(55016002)(486006)(186003)(476003)(97736004)(14454004)(5660300001)(478600001)(25786009)(26005)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2307; H:AM5PR0701MB2867.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:AM5PR0701MB2307; x-ms-traffictypediagnostic: AM5PR0701MB2307: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(109105607167333)(111885846020525)(95692535739014)(81439100147899)(265313219721884); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(11241501184)(806099)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2307; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2307; x-forefront-prvs: 06891E23FB received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RJefuk4jj9PrtaxVHpokWksGBHd6i7K8NYT+nutjFlsrDIenj5d5yuKEPqjvKWrwTIsdTd89UvNA70PxcOzzXCabd4T2lsUgGJ7DhGUNyTOyY4jgCTc5axY9BNauYWZx2RBqtN03nmTPCa4yCUrLTJXCZQvzYxuYvaGRNAxlRaPGcjyvOiPpszjyvhGz4BeFxiJNyQhtBaUNQUYoC/XGWhMJz0Zr2/7f+679rd5/7eAUl2+eDM6g1RHtTO1aRcue spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2867D6E79553AB90206B2C74E5630AM5PR0701MB2867_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 56a14b75-5513-48c2-538b-08d5c68adf02 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56a14b75-5513-48c2-538b-08d5c68adf02 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 00:10:09.0329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2307 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 00:10:17 -0000 --_000_AM5PR0701MB2867D6E79553AB90206B2C74E5630AM5PR0701MB2867_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ice, As Hooman said, the MUST will force duplicate labels and unnecessary ipv4 a= nd ipv6 separation. It is 2018 and time for us as industry to stop treating= ipv4 and ipv6 separate. We need to change the MUST. Even SHOULD is too str= ong to be honest. We should really say SHOULD for one label and MAY for two= and explain why 2 labels can be used. 2 labels add cost not only because of label space but also because of dupli= cation of operational and management cost. We shouod be clear on this. Regards, Andrew Sent from my iPhone Outlook _____________________________ From: Bidgoli, Hooman (Nokia - CA/Ottawa) Sent: Thursday, May 31, 2018 1:17 AM Subject: RE: [Bier] draft-ietf-bier-mvpn To: IJsbrand Wijnands Cc: Dolganow, Andrew (Nokia - SG/Singapore) , , BIER WG , Hi Ice > I don=92t see any benefit in trying to support this with a single label v= alue. The benefit is the saving in the label space. Regards Hooman -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com] Sent: Wednesday, May 30, 2018 10:42 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) Cc: Dolganow, Andrew (Nokia - SG/Singapore) ; dr= aft-ietf-bier-mvpn@ietf.org; BIER WG ; bier-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Hooman, > That said I think from BIER and multicast technology perspective purely, = assigning 2 label for ipv4 and ipv6 address family is not necessary. Maybe = HW limitations should be handled base on the implementation? For interoperability reasons, we should have only one way to support this. = You don=92t want to end up in a situation where the sending router sends th= e packet with the assumption that the egress router will look at the IP hea= der, while the egress router was expecting the label to identify the IP ver= sion. I don=92t see any benefit in trying to support this with a single label val= ue. Thx, Ice. --_000_AM5PR0701MB2867D6E79553AB90206B2C74E5630AM5PR0701MB2867_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ice,

As Hooman said, the MUST will force duplicat= e labels and unnecessary ipv4 and ipv6 separation. It is 2018 and time for = us as industry to stop treating ipv4 and ipv6 separate. We need to change t= he MUST. Even SHOULD is too strong to be honest. We should really say SHOULD for one label and MAY for two an= d explain why 2 labels can  be used. 

2 labels add cost not only because of label = space but also because of duplication of operational and management cost. W= e shouod  be clear on this. 

Regards,
Andrew
Sent from my iPhone Outlook
_____________________________
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com><= br> Sent: Thursday, May 31, 2018 1:17 AM
Subject: RE: [Bier] draft-ietf-bier-mvpn
To: IJsbrand Wijnands <ice@cisco.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com&g= t;, <draft-ietf-bier-mvpn@ietf.org>, BIER WG <bier@ietf.org>, &= lt;bier-chairs@ietf.org>


Hi Ice

> I don=92t see any benefit in trying to support this with a single labe= l value.

The benefit is the saving in the label space.

Regards

Hooman

-----Original Message-----
From: IJsbrand Wijnands [mailto:ice@cisco.com]
Sent: Wednesday, May 30, 2018 10:42 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com> Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com&g= t;; draft-ietf-bier-mvpn@ietf.org; BIER WG <bier@ietf.org>; bier-chai= rs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

Hooman,

> That said I think from BIER and multicast technology perspective purel= y, assigning 2 label for ipv4 and ipv6 address family is not necessary. May= be HW limitations should be handled base on the implementation?

For interoperability reasons, we should have only one way to support this. = You don=92t want to end up in a situation where the sending router sends th= e packet with the assumption that the egress router will look at the IP hea= der, while the egress router was expecting the label to identify the IP version.

I don=92t see any benefit in trying to support this with a single label val= ue.

Thx,

Ice.



--_000_AM5PR0701MB2867D6E79553AB90206B2C74E5630AM5PR0701MB2867_-- From nobody Wed May 30 21:25:56 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186CE12EB62; Wed, 30 May 2018 21:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GlNPqZO7js4P; Wed, 30 May 2018 21:25:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 82F5012EA7C; Wed, 30 May 2018 21:25:50 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BF7EB853EEA1E; Thu, 31 May 2018 05:25:45 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 05:25:46 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Thu, 31 May 2018 12:25:38 +0800 From: Xiejingrong To: "Dolganow, Andrew (Nokia - SG/Singapore)" , "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "IJsbrand Wijnands" CC: BIER WG , "draft-ietf-bier-mvpn@ietf.org" , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA//8+bACAAHs3AIAABqYAgAArnICAAHM3gP//NUPQ Date: Thu, 31 May 2018 04:25:38 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99A7ABEF@nkgeml514-mbx.china.huawei.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115A99A7ABEFnkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 04:25:54 -0000 --_000_16253F7987E4F346823E305D08F9115A99A7ABEFnkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, I have similar question regarding the MUST word in this draft 2.1 about the= Segmented mvpn scenario. One can see at https://www.ietf.org/mail-archive/= web/bier/current/msg02242.html. A word of 'MUST' may be necessary for a method to gain interoperation, but = not necessary or even a block for another method. Maybe a 'MUST do something when using xxxx method' can meet the concerns o= f interoperation and flexibility both. To quote RFC2119 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, Andrew (No= kia - SG/Singapore) Sent: Thursday, May 31, 2018 5:40 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) ; IJsbran= d Wijnands Cc: BIER WG ; draft-ietf-bier-mvpn@ietf.org; bier-chairs@iet= f.org Subject: Re: [Bier] draft-ietf-bier-mvpn Ice, As Hooman said, the MUST will force duplicate labels and unnecessary ipv4 a= nd ipv6 separation. It is 2018 and time for us as industry to stop treating= ipv4 and ipv6 separate. We need to change the MUST. Even SHOULD is too str= ong to be honest. We should really say SHOULD for one label and MAY for two= and explain why 2 labels can be used. 2 labels add cost not only because of label space but also because of dupli= cation of operational and management cost. We shouod be clear on this. Regards, Andrew Sent from my iPhone Outlook _____________________________ From: Bidgoli, Hooman (Nokia - CA/Ottawa) > Sent: Thursday, May 31, 2018 1:17 AM Subject: RE: [Bier] draft-ietf-bier-mvpn To: IJsbrand Wijnands > Cc: Dolganow, Andrew (Nokia - SG/Singapore) >, >, BIER WG >, = > Hi Ice > I don't see any benefit in trying to support this with a single label val= ue. The benefit is the saving in the label space. Regards Hooman -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com] Sent: Wednesday, May 30, 2018 10:42 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) > Cc: Dolganow, Andrew (Nokia - SG/Singapore) >; draft-ietf-bier-mvpn@ietf.org; BIER WG >; bi= er-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Hooman, > That said I think from BIER and multicast technology perspective purely, = assigning 2 label for ipv4 and ipv6 address family is not necessary. Maybe = HW limitations should be handled base on the implementation? For interoperability reasons, we should have only one way to support this. = You don't want to end up in a situation where the sending router sends the = packet with the assumption that the egress router will look at the IP heade= r, while the egress router was expecting the label to identify the IP versi= on. I don't see any benefit in trying to support this with a single label value= . Thx, Ice. --_000_16253F7987E4F346823E305D08F9115A99A7ABEFnkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I have similar questio= n regarding the MUST word in this draft 2.1 about the Segmented mvpn scenar= io. One can see at https://www.ietf.org/mail-archive/web/bier/current/msg02242.html.

 

A word of ‘MUST&= #8217; may be necessary for a method to gain interoperation, but not necess= ary or even a block for another method.

 

Maybe a ‘MUST do= something when using xxxx method’  can meet the concerns of int= eroperation and flexibility both.

 

To quote RFC2119<= /o:p>

6. Guidance in the use= of these Imperatives

   Imperativ= es of the type defined in this memo must be used with care

   and spari= ngly.  In particular, they MUST only be used where it is

   actually = required for interoperation or to limit behavior which has

   potential= for causing harm (e.g., limiting retransmisssions)  For

   example, = they must not be used to try to impose a particular method

   on implem= entors where the method is not required for

   interoper= ability.

 

 

From: = BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Thursday, May 31, 2018 5:40 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com= >; IJsbrand Wijnands <ice@cisco.com>
Cc: BIER WG <bier@ietf.org>; draft-ietf-bier-mvpn@ietf.org; bi= er-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

 

Ice,

 

As Hooman said, the MUST will f= orce duplicate labels and unnecessary ipv4 and ipv6 separation. It is 2018 = and time for us as industry to stop treating ipv4 and ipv6 separate. We nee= d to change the MUST. Even SHOULD is too strong to be honest. We should really say SHOULD for one label and MAY= for two and explain why 2 labels can  be used. 

 

2 labels add cost not only beca= use of label space but also because of duplication of operational and manag= ement cost. We shouod  be clear on this. 

 

Regards,

Andrew

Sent from my iPhone Outlook

= _____________________________
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Sent: Thursday, May 31, 2018 1:17 AM
Subject: RE: [Bier] draft-ietf-bier-mvpn
To: IJsbrand Wijnands <ice@cisco.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>, <draft-ietf-bier-mvpn@ietf.org>, BIER = WG <bier@ietf.org>, <bier-chairs@ietf.org>

Hi Ice

> I don’t see any benefit in trying to support this with a single = label value.

The benefit is the saving in the label space.

Regards

Hooman

-----Original Message-----
From: IJsbrand Wijnands [mailto:ice@cisco.= com]
Sent: Wednesday, May 30, 2018 10:42 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>; draft-ietf-bier-mvpn@ietf.= org; BIER WG <bier@ietf.org>= ; bier-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

Hooman,

> That said I think from BIER and multicast technology perspective purel= y, assigning 2 label for ipv4 and ipv6 address family is not necessary. May= be HW limitations should be handled base on the implementation?

For interoperability reasons, we should have only one way to support this. = You don’t want to end up in a situation where the sending router send= s the packet with the assumption that the egress router will look at the IP= header, while the egress router was expecting the label to identify the IP version.

I don’t see any benefit in trying to support this with a single label= value.

Thx,

Ice.


--_000_16253F7987E4F346823E305D08F9115A99A7ABEFnkgeml514mbxchi_-- From nobody Wed May 30 23:31:31 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB4112ECBF; Wed, 30 May 2018 23:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5yYcrm7KLk6f; Wed, 30 May 2018 23:31:27 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3164212EC78; Wed, 30 May 2018 23:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3042; q=dns/txt; s=iport; t=1527748286; x=1528957886; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yxVanBUifF37/v7UWhy/2+4F/1U6CaIBLrQkMw/dOmo=; b=Uycr3abyJgB53i25EnGNW7IRtSUY/vrQCe6rxfiEBRelbU0akbKtPcR4 B3rfFCEa1j/pA7ojZdyVRADQ3rp4SRhsV1R4QlF7s4nhjbWHXd07zBQgR ptxWmt43fY4tjylw4/UX/wlceHxW/K7Imj0WD2TqcNEdZjexWWrbOQRv+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQBulQ9b/xbLJq1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGEJm0SKIN3iGOMRwEBAQEBAQaBKIEPkzyBeAslhEcCgkA?= =?us-ascii?q?2FgECAQEBAQEBAmwcDIUoAQEBAwEjVgUHBAsRBAEBAwIjAwICRgkIBhODHgQ?= =?us-ascii?q?CgXIFCA+mJoIciEaBYwWBCog/gQeBDySCaYMRAQEDgTIrgwAwgiQCmGYJhWy?= =?us-ascii?q?IdI0MiXGEUIItAgQGBQITAYFIBisNgUVNIxVlAYIYPoFiBRKIWYVAPTCPLgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.49,463,1520899200"; d="scan'208";a="4153147" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2018 06:31:24 +0000 Received: from ams-iwijnand-88113.cisco.com (ams-iwijnand-88113.cisco.com [10.60.202.94]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4V6VNgF024006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 May 2018 06:31:23 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: IJsbrand Wijnands In-Reply-To: Date: Thu, 31 May 2018 08:31:22 +0200 Cc: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> To: "Dolganow, Andrew (Nokia - SG/Singapore)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 06:31:30 -0000 Andrew, > As Hooman said, the MUST will force duplicate labels and unnecessary = ipv4 and ipv6 separation. MUST will make sure we=E2=80=99ll end up with interoperable = implementations, and there is a need to treat IPv4 and IPv6 differently. > It is 2018 and time for us as industry to stop treating ipv4 and ipv6 = separate. That is a non-argument. > We need to change the MUST. Even SHOULD is too strong to be honest. We = should really say SHOULD for one label and MAY for two and explain why 2 = labels can be used.=20 >=20 > 2 labels add cost not only because of label space but also because of = duplication of operational and management cost. We shouod be clear on = this.=20 Each PE has 1M labels to its disposal, there is no shortage of labels in = this case. If you want to scale down the number of labels in the MPLS FIB on the = egress, checkout = https://tools.ietf.org/html/draft-zzhang-bess-mvpn-evpn-aggregation-label-= 01 This drafts proposes to use a global labels for the disposition, such = that there is no per PE MPLS state. You=E2=80=99ll end up with the = number of labels equal to the number of VPN=E2=80=99s, times 2 if both = IPv4 and IPv6 are enabled. Not an issue. Thx, Ice. >=20 > Regards, > Andrew > Sent from my iPhone Outlook > _____________________________ > From: Bidgoli, Hooman (Nokia - CA/Ottawa) > Sent: Thursday, May 31, 2018 1:17 AM > Subject: RE: [Bier] draft-ietf-bier-mvpn > To: IJsbrand Wijnands > Cc: Dolganow, Andrew (Nokia - SG/Singapore) = , , BIER WG = , >=20 >=20 > Hi Ice >=20 > > I don=E2=80=99t see any benefit in trying to support this with a = single label value. >=20 > The benefit is the saving in the label space. >=20 > Regards >=20 > Hooman >=20 > -----Original Message----- > From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 > Sent: Wednesday, May 30, 2018 10:42 AM > To: Bidgoli, Hooman (Nokia - CA/Ottawa) > Cc: Dolganow, Andrew (Nokia - SG/Singapore) = ; draft-ietf-bier-mvpn@ietf.org; BIER WG = ; bier-chairs@ietf.org > Subject: Re: [Bier] draft-ietf-bier-mvpn >=20 > Hooman, >=20 > > That said I think from BIER and multicast technology perspective = purely, assigning 2 label for ipv4 and ipv6 address family is not = necessary. Maybe HW limitations should be handled base on the = implementation?=20 >=20 > For interoperability reasons, we should have only one way to support = this. You don=E2=80=99t want to end up in a situation where the sending = router sends the packet with the assumption that the egress router will = look at the IP header, while the egress router was expecting the label = to identify the IP version. >=20 > I don=E2=80=99t see any benefit in trying to support this with a = single label value. >=20 > Thx, >=20 > Ice. >=20 >=20 >=20 From nobody Wed May 30 23:51:49 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BFB12EBBE; Wed, 30 May 2018 23:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 fTdco0w-u-1H; Wed, 30 May 2018 23:51:44 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50126.outbound.protection.outlook.com [40.107.5.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694D012E03C; Wed, 30 May 2018 23:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QI5AJOsS5TrnqL1UanvoozwTLqzuXnCUI8rS3WHNY4U=; b=ntCI6rhzQpdqeRn165hAMHHCw4X+TuBuks7r3ikwXqrR+vYfIcLvcY3ZmZhvPN1i9cN/HGIchphyMjiCVUaRWBb1rtWdoOuLSuuP7Q4zhZe9Zbc/1ldFpb8c894wV0C/NkKXbZPLvsi7VuNaQvoGMyBEsS0GAbtFfA7vJiTAIG0= Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com (10.168.155.146) by AM5PR0701MB1795.eurprd07.prod.outlook.com (10.167.215.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Thu, 31 May 2018 06:51:40 +0000 Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192]) by AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192%5]) with mapi id 15.20.0820.010; Thu, 31 May 2018 06:51:39 +0000 From: "Dolganow, Andrew (Nokia - SG/Singapore)" To: IJsbrand Wijnands CC: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysIAA62wA///+9+CAAJ/bu4AAaoMAgACLvoA= Date: Thu, 31 May 2018 06:51:39 +0000 Message-ID: <7DC441DE-7951-413E-920E-76B565877605@nokia.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> In-Reply-To: <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [131.228.32.172] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1795; 7:XCoSGCeaMFSZ2h2ExhpCH3/9UBOWZ8W4TLW3ajsSzlegFmzmaXU9a09W3DYelxWWFJcidQYVcJhmAfeFBg1vO2aheRV1NDQMGY0lJY/c+9898CZXGUy1BaquaCdCBCZjGQqMOrfeLkctfhusbuqOXtFhmU0HwwGSGSP398OMwKBab6LGlOog8cKLqyf9+5vgooMr4j2exwcM0RbeuONj/xou8CsaEDoqK3DUOwoTSY4I3vzHcWt1Sic6vtVyKLko x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39380400002)(39860400002)(346002)(13464003)(199004)(189003)(5660300001)(8936002)(54906003)(316002)(33656002)(966005)(76176011)(14454004)(6512007)(81166006)(58126008)(8676002)(81156014)(6306002)(99286004)(93886005)(68736007)(3660700001)(2906002)(97736004)(6116002)(6436002)(2900100001)(6486002)(478600001)(3846002)(106356001)(102836004)(229853002)(25786009)(105586002)(82746002)(6916009)(3280700002)(5250100002)(4326008)(476003)(86362001)(486006)(36756003)(2616005)(7736002)(186003)(5003630100001)(446003)(83716003)(6506007)(26005)(6246003)(305945005)(53936002)(66066001)(45080400002)(53546011)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1795; H:AM5PR0701MB2867.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:AM5PR0701MB1795; x-ms-traffictypediagnostic: AM5PR0701MB1795: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.dolganow@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(85827821059158)(109105607167333)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB1795; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB1795; x-forefront-prvs: 06891E23FB received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gkl1mbSG+RYpqW/KoVTlsxALDgwrmjxbgLWMBTLrHJ3zT34tAZ2Ab+z3XJPfs2l7QukuT2f/P7ML/XruLnN1Mmo8DKdj1Pcb6jYHIONabCPc3NsUb1mxHY/lyknZuX6cbblnQ73b6V/wWhB5LHiwBYIRPWA+8jCIL9bH55h2j9On3da73r8GTBm7E/kDe8fvY5M04W8LriN3AmQeu6S+R29sY5lwicR4ZFCzCMI+CzRCnHM1UXWFR4n/DGxWhL8W spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2F0B2E9536D90A488B3849E633E537D9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 59d54b04-5c12-4835-c93c-08d5c6c2f613 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59d54b04-5c12-4835-c93c-08d5c6c2f613 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 06:51:39.6209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1795 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 06:51:47 -0000 SWNlLA0KDQpXZSBkbyBub3Qgd2FudCBub3IgbmVlZCB0byBoYXZlIHNlcGFyYXRlIGxhYmVsIGZv ciBJUHY0IGFuZCBJUHY2LiBUaGUgY3VycmVudCBkcmFmdCBmb3JjZXMgdGhhdCBhbmQgd2UgdGhp bmsgdGhpcyBpcyBub3QgZGVzaXJlZCBhbmQgZm9yIHN1cmUgbm90IG5lY2Vzc2FyeS4gSSBhbSBo YXBweSB0byBzcGVsbCBvdXQgb3B0aW9ucyBpbiBhIGRyYWZ0IHRvIGVpdGhlciB1c2Ugb25lIG9y IHR3byBsYWJlbHMgYW5kIHNheSB3aGF0IGVhY2ggd2lsbCBhbGxvdy9jb3N0IGJ1dCB3ZSBjYW5u b3QgYWNjZXB0IGEgc29sdXRpb24gdGhhdCBmb3JjZXMgc2VwYXJhdGUgbGFiZWxzIGFzIHRoaXMg aXMgbm90IGEgY29tbW9uIGNhc2Ugd2UgYXJlIGJlaW5nIGFza2VkIGJ5IGN1c3RvbWVycyB0byBh ZGRyZXNzLg0KDQpBbmRyZXcNCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogIihJY2UpIElKc2JyYW5kIFdpam5hbmRzIiA8aWNlQGNpc2NvLmNvbT4NCkRhdGU6IFRodXJz ZGF5LCBNYXkgMzEsIDIwMTggYXQgMjozMSBQTQ0KVG86IEFuZHJldyBEb2xnYW5vdyA8YW5kcmV3 LmRvbGdhbm93QG5va2lhLmNvbT4NCkNjOiBIb29tYW4gQmlkZ29saSA8aG9vbWFuLmJpZGdvbGlA bm9raWEuY29tPiwgImRyYWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1i aWVyLW12cG5AaWV0Zi5vcmc+LCBCSUVSIFdHIDxiaWVyQGlldGYub3JnPiwgImJpZXItY2hhaXJz QGlldGYub3JnIiA8Ymllci1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0JpZXJdIGRy YWZ0LWlldGYtYmllci1tdnBuDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+ DQpSZXNlbnQtVG86IEVyaWMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD4sIDxtYXNpdmFrdUBj aXNjby5jb20+LCA8YWxkcmluLmlldGZAZ21haWwuY29tPiwgQW5kcmV3IERvbGdhbm93IDxhbmRy ZXcuZG9sZ2Fub3dAbm9raWEuY29tPiwgVG9uaSBQcnp5Z2llbmRhIDxwcnpAanVuaXBlci5uZXQ+ DQpSZXNlbnQtRGF0ZTogVGh1cnNkYXksIE1heSAzMSwgMjAxOCBhdCAyOjMxIFBNDQoNCiAgICBB bmRyZXcsDQogICAgDQogICAgPiBBcyBIb29tYW4gc2FpZCwgdGhlIE1VU1Qgd2lsbCBmb3JjZSBk dXBsaWNhdGUgbGFiZWxzIGFuZCB1bm5lY2Vzc2FyeSBpcHY0IGFuZCBpcHY2IHNlcGFyYXRpb24u DQogICAgDQogICAgTVVTVCB3aWxsIG1ha2Ugc3VyZSB3ZeKAmWxsIGVuZCB1cCB3aXRoIGludGVy b3BlcmFibGUgaW1wbGVtZW50YXRpb25zLCBhbmQgdGhlcmUgaXMgYSBuZWVkIHRvIHRyZWF0IElQ djQgYW5kIElQdjYgZGlmZmVyZW50bHkuDQogICAgDQogICAgPiBJdCBpcyAyMDE4IGFuZCB0aW1l IGZvciB1cyBhcyBpbmR1c3RyeSB0byBzdG9wIHRyZWF0aW5nIGlwdjQgYW5kIGlwdjYgc2VwYXJh dGUuDQogICAgDQogICAgVGhhdCBpcyBhIG5vbi1hcmd1bWVudC4NCiAgICANCiAgICA+IFdlIG5l ZWQgdG8gY2hhbmdlIHRoZSBNVVNULiBFdmVuIFNIT1VMRCBpcyB0b28gc3Ryb25nIHRvIGJlIGhv bmVzdC4gV2Ugc2hvdWxkIHJlYWxseSBzYXkgU0hPVUxEIGZvciBvbmUgbGFiZWwgYW5kIE1BWSBm b3IgdHdvIGFuZCBleHBsYWluIHdoeSAyIGxhYmVscyBjYW4gIGJlIHVzZWQuIA0KICAgID4gDQog ICAgPiAyIGxhYmVscyBhZGQgY29zdCBub3Qgb25seSBiZWNhdXNlIG9mIGxhYmVsIHNwYWNlIGJ1 dCBhbHNvIGJlY2F1c2Ugb2YgZHVwbGljYXRpb24gb2Ygb3BlcmF0aW9uYWwgYW5kIG1hbmFnZW1l bnQgY29zdC4gV2Ugc2hvdW9kICBiZSBjbGVhciBvbiB0aGlzLiANCiAgICANCiAgICBFYWNoIFBF IGhhcyAxTSBsYWJlbHMgdG8gaXRzIGRpc3Bvc2FsLCB0aGVyZSBpcyBubyBzaG9ydGFnZSBvZiBs YWJlbHMgaW4gdGhpcyBjYXNlLg0KICAgIA0KICAgIElmIHlvdSB3YW50IHRvIHNjYWxlIGRvd24g dGhlIG51bWJlciBvZiBsYWJlbHMgaW4gdGhlIE1QTFMgRklCIG9uIHRoZSBlZ3Jlc3MsIGNoZWNr b3V0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16emhhbmctYmVzcy1tdnBuLWV2 cG4tYWdncmVnYXRpb24tbGFiZWwtMDEgVGhpcyBkcmFmdHMgcHJvcG9zZXMgdG8gdXNlIGEgZ2xv YmFsIGxhYmVscyBmb3IgdGhlIGRpc3Bvc2l0aW9uLCBzdWNoIHRoYXQgdGhlcmUgaXMgbm8gcGVy IFBFIE1QTFMgc3RhdGUuIFlvdeKAmWxsIGVuZCB1cCB3aXRoIHRoZSBudW1iZXIgb2YgbGFiZWxz IGVxdWFsIHRvIHRoZSBudW1iZXIgb2YgVlBO4oCZcywgdGltZXMgMiBpZiBib3RoIElQdjQgYW5k IElQdjYgYXJlIGVuYWJsZWQuIE5vdCBhbiBpc3N1ZS4NCiAgICANCiAgICBUaHgsDQogICAgDQog ICAgSWNlLg0KICAgIA0KICAgID4gDQogICAgPiBSZWdhcmRzLA0KICAgID4gQW5kcmV3DQogICAg PiBTZW50IGZyb20gbXkgaVBob25lIE91dGxvb2sNCiAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgPiBGcm9tOiBCaWRnb2xpLCBIb29tYW4gKE5va2lhIC0gQ0EvT3R0YXdh KSA8aG9vbWFuLmJpZGdvbGlAbm9raWEuY29tPg0KICAgID4gU2VudDogVGh1cnNkYXksIE1heSAz MSwgMjAxOCAxOjE3IEFNDQogICAgPiBTdWJqZWN0OiBSRTogW0JpZXJdIGRyYWZ0LWlldGYtYmll ci1tdnBuDQogICAgPiBUbzogSUpzYnJhbmQgV2lqbmFuZHMgPGljZUBjaXNjby5jb20+DQogICAg PiBDYzogRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRy9TaW5nYXBvcmUpIDxhbmRyZXcuZG9s Z2Fub3dAbm9raWEuY29tPiwgPGRyYWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnPiwgQklFUiBX RyA8YmllckBpZXRmLm9yZz4sIDxiaWVyLWNoYWlyc0BpZXRmLm9yZz4NCiAgICA+IA0KICAgID4g DQogICAgPiBIaSBJY2UNCiAgICA+IA0KICAgID4gPiBJIGRvbuKAmXQgc2VlIGFueSBiZW5lZml0 IGluIHRyeWluZyB0byBzdXBwb3J0IHRoaXMgd2l0aCBhIHNpbmdsZSBsYWJlbCB2YWx1ZS4NCiAg ICA+IA0KICAgID4gVGhlIGJlbmVmaXQgaXMgdGhlIHNhdmluZyBpbiB0aGUgbGFiZWwgc3BhY2Uu DQogICAgPiANCiAgICA+IFJlZ2FyZHMNCiAgICA+IA0KICAgID4gSG9vbWFuDQogICAgPiANCiAg ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBJSnNicmFuZCBXaWpu YW5kcyBbbWFpbHRvOmljZUBjaXNjby5jb21dIA0KICAgID4gU2VudDogV2VkbmVzZGF5LCBNYXkg MzAsIDIwMTggMTA6NDIgQU0NCiAgICA+IFRvOiBCaWRnb2xpLCBIb29tYW4gKE5va2lhIC0gQ0Ev T3R0YXdhKSA8aG9vbWFuLmJpZGdvbGlAbm9raWEuY29tPg0KICAgID4gQ2M6IERvbGdhbm93LCBB bmRyZXcgKE5va2lhIC0gU0cvU2luZ2Fwb3JlKSA8YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbT47 IGRyYWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnOyBCSUVSIFdHIDxiaWVyQGlldGYub3JnPjsg Ymllci1jaGFpcnNAaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IFJlOiBbQmllcl0gZHJhZnQtaWV0 Zi1iaWVyLW12cG4NCiAgICA+IA0KICAgID4gSG9vbWFuLA0KICAgID4gDQogICAgPiA+IFRoYXQg c2FpZCBJIHRoaW5rIGZyb20gQklFUiBhbmQgbXVsdGljYXN0IHRlY2hub2xvZ3kgcGVyc3BlY3Rp dmUgcHVyZWx5LCBhc3NpZ25pbmcgMiBsYWJlbCBmb3IgaXB2NCBhbmQgaXB2NiBhZGRyZXNzIGZh bWlseSBpcyBub3QgbmVjZXNzYXJ5LiBNYXliZSBIVyBsaW1pdGF0aW9ucyBzaG91bGQgYmUgaGFu ZGxlZCBiYXNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbj8gDQogICAgPiANCiAgICA+IEZvciBpbnRl cm9wZXJhYmlsaXR5IHJlYXNvbnMsIHdlIHNob3VsZCBoYXZlIG9ubHkgb25lIHdheSB0byBzdXBw b3J0IHRoaXMuIFlvdSBkb27igJl0IHdhbnQgdG8gZW5kIHVwIGluIGEgc2l0dWF0aW9uIHdoZXJl IHRoZSBzZW5kaW5nIHJvdXRlciBzZW5kcyB0aGUgcGFja2V0IHdpdGggdGhlIGFzc3VtcHRpb24g dGhhdCB0aGUgZWdyZXNzIHJvdXRlciB3aWxsIGxvb2sgYXQgdGhlIElQIGhlYWRlciwgd2hpbGUg dGhlIGVncmVzcyByb3V0ZXIgd2FzIGV4cGVjdGluZyB0aGUgbGFiZWwgdG8gaWRlbnRpZnkgdGhl IElQIHZlcnNpb24uDQogICAgPiANCiAgICA+IEkgZG9u4oCZdCBzZWUgYW55IGJlbmVmaXQgaW4g dHJ5aW5nIHRvIHN1cHBvcnQgdGhpcyB3aXRoIGEgc2luZ2xlIGxhYmVsIHZhbHVlLg0KICAgID4g DQogICAgPiBUaHgsDQogICAgPiANCiAgICA+IEljZS4NCiAgICA+IA0KICAgID4gDQogICAgPiAN CiAgICANCiAgICANCg0K From nobody Thu May 31 00:26:05 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D507F12F299; Thu, 31 May 2018 00:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 LXy2U7SBZV8J; Thu, 31 May 2018 00:26:00 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04F812F27C; Thu, 31 May 2018 00:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4567; q=dns/txt; s=iport; t=1527751560; x=1528961160; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KxrYEl8UAp9fnExYfifY/8OvZDbAJLhj1Eny9CBdbvg=; b=Zzdyg7rNLioM21oQnKnyIMrHguaKr3JdcBZmuGL+7byYXeDiuiYF/SsF HWZi3S8u+quU3koRvLgsFtOBUZiWFGuqW/POCr0PTpq2cUrWz+kp3rG6k NsLS5SErvcvQHrGX0T4cWjqhglXjSK2HkhLrPUELgGxSZ/n55Sg+Snxwk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQAwow9b/xbLJq1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDFYERbRIog3eIY4xHAQEBAQEBBoEogQ+HB44tCyWERwK?= =?us-ascii?q?CQTgUAQIBAQEBAQECbBwMhSgBAQEDASNWBQcECxEDAQEBAQICIwMCAiElCQg?= =?us-ascii?q?GExuDAwQCgWcDCAUID6Y6ghyHDQ2BLIFjBYEKiD+BB4EPJIJpgk9CAQEDgTI?= =?us-ascii?q?rgwAwgiQCmDosCYVshXODAY0MiXFKhAaCLQIEBgUCEwGBWCENgUVNIxVlAYI?= =?us-ascii?q?YPoFiBRKIWYVAPTCPLgEB?= X-IronPort-AV: E=Sophos;i="5.49,463,1520899200"; d="scan'208";a="4154149" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2018 07:25:57 +0000 Received: from ams-iwijnand-88113.cisco.com (ams-iwijnand-88113.cisco.com [10.60.202.94]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4V7PuLn004479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 May 2018 07:25:57 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: IJsbrand Wijnands In-Reply-To: <7DC441DE-7951-413E-920E-76B565877605@nokia.com> Date: Thu, 31 May 2018 09:25:56 +0200 Cc: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9458EAEB-B1D7-4B12-ABAA-A44AC23B554D@cisco.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> <7DC441DE-7951-413E-920E-76B565877605@nokia.com> To: "Dolganow, Andrew (Nokia - SG/Singapore)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 07:26:03 -0000 Andrew, Can you explain a little more about the problem customers are asking you = to solve? Thx, Ice. > On 31 May 2018, at 08:51, Dolganow, Andrew (Nokia - SG/Singapore) = wrote: >=20 > Ice, >=20 > We do not want nor need to have separate label for IPv4 and IPv6. The = current draft forces that and we think this is not desired and for sure = not necessary. I am happy to spell out options in a draft to either use = one or two labels and say what each will allow/cost but we cannot accept = a solution that forces separate labels as this is not a common case we = are being asked by customers to address. >=20 > Andrew >=20 >=20 > =EF=BB=BF-----Original Message----- > From: "(Ice) IJsbrand Wijnands" > Date: Thursday, May 31, 2018 at 2:31 PM > To: Andrew Dolganow > Cc: Hooman Bidgoli , = "draft-ietf-bier-mvpn@ietf.org" , BIER WG = , "bier-chairs@ietf.org" > Subject: Re: [Bier] draft-ietf-bier-mvpn > Resent-From: > Resent-To: Eric Rosen , , = , Andrew Dolganow , = Toni Przygienda > Resent-Date: Thursday, May 31, 2018 at 2:31 PM >=20 > Andrew, >=20 >> As Hooman said, the MUST will force duplicate labels and unnecessary = ipv4 and ipv6 separation. >=20 > MUST will make sure we=E2=80=99ll end up with interoperable = implementations, and there is a need to treat IPv4 and IPv6 differently. >=20 >> It is 2018 and time for us as industry to stop treating ipv4 and ipv6 = separate. >=20 > That is a non-argument. >=20 >> We need to change the MUST. Even SHOULD is too strong to be honest. = We should really say SHOULD for one label and MAY for two and explain = why 2 labels can be used.=20 >>=20 >> 2 labels add cost not only because of label space but also because of = duplication of operational and management cost. We shouod be clear on = this.=20 >=20 > Each PE has 1M labels to its disposal, there is no shortage of = labels in this case. >=20 > If you want to scale down the number of labels in the MPLS FIB on = the egress, checkout = https://tools.ietf.org/html/draft-zzhang-bess-mvpn-evpn-aggregation-label-= 01 This drafts proposes to use a global labels for the disposition, such = that there is no per PE MPLS state. You=E2=80=99ll end up with the = number of labels equal to the number of VPN=E2=80=99s, times 2 if both = IPv4 and IPv6 are enabled. Not an issue. >=20 > Thx, >=20 > Ice. >=20 >>=20 >> Regards, >> Andrew >> Sent from my iPhone Outlook >> _____________________________ >> From: Bidgoli, Hooman (Nokia - CA/Ottawa) >> Sent: Thursday, May 31, 2018 1:17 AM >> Subject: RE: [Bier] draft-ietf-bier-mvpn >> To: IJsbrand Wijnands >> Cc: Dolganow, Andrew (Nokia - SG/Singapore) = , , BIER WG = , >>=20 >>=20 >> Hi Ice >>=20 >>> I don=E2=80=99t see any benefit in trying to support this with a = single label value. >>=20 >> The benefit is the saving in the label space. >>=20 >> Regards >>=20 >> Hooman >>=20 >> -----Original Message----- >> From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 >> Sent: Wednesday, May 30, 2018 10:42 AM >> To: Bidgoli, Hooman (Nokia - CA/Ottawa) >> Cc: Dolganow, Andrew (Nokia - SG/Singapore) = ; draft-ietf-bier-mvpn@ietf.org; BIER WG = ; bier-chairs@ietf.org >> Subject: Re: [Bier] draft-ietf-bier-mvpn >>=20 >> Hooman, >>=20 >>> That said I think from BIER and multicast technology perspective = purely, assigning 2 label for ipv4 and ipv6 address family is not = necessary. Maybe HW limitations should be handled base on the = implementation?=20 >>=20 >> For interoperability reasons, we should have only one way to support = this. You don=E2=80=99t want to end up in a situation where the sending = router sends the packet with the assumption that the egress router will = look at the IP header, while the egress router was expecting the label = to identify the IP version. >>=20 >> I don=E2=80=99t see any benefit in trying to support this with a = single label value. >>=20 >> Thx, >>=20 >> Ice. >>=20 >>=20 >>=20 >=20 >=20 >=20 From nobody Thu May 31 06:29:27 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4558412E887; Thu, 31 May 2018 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 dYktXKfJtvko; Thu, 31 May 2018 06:29:16 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 261CC12EADE; Thu, 31 May 2018 06:29:15 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4VDSb7W014327; Thu, 31 May 2018 06:29:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=5livyobalpLEQIlvwNewEVgP3Itan2fBKIBdLsJwaFQ=; b=z8xBsoImliSdFb+JiEjE1DwXWcH4sbbMJ3lahxkJ7/9Jfb+ro2AvclwaAoAKpmfQEbO8 JJcr0a7N5agjUJMPPXgFC/87COby/wIQkbg4RrTQ2r5A3Bg7gyroi7QD8qCl35t6XUao MO9MTGcWmrYbyQ/1A0bx5/XQG1Km23xMf3W5iKKbJn1nKotYmSQpUt8tZxPKcYWSF3Fs Tpp6P23ak/6D4JDA5Yyz0jumpaDbX7F9ljImuekCei3ov1315xzf1+Pw4kapKZ+pXs/2 BrvHFnyCN/iVR1xgrGOX3QqLn57Zq1wjkBWajFSth2Nsxxpwp7NG27oWQ2B18JyG6ugW pQ== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0022.outbound.protection.outlook.com [216.32.181.22]) by mx0b-00273201.pphosted.com with ESMTP id 2jacnmgfxd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 May 2018 06:29:08 -0700 Received: from BN3PR05MB2642.namprd05.prod.outlook.com (10.166.72.18) by BN6SPR00MB245.namprd05.prod.outlook.com (10.168.230.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Thu, 31 May 2018 13:29:05 +0000 Received: from BN3PR05MB2642.namprd05.prod.outlook.com ([fe80::cda1:8355:9f97:ed82]) by BN3PR05MB2642.namprd05.prod.outlook.com ([fe80::cda1:8355:9f97:ed82%6]) with mapi id 15.20.0820.010; Thu, 31 May 2018 13:29:05 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Xiejingrong , "Dolganow, Andrew (Nokia - SG/Singapore)" , "Bidgoli, Hooman (Nokia - CA/Ottawa)" , IJsbrand Wijnands CC: BIER WG , "draft-ietf-bier-mvpn@ietf.org" , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysIAA62wA///+9+CAAJ/bu4AAR2IA//9rrDA= Date: Thu, 31 May 2018 13:29:05 +0000 Message-ID: References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com>, <16253F7987E4F346823E305D08F9115A99A7ABEF@nkgeml514-mbx.china.huawei.com> In-Reply-To: <16253F7987E4F346823E305D08F9115A99A7ABEF@nkgeml514-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.300.84 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6SPR00MB245; 7:Z+nMBs6uypO7C4IFVwuLJjWPviP9txUqatBHoe3WVxW4SojcCYeu22Eo81jABgG7oPocXRC+P/I0m7FHevuhFbmdADSSJlLGeU8YC/OBFljMjRy0D1xg/ITOtKipeJt4F+i7L/kesPsHZBJ21ffXAqfDwIdNldErE/M5XzzTrQsMDcFJvb2AXSLnP9p6dUycUIaUNoFVR/LeuwcRiUiyZBqzMkEnIQa5iNJsU0DnrkYxttqVl44PpBSq0vOAqEhQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6SPR00MB245; x-ms-traffictypediagnostic: BN6SPR00MB245: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(82608151540597)(109105607167333)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN6SPR00MB245; BCL:0; PCL:0; RULEID:; SRVR:BN6SPR00MB245; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39380400002)(39860400002)(13464003)(199004)(189003)(68736007)(606006)(45080400002)(2900100001)(81166006)(476003)(486006)(5660300001)(11346002)(446003)(59450400001)(86362001)(53546011)(6506007)(99286004)(5003630100001)(8676002)(102836004)(478600001)(26005)(186003)(7696005)(81156014)(76176011)(14454004)(966005)(5250100002)(3660700001)(9326002)(74316002)(2906002)(93886005)(7736002)(8936002)(110136005)(53936002)(16200700003)(53946003)(236005)(54906003)(9686003)(6306002)(54896002)(66066001)(106356001)(105586002)(55016002)(316002)(8656006)(33656002)(4326008)(6246003)(3846002)(97736004)(25786009)(6436002)(6116002)(3280700002)(790700001)(229853002)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6SPR00MB245; H:BN3PR05MB2642.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: diaFntq5PxW6hSVCfqcX+4qnJ5msDo6g80zDU+H4/BTOzyGTmZ/ZSpU9HNm1KCoht6aXEWYtb6qqaajD6f5yvji2lvLPK7Y8DCXH4JcdVxUXpbNXzf6o++jmeyyQF8OeXArmupxh6GjOxKri5qdBooU13DboajeCzE8cEDJTmAPV6TvXlAm6wbOwSCJ6JKp9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR05MB2642E843A26C7FA5644A4625D4630BN3PR05MB2642namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 31c5ab70-491b-40bc-72c5-08d5c6fa7b4c X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 31c5ab70-491b-40bc-72c5-08d5c6fa7b4c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 13:29:05.4633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6SPR00MB245 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805310154 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 13:29:26 -0000 --_000_BN3PR05MB2642E843A26C7FA5644A4625D4630BN3PR05MB2642namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jingrong, I also have the following in https://tools.ietf.org/html/draft-zzhang-bess-= mvpn-evpn-aggregation-label-01: 2.2.2.3. Alternative to the per-PMSI Label Allocation The per-PMSI label allocation in case of segmentation, whether for S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to be able to label switch traffic w/o having to do IP or MAC lookup in VRFs (the segmentation points typically do not have those VRFs at all). If the label scaling becomes a concern, altertatively the segmenation points could use (C-S,C-G) lookup in VRFs for flows identifyed by the S-PMSIs. This allows the S-PMSIs for the same VPN/ BD to share the a VPN/BD-identifying label that leads to lookup in the VRFs. That label should be different from the label used in the per-PE/region I-PMSIs though, so that the segmentation points can label switch other traffic (not identified by those S-PMSIs). However, this moves the scaling problem from the number of labels to the number of (C-S/*,C-G) routes in VRFs on the segmentation points. I did not realized that you had the following in your email: =D8 Also I have submitted a new draft to describe why it is important and = valuable to use an alternative forwarding procedure in segmented MVPN, by u= sing IP lookup instead of requiring Per-Flow Labels. I will add an informative reference to your draft next time when I update m= y draft. I agree with you that for the particular issue of the "MUST" wording in dra= ft-ietf-bier-mvpn, it can stay MUST because the assumption is that segmenta= tion points do label switching. I have not read about the use case that Hoo= man/Adnrew have. Jeffrey From: BIER On Behalf Of Xiejingrong Sent: Thursday, May 31, 2018 12:26 AM To: Dolganow, Andrew (Nokia - SG/Singapore) ; Bi= dgoli, Hooman (Nokia - CA/Ottawa) ; IJsbrand Wijn= ands Cc: BIER WG ; draft-ietf-bier-mvpn@ietf.org; bier-chairs@iet= f.org Subject: Re: [Bier] draft-ietf-bier-mvpn Hi folks, I have similar question regarding the MUST word in this draft 2.1 about the= Segmented mvpn scenario. One can see at https://www.ietf.org/mail-archive/= web/bier/current/msg02242.html. A word of 'MUST' may be necessary for a method to gain interoperation, but = not necessary or even a block for another method. Maybe a 'MUST do something when using xxxx method' can meet the concerns o= f interoperation and flexibility both. To quote RFC2119 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, Andrew (No= kia - SG/Singapore) Sent: Thursday, May 31, 2018 5:40 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) >; IJsbrand Wijnands > Cc: BIER WG >; draft-ietf-bier-mvpn@iet= f.org; bier-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Ice, As Hooman said, the MUST will force duplicate labels and unnecessary ipv4 a= nd ipv6 separation. It is 2018 and time for us as industry to stop treating= ipv4 and ipv6 separate. We need to change the MUST. Even SHOULD is too str= ong to be honest. We should really say SHOULD for one label and MAY for two= and explain why 2 labels can be used. 2 labels add cost not only because of label space but also because of dupli= cation of operational and management cost. We shouod be clear on this. Regards, Andrew Sent from my iPhone Outlook _____________________________ From: Bidgoli, Hooman (Nokia - CA/Ottawa) > Sent: Thursday, May 31, 2018 1:17 AM Subject: RE: [Bier] draft-ietf-bier-mvpn To: IJsbrand Wijnands > Cc: Dolganow, Andrew (Nokia - SG/Singapore) >, >, BIER WG >, = > Hi Ice > I don't see any benefit in trying to support this with a single label val= ue. The benefit is the saving in the label space. Regards Hooman -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com] Sent: Wednesday, May 30, 2018 10:42 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) > Cc: Dolganow, Andrew (Nokia - SG/Singapore) >; draft-ietf-bier-mvpn@ietf.org; BIER WG >; bi= er-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Hooman, > That said I think from BIER and multicast technology perspective purely, = assigning 2 label for ipv4 and ipv6 address family is not necessary. Maybe = HW limitations should be handled base on the implementation? For interoperability reasons, we should have only one way to support this. = You don't want to end up in a situation where the sending router sends the = packet with the assumption that the egress router will look at the IP heade= r, while the egress router was expecting the label to identify the IP versi= on. I don't see any benefit in trying to support this with a single label value= . Thx, Ice. --_000_BN3PR05MB2642E843A26C7FA5644A4625D4630BN3PR05MB2642namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jingrong,

 

I also have the following in https://tools.ietf.org/ht= ml/draft-zzhang-bess-mvpn-evpn-aggregation-label-01:

2.2.2.3.  Alternative to the per-PMSI Label Allocation

   The per-PMSI label allocation in case of segmentation, whether for

   S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points t= o

   be able to label switch traffic w/o having to do IP or MAC lookup in=

   VRFs (the segmentation points typically do not have those VRFs at

   all).  If the label sca= ling becomes a concern, altertatively the

   segmenation points could use (C-S,C-G)= lookup in VRFs for flows

   identifyed by the S-PMSIs.  This allows the S-PMSIs for the same VPN/

   BD to share the a VPN/BD-identifying label that leads to lookup in

   the VRFs.  That label s= hould be different from the label used in the

   per-PE/region I-PMSIs though, so that the segmentation points can

   label switch other traffic (not identified by those S-PMSIs).

   However, this moves the scaling problem from the number of labels to=

   the number of (C-S/*,C-G) routes in VRFs on the segmentation points.=

 

I did not realized that you had the following in your = email:

 

=D8  Also I have submitted a new draft to describe why it is important and valu= able to use an alternative forwarding procedure in segmented MVPN, by using= IP lookup instead of requiring Per-Flow Labels.

 

I will add an informative reference to your draft next= time when I update my draft.

 

I agree with you that for the particular issue of the = “MUST” wording in draft-ietf-bier= -mvpn, it can stay MUST because the assumption is that segmentation points do lab= el switching. I have not read about the use case that Hooman/Adnrew have.

 

Jeffrey

 

From: B= IER <bier-bounces@ietf.org> On Behalf Of Xiejingrong
Sent: Thursday, May 31, 2018 12:26 AM
To: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@noki= a.com>; Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com= >; IJsbrand Wijnands <ice@cisco.com>
Cc: BIER WG <bier@ietf.org>; draft-ietf-bier-mvpn@ietf.org; bi= er-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

 

Hi folks,

 

I have similar question regarding the= MUST word in this draft 2.1 about the Segmented mvpn scenario. One can see= at https://www.ietf.org/mail-archive/web/bier/current/msg02242.html.<= /o:p>

 

A word of ‘MUST’ may be n= ecessary for a method to gain interoperation, but not necessary or even a b= lock for another method.

 

Maybe a ‘MUST do something when= using xxxx method’  can meet the concerns of interoperation and= flexibility both.

 

To quote RFC2119

6. Guidance in the use of these Imper= atives

   Imperatives of the type = defined in this memo must be used with care

   and sparingly.  In = particular, they MUST only be used where it is

   actually required for in= teroperation or to limit behavior which has

   potential for causing ha= rm (e.g., limiting retransmisssions)  For

   example, they must not b= e used to try to impose a particular method

   on implementors where th= e method is not required for

   interoperability.

 

 

From: = BIER [mailto:bier-bounces@ietf.org= ] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Thursday, May 31, 2018 5:40 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>; IJsbrand Wijnands <= ;ice@cisco.com>
Cc: BIER WG <bier@ietf.org&g= t;; draft-ietf-bier-mvpn@ietf.org; = bier-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

 

Ice,

 

As Hooman said, the MUST will force duplicate labels= and unnecessary ipv4 and ipv6 separation. It is 2018 and time for us as in= dustry to stop treating ipv4 and ipv6 separate. We need to change the MUST.= Even SHOULD is too strong to be honest. We should really say SHOULD for one label and MAY for two and explain why = 2 labels can  be used. 

 

2 labels add cost not only because of label space bu= t also because of duplication of operational and management cost. We shouod=  be clear on this. 

 

Regards,

Andrew

Sent from my iPhone Outlook

_= ____________________________
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Sent: Thursday, May 31, 2018 1:17 AM
Subject: RE: [Bier] draft-ietf-bier-mvpn
To: IJsbrand Wijnands <ice@cisco.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>, <draft-ietf-bier-mvpn@ietf.org>, BIER = WG <bier@ietf.org>, <bier-chairs@ietf.org>

Hi Ice

> I don’t see any benefit in trying to support this with a single = label value.

The benefit is the saving in the label space.

Regards

Hooman

-----Original Message-----
From: IJsbrand Wijnands [mailto:ice@cisco.= com]
Sent: Wednesday, May 30, 2018 10:42 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>; draft-ietf-bier-mvpn@ietf.= org; BIER WG <bier@ietf.org>= ; bier-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

Hooman,

> That said I think from BIER and multicast technology perspective purel= y, assigning 2 label for ipv4 and ipv6 address family is not necessary. May= be HW limitations should be handled base on the implementation?

For interoperability reasons, we should have only one way to support this. = You don’t want to end up in a situation where the sending router send= s the packet with the assumption that the egress router will look at the IP= header, while the egress router was expecting the label to identify the IP version.

I don’t see any benefit in trying to support this with a single label= value.

Thx,

Ice.

--_000_BN3PR05MB2642E843A26C7FA5644A4625D4630BN3PR05MB2642namp_-- From nobody Thu May 31 07:50:47 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6112EA54; Thu, 31 May 2018 07:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 uHsu3y2GpAAd; Thu, 31 May 2018 07:50:07 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE69712EAD2; Thu, 31 May 2018 07:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3gZZIoHgW4ZEF9nvtpKxR8N0CiV9b/fMuwQi2iA2FOc=; b=HzE5iSwyEMxdQi2NFXLaBucCrOZpoIG084wZhBvRe2xKcU01mwdryndcn0NI4G5v3wyy1ZEqr8iFROcii1UUkdqQS9dJJ1/PsfodYBp8XWBE+icl7a09qBCHfLPlTdnsANhehbLO9Vky4NL6aAJWYSL5Amo11osUxSA9TRQ3dI8= Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com (10.168.137.146) by VI1PR0701MB2047.eurprd07.prod.outlook.com (10.167.210.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Thu, 31 May 2018 14:50:00 +0000 Received: from VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8]) by VI1PR0701MB2351.eurprd07.prod.outlook.com ([fe80::9dde:79d1:5358:5df8%9]) with mapi id 15.20.0820.010; Thu, 31 May 2018 14:49:59 +0000 From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" To: IJsbrand Wijnands , "Dolganow, Andrew (Nokia - SG/Singapore)" CC: BIER WG , "draft-ietf-bier-mvpn@ietf.org" , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysIAA62wA///+9+CAAJ/bu4AAaoMA//96wEA= Date: Thu, 31 May 2018 14:49:59 +0000 Message-ID: References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> In-Reply-To: <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hooman.bidgoli@nokia.com; x-originating-ip: [135.245.20.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2047; 7:LdPHulSFPUOlsePC1A0x26JBWF5FHKKJeusGc/aIl+Cb2nLkCsxebXoK6tFRVgXDv3DkxvKMXjr8qU6F0doKBKT9rkCu9tWS+a4d/mSB11Naea+MjSlYEif9AAoIVK7VV8G2LCA3wV3TNjJIDHQoGslQ8k5ra/czO2UMLaQg1Bjf7DUaTu+t1qQxT1tvjoc/FuwZWjIdf7pg2PPijvgtjh8ZuMJNt9U3f17E5Izr8HlHtKpn4RIdLLIo20Tl0BvC x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(199004)(189003)(13464003)(476003)(229853002)(3280700002)(8676002)(5660300001)(55016002)(6246003)(93886005)(3660700001)(6436002)(486006)(2906002)(6636002)(2900100001)(5003630100001)(66066001)(3846002)(6306002)(9686003)(25786009)(4326008)(105586002)(106356001)(33656002)(966005)(6116002)(53936002)(97736004)(86362001)(7696005)(81156014)(76176011)(54906003)(81166006)(8936002)(68736007)(102836004)(316002)(186003)(478600001)(99286004)(26005)(14454004)(7736002)(110136005)(11346002)(446003)(53546011)(6506007)(305945005)(5250100002)(45080400002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2047; H:VI1PR0701MB2351.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:VI1PR0701MB2047; x-ms-traffictypediagnostic: VI1PR0701MB2047: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(109105607167333)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2047; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2047; x-forefront-prvs: 06891E23FB received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AGYiNg6/qZ9TwlYipqwkTwXDcLsmgafUR79mRziwBV9k8g+D5Z9Q2J8CHFN8hTgc9nJMJCmNgU6xna+8tpovSvYFyYBgktunKXvl2AEu/pT6ykaJcAeeSL1A6hsGWPmXAORzIRiqymM9KoUhsWBxo/WYaqd2rJ5zvN3wD5bBpzJQ8kklP8Y4OFvhchqDDdtddsRJiCuxLyKAYRURlYXFELIgpWjv5bIlN5TTuHRfglWZk5uldRjzA3NTcV+X7GDK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 52541e12-2467-4c2d-a498-08d5c705c85d X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52541e12-2467-4c2d-a498-08d5c705c85d X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 14:49:59.1916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2047 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 14:50:22 -0000 SGkgSWNlDQoNCj4gRWFjaCBQRSBoYXMgMU0gbGFiZWxzIHRvIGl0cyBkaXNwb3NhbCwgdGhlcmUg aXMgbm8gc2hvcnRhZ2Ugb2YgbGFiZWxzIGluIHRoaXMgY2FzZS4NCg0KVGhlcmUgYXJlIEhXIGxp bWl0YXRpb25zIGhlcmUgYXMgd2VsbCwgbm90IGFsbCBIVyBzdXBwb3J0IDFNIGxhYmVsIHNwYWNl LCBJIGRvbid0IGFncmVlIHdpdGggdGhpcyBzdGF0ZW1lbnQuIEluIGNvcmUgUEUgeW91IGNvdWxk IGhhdmUgMTBLcyBvZiBWUE5zIG11bHRpcGx5IHRoYXQgYnkgMiwgaXQgaXMgYSBsYXJnZSBsYWJl bCBzcGFjZS4NClRocm93IGEgbXBscyB1bmljYXN0IHByb3RvY29sIG9uIHRvcCBvZiB0aGF0IGFu ZC4uLg0KDQpJIHRoaW5rIGJvdGggaXNzdWVzIG5lZWQgdG8gYmUgY29uc2lkZXJlZCwgaGVyZSBp cyB0aGUgcGFyYWdyYXBoIEkgc3VnZ2VzdA0KDQogICAgICBJZiB0aGUgdHdvIHJvdXRlcyBkbyBu b3QgaGF2ZSB0aGUgc2FtZSBBZGRyZXNzIEZhbWlseSBJZGVudGlmaWVyDQogICAgICAoQUZJKSB2 YWx1ZSwgdGhlbiB0aGVpciByZXNwZWN0aXZlIFBUQXMgTUFZIGNvbnRhaW4gYSBzaW5nbGUgbGFi ZWwsIA0KICAgICAgSW4gdGhpcyBjYXNlIHRoZSBlZ3Jlc3MgUEUgd2lsbCBpZGVudGlmeSB0aGUg QUZJIGJhc2Ugb24gdGhlIElQIHBheWxvYWQgaGVhZGVyLg0KICAgICAgQWx0ZXJuYXRpdmVseSB0 aGVpciByZXNwZWN0aXZlIFBUQXMgTUFZIGNvbnRhaW4gZGlmZmVyZW50IE1QTFMgbGFiZWwgdmFs dWVzLg0KICAgICAgSW4gdGhpcyBjYXNlIHdoZW4gYW4gZWdyZXNzIFBFIHJlY2VpdmVzIGENCiAg ICAgIGRhdGEgcGFja2V0IHdpdGggdGhlIGdpdmVuIGxhYmVsLCB0aGUgZWdyZXNzIFBFIGNhbiBp bmZlciBmcm9tIHRoZQ0KICAgICAgbGFiZWwgd2hldGhlciB0aGUgcGF5bG9hZCBpcyBhbiBJUHY0 IHBhY2tldCBvciBhbiBJUHY2IHBhY2tldC4NCg0KUmVnYXJkcw0KDQpIb29tYW4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJJRVIgW21haWx0bzpiaWVyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBJSnNicmFuZCBXaWpuYW5kcw0KU2VudDogVGh1cnNkYXksIE1h eSAzMSwgMjAxOCAyOjMxIEFNDQpUbzogRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRy9TaW5n YXBvcmUpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPg0KQ2M6IEJJRVIgV0cgPGJpZXJAaWV0 Zi5vcmc+OyBCaWRnb2xpLCBIb29tYW4gKE5va2lhIC0gQ0EvT3R0YXdhKSA8aG9vbWFuLmJpZGdv bGlAbm9raWEuY29tPjsgZHJhZnQtaWV0Zi1iaWVyLW12cG5AaWV0Zi5vcmc7IGJpZXItY2hhaXJz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0JpZXJdIGRyYWZ0LWlldGYtYmllci1tdnBuDQoNCkFu ZHJldywNCg0KPiBBcyBIb29tYW4gc2FpZCwgdGhlIE1VU1Qgd2lsbCBmb3JjZSBkdXBsaWNhdGUg bGFiZWxzIGFuZCB1bm5lY2Vzc2FyeSBpcHY0IGFuZCBpcHY2IHNlcGFyYXRpb24uDQoNCk1VU1Qg d2lsbCBtYWtlIHN1cmUgd2XigJlsbCBlbmQgdXAgd2l0aCBpbnRlcm9wZXJhYmxlIGltcGxlbWVu dGF0aW9ucywgYW5kIHRoZXJlIGlzIGEgbmVlZCB0byB0cmVhdCBJUHY0IGFuZCBJUHY2IGRpZmZl cmVudGx5Lg0KDQo+IEl0IGlzIDIwMTggYW5kIHRpbWUgZm9yIHVzIGFzIGluZHVzdHJ5IHRvIHN0 b3AgdHJlYXRpbmcgaXB2NCBhbmQgaXB2NiBzZXBhcmF0ZS4NCg0KVGhhdCBpcyBhIG5vbi1hcmd1 bWVudC4NCg0KPiBXZSBuZWVkIHRvIGNoYW5nZSB0aGUgTVVTVC4gRXZlbiBTSE9VTEQgaXMgdG9v IHN0cm9uZyB0byBiZSBob25lc3QuIFdlIHNob3VsZCByZWFsbHkgc2F5IFNIT1VMRCBmb3Igb25l IGxhYmVsIGFuZCBNQVkgZm9yIHR3byBhbmQgZXhwbGFpbiB3aHkgMiBsYWJlbHMgY2FuICBiZSB1 c2VkLiANCj4gDQo+IDIgbGFiZWxzIGFkZCBjb3N0IG5vdCBvbmx5IGJlY2F1c2Ugb2YgbGFiZWwg c3BhY2UgYnV0IGFsc28gYmVjYXVzZSBvZiBkdXBsaWNhdGlvbiBvZiBvcGVyYXRpb25hbCBhbmQg bWFuYWdlbWVudCBjb3N0LiBXZSBzaG91b2QgIGJlIGNsZWFyIG9uIHRoaXMuIA0KDQpFYWNoIFBF IGhhcyAxTSBsYWJlbHMgdG8gaXRzIGRpc3Bvc2FsLCB0aGVyZSBpcyBubyBzaG9ydGFnZSBvZiBs YWJlbHMgaW4gdGhpcyBjYXNlLg0KDQpJZiB5b3Ugd2FudCB0byBzY2FsZSBkb3duIHRoZSBudW1i ZXIgb2YgbGFiZWxzIGluIHRoZSBNUExTIEZJQiBvbiB0aGUgZWdyZXNzLCBjaGVja291dCBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenpoYW5nLWJlc3MtbXZwbi1ldnBuLWFnZ3Jl Z2F0aW9uLWxhYmVsLTAxIFRoaXMgZHJhZnRzIHByb3Bvc2VzIHRvIHVzZSBhIGdsb2JhbCBsYWJl bHMgZm9yIHRoZSBkaXNwb3NpdGlvbiwgc3VjaCB0aGF0IHRoZXJlIGlzIG5vIHBlciBQRSBNUExT IHN0YXRlLiBZb3XigJlsbCBlbmQgdXAgd2l0aCB0aGUgbnVtYmVyIG9mIGxhYmVscyBlcXVhbCB0 byB0aGUgbnVtYmVyIG9mIFZQTuKAmXMsIHRpbWVzIDIgaWYgYm90aCBJUHY0IGFuZCBJUHY2IGFy ZSBlbmFibGVkLiBOb3QgYW4gaXNzdWUuDQoNClRoeCwNCg0KSWNlLg0KDQo+IA0KPiBSZWdhcmRz LA0KPiBBbmRyZXcNCj4gU2VudCBmcm9tIG15IGlQaG9uZSBPdXRsb29rDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEZyb206IEJpZGdvbGksIEhvb21hbiAoTm9raWEgLSBDQS9P dHRhd2EpIDxob29tYW4uYmlkZ29saUBub2tpYS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkg MzEsIDIwMTggMToxNyBBTQ0KPiBTdWJqZWN0OiBSRTogW0JpZXJdIGRyYWZ0LWlldGYtYmllci1t dnBuDQo+IFRvOiBJSnNicmFuZCBXaWpuYW5kcyA8aWNlQGNpc2NvLmNvbT4NCj4gQ2M6IERvbGdh bm93LCBBbmRyZXcgKE5va2lhIC0gU0cvU2luZ2Fwb3JlKSA8YW5kcmV3LmRvbGdhbm93QG5va2lh LmNvbT4sIDxkcmFmdC1pZXRmLWJpZXItbXZwbkBpZXRmLm9yZz4sIEJJRVIgV0cgPGJpZXJAaWV0 Zi5vcmc+LCA8Ymllci1jaGFpcnNAaWV0Zi5vcmc+DQo+IA0KPiANCj4gSGkgSWNlDQo+IA0KPiA+ IEkgZG9u4oCZdCBzZWUgYW55IGJlbmVmaXQgaW4gdHJ5aW5nIHRvIHN1cHBvcnQgdGhpcyB3aXRo IGEgc2luZ2xlIGxhYmVsIHZhbHVlLg0KPiANCj4gVGhlIGJlbmVmaXQgaXMgdGhlIHNhdmluZyBp biB0aGUgbGFiZWwgc3BhY2UuDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBIb29tYW4NCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElKc2JyYW5kIFdpam5hbmRzIFttYWls dG86aWNlQGNpc2NvLmNvbV0gDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDMwLCAyMDE4IDEwOjQy IEFNDQo+IFRvOiBCaWRnb2xpLCBIb29tYW4gKE5va2lhIC0gQ0EvT3R0YXdhKSA8aG9vbWFuLmJp ZGdvbGlAbm9raWEuY29tPg0KPiBDYzogRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRy9TaW5n YXBvcmUpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsgZHJhZnQtaWV0Zi1iaWVyLW12cG5A aWV0Zi5vcmc7IEJJRVIgV0cgPGJpZXJAaWV0Zi5vcmc+OyBiaWVyLWNoYWlyc0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW0JpZXJdIGRyYWZ0LWlldGYtYmllci1tdnBuDQo+IA0KPiBIb29tYW4s DQo+IA0KPiA+IFRoYXQgc2FpZCBJIHRoaW5rIGZyb20gQklFUiBhbmQgbXVsdGljYXN0IHRlY2hu b2xvZ3kgcGVyc3BlY3RpdmUgcHVyZWx5LCBhc3NpZ25pbmcgMiBsYWJlbCBmb3IgaXB2NCBhbmQg aXB2NiBhZGRyZXNzIGZhbWlseSBpcyBub3QgbmVjZXNzYXJ5LiBNYXliZSBIVyBsaW1pdGF0aW9u cyBzaG91bGQgYmUgaGFuZGxlZCBiYXNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbj8gDQo+IA0KPiBG b3IgaW50ZXJvcGVyYWJpbGl0eSByZWFzb25zLCB3ZSBzaG91bGQgaGF2ZSBvbmx5IG9uZSB3YXkg dG8gc3VwcG9ydCB0aGlzLiBZb3UgZG9u4oCZdCB3YW50IHRvIGVuZCB1cCBpbiBhIHNpdHVhdGlv biB3aGVyZSB0aGUgc2VuZGluZyByb3V0ZXIgc2VuZHMgdGhlIHBhY2tldCB3aXRoIHRoZSBhc3N1 bXB0aW9uIHRoYXQgdGhlIGVncmVzcyByb3V0ZXIgd2lsbCBsb29rIGF0IHRoZSBJUCBoZWFkZXIs IHdoaWxlIHRoZSBlZ3Jlc3Mgcm91dGVyIHdhcyBleHBlY3RpbmcgdGhlIGxhYmVsIHRvIGlkZW50 aWZ5IHRoZSBJUCB2ZXJzaW9uLg0KPiANCj4gSSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiB0 cnlpbmcgdG8gc3VwcG9ydCB0aGlzIHdpdGggYSBzaW5nbGUgbGFiZWwgdmFsdWUuDQo+IA0KPiBU aHgsDQo+IA0KPiBJY2UuDQo+IA0KPiANCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpCSUVSIG1haWxpbmcgbGlzdA0KQklFUkBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQo= From nobody Thu May 31 08:05:49 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5034B12F29B; Thu, 31 May 2018 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Tk_PTMKlF6OK; Thu, 31 May 2018 08:05:39 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039CD12E86C; Thu, 31 May 2018 08:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5280; q=dns/txt; s=iport; t=1527779125; x=1528988725; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vLHpYDVptK9CzToDzVTGAuzq7WNiLwbMfrNkId66JdE=; b=T2EjOBXM63mXWA7YlYZHgEmXhkJwbS/1AdFO52fBKOmM0RgWOckuHeFB QhXVzbZb24kB3MldTjuaHFEoPzcunrWVRGI0L3Dk8i/pFW3hy6YAhmoAz TSmK9wD6odtNAmcsWtiB03ij0RQcszPpzYv5znjsjHlG6CAlxDenISe60 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AAD9DRBb/xbLJq1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGEJm0SKIN3iARfjEsBAQEBAQaBByGBD5M8gXgLGA2ERwK?= =?us-ascii?q?CJTQYAQIBAQEBAQECbBwMhSgBAQEBAgEBASFLCwUHBAsRBAEBAwIjAwICJx8?= =?us-ascii?q?JCAYTG4MDBAKBcgUID6dBghyIRIFjBYEKiEOBB4EPJAyCXYMRAQEDgTIrgwA?= =?us-ascii?q?wgiQCmGkJhWyIdY0TiXGEUIItAgQGBQITAYFBOA2BRU0jFTsqAYIYPoFiBRK?= =?us-ascii?q?IWYVAPTCPYQEB?= X-IronPort-AV: E=Sophos;i="5.49,463,1520899200"; d="scan'208";a="4169293" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2018 15:05:23 +0000 Received: from ams-iwijnand-88113.cisco.com (ams-iwijnand-88113.cisco.com [10.60.202.94]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w4VF5MNx007397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 May 2018 15:05:23 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: IJsbrand Wijnands In-Reply-To: Date: Thu, 31 May 2018 17:05:22 +0200 Cc: "Dolganow, Andrew (Nokia - SG/Singapore)" , BIER WG , "draft-ietf-bier-mvpn@ietf.org" , "bier-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3DBA3451-3ECA-4920-B513-F3F2016E6FCF@cisco.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:05:48 -0000 Hi Hooman, >> Each PE has 1M labels to its disposal, there is no shortage of labels = in this case. >=20 > There are HW limitations here as well, not all HW support 1M label = space, I don't agree with this statement. In core PE you could have 10Ks = of VPNs multiply that by 2, it is a large label space. > Throw a mpls unicast protocol on top of that and=E2=80=A6 I don=E2=80=99t find that convincing at all. If you really want to make = the upstream label space smaller, the solution for that is documented in = https://tools.ietf.org/html/draft-zzhang-bess-mvpn-evpn-aggregation-label-= 01. Are there examples in IETF where for MPLS forwarding we use the IP proto = to dispatch between IPv4/IPv6? > I think both issues need to be considered, here is the paragraph I = suggest >=20 > If the two routes do not have the same Address Family Identifier > (AFI) value, then their respective PTAs MAY contain a single = label,=20 > In this case the egress PE will identify the AFI base on the IP = payload header. > Alternatively their respective PTAs MAY contain different MPLS = label values. > In this case when an egress PE receives a > data packet with the given label, the egress PE can infer from = the > label whether the payload is an IPv4 packet or an IPv6 packet. This will lead to all sort of interoperability issues. If you want to = use IP proto, it needs to be signalled so the ingress at least knows = what is expected. Thx, Ice. >=20 > Regards >=20 > Hooman >=20 > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand = Wijnands > Sent: Thursday, May 31, 2018 2:31 AM > To: Dolganow, Andrew (Nokia - SG/Singapore) = > Cc: BIER WG ; Bidgoli, Hooman (Nokia - CA/Ottawa) = ; draft-ietf-bier-mvpn@ietf.org; = bier-chairs@ietf.org > Subject: Re: [Bier] draft-ietf-bier-mvpn >=20 > Andrew, >=20 >> As Hooman said, the MUST will force duplicate labels and unnecessary = ipv4 and ipv6 separation. >=20 > MUST will make sure we=E2=80=99ll end up with interoperable = implementations, and there is a need to treat IPv4 and IPv6 differently. >=20 >> It is 2018 and time for us as industry to stop treating ipv4 and ipv6 = separate. >=20 > That is a non-argument. >=20 >> We need to change the MUST. Even SHOULD is too strong to be honest. = We should really say SHOULD for one label and MAY for two and explain = why 2 labels can be used.=20 >>=20 >> 2 labels add cost not only because of label space but also because of = duplication of operational and management cost. We shouod be clear on = this.=20 >=20 > Each PE has 1M labels to its disposal, there is no shortage of labels = in this case. >=20 > If you want to scale down the number of labels in the MPLS FIB on the = egress, checkout = https://tools.ietf.org/html/draft-zzhang-bess-mvpn-evpn-aggregation-label-= 01 This drafts proposes to use a global labels for the disposition, such = that there is no per PE MPLS state. You=E2=80=99ll end up with the = number of labels equal to the number of VPN=E2=80=99s, times 2 if both = IPv4 and IPv6 are enabled. Not an issue. >=20 > Thx, >=20 > Ice. >=20 >>=20 >> Regards, >> Andrew >> Sent from my iPhone Outlook >> _____________________________ >> From: Bidgoli, Hooman (Nokia - CA/Ottawa) >> Sent: Thursday, May 31, 2018 1:17 AM >> Subject: RE: [Bier] draft-ietf-bier-mvpn >> To: IJsbrand Wijnands >> Cc: Dolganow, Andrew (Nokia - SG/Singapore) = , , BIER WG = , >>=20 >>=20 >> Hi Ice >>=20 >>> I don=E2=80=99t see any benefit in trying to support this with a = single label value. >>=20 >> The benefit is the saving in the label space. >>=20 >> Regards >>=20 >> Hooman >>=20 >> -----Original Message----- >> From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 >> Sent: Wednesday, May 30, 2018 10:42 AM >> To: Bidgoli, Hooman (Nokia - CA/Ottawa) >> Cc: Dolganow, Andrew (Nokia - SG/Singapore) = ; draft-ietf-bier-mvpn@ietf.org; BIER WG = ; bier-chairs@ietf.org >> Subject: Re: [Bier] draft-ietf-bier-mvpn >>=20 >> Hooman, >>=20 >>> That said I think from BIER and multicast technology perspective = purely, assigning 2 label for ipv4 and ipv6 address family is not = necessary. Maybe HW limitations should be handled base on the = implementation?=20 >>=20 >> For interoperability reasons, we should have only one way to support = this. You don=E2=80=99t want to end up in a situation where the sending = router sends the packet with the assumption that the egress router will = look at the IP header, while the egress router was expecting the label = to identify the IP version. >>=20 >> I don=E2=80=99t see any benefit in trying to support this with a = single label value. >>=20 >> Thx, >>=20 >> Ice. >>=20 >>=20 >>=20 >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Thu May 31 08:36:34 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7358112E8AE; Thu, 31 May 2018 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 cpKWJjoNRoJY; Thu, 31 May 2018 08:36:30 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 37E6012D877; Thu, 31 May 2018 08:36:30 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4VFTcl5009425; Thu, 31 May 2018 08:36:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=iEwSzmZyFLFkKetOlvA09fAlqnnEN+NtePQeF4IJdS8=; b=NalB6FRk5ptEM6R+LUcZ6AnuN3IBZsEeVEWvRhzMIlITG+oIFqzjmfM4fCp00wuowDKX 1oAgbuuOVAbhD47BWHqnHrPfD/h96x0kf9eHHpOEh9vXmnsL2vyWYHUr/VOJ3MKypSSR d9YVygcAeUuUsYIHo2dTgqSRL5Pes1m2Ze0XQ3XpGV3hxKIRidCd1QsPHRVaRhg26M84 QxP3F/6dmKUZVyfqZDAbJMNDI5XoCbjIW8EVtER2xXXytPVp+fUV1lzQnHUOn3uQMvB+ HbWiKogNjH22m1XvM/KrWNk9uSjmR+PPA35EWEbVOTUWoOTDWnJ5cVtqS9Wp4DQGM5LC hQ== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0113.outbound.protection.outlook.com [207.46.163.113]) by mx0a-00273201.pphosted.com with ESMTP id 2jakb001v3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 May 2018 08:36:28 -0700 Received: from [172.29.35.171] (66.129.241.12) by MWHPR0501MB3868.namprd05.prod.outlook.com (2603:10b6:301:7b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Thu, 31 May 2018 15:36:23 +0000 To: IJsbrand Wijnands , "Dolganow, Andrew (Nokia - SG/Singapore)" Cc: "Bidgoli, Hooman (Nokia - CA/Ottawa)" , "draft-ietf-bier-mvpn@ietf.org" , BIER WG , "bier-chairs@ietf.org" References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> From: Eric C Rosen Message-ID: <2fd9cdd3-7ffc-a368-c1e0-19708869110e@juniper.net> Date: Thu, 31 May 2018 11:36:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN4PR11CA0023.namprd11.prod.outlook.com (2603:10b6:403:1::33) To MWHPR0501MB3868.namprd05.prod.outlook.com (2603:10b6:301:7b::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:MWHPR0501MB3868; X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 3:AzGxbOLo3NaSUNrY16NqnIPaB2fDJwUJw4+I9Rk20OYqhpqvZZUr5LAxU3zVD8ada0W3LTQ3n2ibyZ4A1D1KwAxCGE1JvHbiR9foRa/yloogvYSYGTBXyjLBM8S7hxAycJSCth0W1HevIlw923PbspenrO3EYLpXSqtEN3Bs2q/cOWlumrHpw1usz56QLkPOqN7O3rqRH/3QDnU8zyFZV/SGptlmLhhQwsILGXkf5qk7d7roUV0I2mShMJFhcaNg; 25:tFAr/wrjtEsfH/Gxx1kltJCa+EZnI3X41+0BzqqTWqjU+tyZtTR959e1DJ4lhmfpToyVSA40LlKQJDYhhFqu0vbg/fV29YhHqo3Nc81XJNX110l6ZctLIk7tYLRBvgoVIxDRc6KU7oNJxa+omCHM8L+xOl2a27DKQI5SsF7Yv1snQuBUkuD1z8uIjpm6v0YeKjgCWdjSh6+Vxi4lNlEaYpCBoo9lApFX1FrLrd2ZqygEaKEy4vCvAGEQFVmlursGE8QEtmHZEvKCBMJq1lflIJMs/NPwcEeTBAoHGioHA2rkQmj26wXd9ZSxXsOkqVC0FyttXi3ZyvqLDzw9Bi62Nw==; 31:2+jjH0dPo0SNz/fRCHJO7O1uqzFHEcH9EqNZFu3a6diBh+/HqBwsaR2E5HPj5QIB2rgromBDyyJxfy5EJIUhiBjoyHMUQ1ObWFzNp0iT41R0kmw/BZGSmcyIeKqi09Ojbc9kUxe6zYQ3IC19JyZ6d/jbXCXFgfkdlcHXeBsjDO3zATwD4I3T532Vp0qtY149IlY7qwbuYbUTYSwH5yWOoIdg0mPw3cCjxXe4DDna/tA= X-MS-TrafficTypeDiagnostic: MWHPR0501MB3868: X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 20:bBUJy0bcKCxlnXjmvpeVbM6jL72WG+kI7E1hyvp8IAN/KmSzV/5rqf0VHeOdJ9yKhDFKMmldr84+IfgHp1yQ2g1cuzMQCUzb8PnGj1E9JwoOwN19VASbEQH4z7Fp5nxmcRFAuGnvcqDHPFq2SFzYWGsZNY54GUKJlqwqXImE0ve4ae9DiDTAi71jcqfP+N1y6VwyVrL8r/lggWez/Nl0dBsqJoslK9WtJe9ahTfV5jD/n6JykJHVqQXNDkcvBobaz6cBAUnmYXi/4f7esv8mBsXe8VZFDjNnshnCMDN/kVkwl7Zd0/hYj+LAJwIrm79JPlE6m+uSo/59q1njjYEvKuCRGpU/TTX/ZZk4t5GBP0s4wnXeduI/HRwl98di7NQ3QYx8JJF+RD2nuAKII2kf+gK9QICHrhhKyfOfij1IcFMMEUhpBNSOCEBt6ZBsQYhJOYg0QmhRgJlJufO4/vxm1Upden/uXIF7IK2wofszwJ9LLKu1UtPy2NZoaMFjODTUNFjm4hXFn0RRbUt7X+JtAr+nGLvwTkyx8dI/Zsw/xqpdC4MRsQj0y2Aq7mwsNfV7bX8fnzK34VvBK5tXBhN1r1K0djqtYBApcoFe6thrQb4=; 4:ay1u1zh9O3CMtnF7nNDIC3Nfp9pNaaZrz3bQrZ9xmrwxciDtScKp1DktQsJ76H3LMhYMXhEa3fQWc+lViBGLcz/Ys6rM4Xh2fUyPjFkfwI3W1NdxSDncFLHm5ACLATR950yWo9NAhOy6am8sZzsGE0bMttXVNCK1b4twUlJEfJx4RZvOw5TSm+79gJo99p/a4bx5qdKRKCDqXHEGajwiNlPnFS802ZoUtuorrSV2yajjEPwHTuo4odyDP3HCEzTr+Ed6cMt2ou3b8kyoWX2gow== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:MWHPR0501MB3868; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0501MB3868; X-Forefront-PRVS: 06891E23FB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39380400002)(376002)(39860400002)(346002)(366004)(396003)(199004)(189003)(65826007)(68736007)(230700001)(76176011)(16576012)(6666003)(58126008)(316002)(5660300001)(8676002)(81166006)(110136005)(81156014)(229853002)(6486002)(54906003)(2906002)(8936002)(64126003)(3846002)(97736004)(53936002)(305945005)(4326008)(86362001)(25786009)(3260700006)(6116002)(8656006)(23676004)(52146003)(2486003)(52116002)(67846002)(486006)(53546011)(66066001)(65806001)(386003)(50466002)(59450400001)(11346002)(16526019)(478600001)(446003)(65956001)(36756003)(26005)(47776003)(2616005)(6246003)(77096007)(105586002)(7736002)(106356001)(476003)(31696002)(956004)(31686004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0501MB3868; H:[172.29.35.171]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA1MDFNQjM4Njg7MjM6bkxqYXBSTFlEMElld0dzTDVBTFA1YlUr?= =?utf-8?B?ZU9QZ1VXUWE2L21IcjFlWTZHQU5VaHA5WlQzLy9Qd3BNZkNsLzVMeCtMSXpV?= =?utf-8?B?OGw2ZHR6R01XbHhJcDBSbGdmbDlZOUhvUGtIMWJLTzdYcUVYMzl3VERWNzBt?= =?utf-8?B?TDZpSENMZE1UOVNsQkRlWTY5UG1WSVg1N2JheVB0bE01cW9ZOWhpL2hNY25X?= =?utf-8?B?emNrS1YyajJmSHMwOVY5eW41dUNkeVViZkFhZWZFd2RFa0szdVVxZVlnYWhU?= =?utf-8?B?Zit6UlluY0dLSkM5Q0tFT0x3YnZqZm02eVdpMlB5Rm5vb0toOXphREZINW4r?= =?utf-8?B?YnNZQ3hWQlNsSEpVbmhyR0NMS2E3ZmN3d3I4WFhsSkRpd2RIY0dqYWtRN0xY?= =?utf-8?B?M1lGOUhaVDRDNUNwT0R2QWh0aGtjS3Z2Mkl5Nm9VRnNrRXYvd1M4WS9HeDFU?= =?utf-8?B?VlJhM1BCbGtYYTA5bmMxbTIyVEVEOCtCUERsM0QrWkN0bkhiMlZWMW9acFhm?= =?utf-8?B?dWRhdWZ6eks5SVZtQzJsdUVndmxCemdEdUUwb0Y2U1V5N3ViZG5BM09Sc0VK?= =?utf-8?B?cnJFMlRxYkozVFgzQ01ndGh3Nll6TFhYeGhJVmxnbi9NUENwVGVidjRuaTFE?= =?utf-8?B?RFpaVE1HRDJYc2JmOEh1T3B6MEhMVTR6eEdFc1AwcnFVd3ZLSFZlNmE3Tk9h?= =?utf-8?B?Z3ZjOEdIQXUxNkFtcWgrMm1XaTduM09ncytMcjBmSVYrUGNKbWlPSXhFRTF4?= =?utf-8?B?RFF5OVVUN002aTFpODJia3VLUzMxZE9SckNsejZka25yTGlNUlFzdkliY2Nz?= =?utf-8?B?ekhObHRTVUNtSytCbDdUdDVhejBNMkhwbjdwNXVwb1RFT2xLdHlBZlFMeUxG?= =?utf-8?B?OFdNZ0g3QWhva0NyOUpOZE5zYUZqWlp6aWNKTGROeGI3ZmxLL1NLUkd0THp0?= =?utf-8?B?TFdPU0RwQWtlWTJGcVo0aC9zRnpDUG9vNmdIc3FNcU00RVBDekVXOFFHNGdH?= =?utf-8?B?VlFad1JEZDQvTEk2ek9UNjFVY2lYUTBDRFBQMUdxSE5JeDJBQWpPNGJodnRi?= =?utf-8?B?NDgvM0hhNzNNRmNGN3R3S3R1a255ZGhVTUtUdWZmdmp1OFZwYUxXMXg5bExy?= =?utf-8?B?R0VRRWdlWGtERGJvOFFmdi9QS202dUFwMWh4VHBDSEgrUjdQRDBxemtsaEtF?= =?utf-8?B?azlHamVvc1VxeU1XREt6UjR1aSt0UUtpVEtpQndoVncyNUFJeGNPbDBJVlJ6?= =?utf-8?B?dTM4R3lQVVdlOHNodVBpTG0vQXYxaGFLMjk0MVVkSW1lenh6OVRHcWkyT3RQ?= =?utf-8?B?T0JPUlk4VFBDd1RDNG5nYjFNOHkreTU5OTJ0aFdnR05IVmVUUU1haG9CcW53?= =?utf-8?B?YzZpUHRTaUZNOEo0QXF4QVBteDVqWnNQWGhoZlhiT1pXTHM4WXY2N3U3NUI3?= =?utf-8?B?anlTZkt4UlIyQThndXU5Ri9LTmhZMW0yZkdHbzFGTkJrQUFaNWE3QVVFWHBv?= =?utf-8?B?SWcwd25WdURqWFpDWHIxMmNEeUpRZ0lhSjc4U25uUXk2UVZzeW1NTHkvMmdF?= =?utf-8?B?UkdBUU00QXM0cWpjWHdTUGppZk9BWHR6bHdjZ2NrRkZZTzl1MkdmU1NlVjZI?= =?utf-8?B?cFJQVFpnM2VCM2ptSi9KamlRVjQrazkrSFpOYnEyc1VCc0RhMnkrYnNVS3BV?= =?utf-8?B?b0UxeERuOU1JR2VJMWE5TWxaMGtWVHFSYWhmZThZL0pDRlpnUklRdjN4TXJI?= =?utf-8?B?WlZLcnJaVUJKakIwRVQ0ellMN1ZPbGtscUM4VXJuYkpFNEs5bTFUb3FmdGRm?= =?utf-8?B?SmVUaVN4SHpaYjk1WmZpWHRMbHpSZzh1T0VFZFRSRFpBUGdNWVJEOG5WTk4x?= =?utf-8?B?TWUvM1c4MklOTUZqcVhRbENLckxuNklScjI1dEd5S2FhL2FBdVdUOEo2alN5?= =?utf-8?B?TXBreklhL3pFWHpITzlLTlp4ZFhFRHc0MFpVTGZGVGVGUW14ZkhQVmU3aUQ1?= =?utf-8?B?c1p5Nkw2SjhsTWQzK1ZuOUV2Y2NLUTdYWmZoSEd5TjRwL2lmbWdqWTlBYVlt?= =?utf-8?Q?eddCB8=3D?= X-Microsoft-Antispam-Message-Info: ZExtt8GJjOl22cjHaLp/NKPn4fKbPdV92TDfu+Unmg/2DnUonG3ARssGNFgMwaoYoAx2My7oZkiMYieIiV32j0ZdaNEFs51xM+K/P06w4aU/lNWMXjW1vkeepOtai69Ii9u+2kVjYXD1yn3BLM49k69SVxAM5QlCZKSmE9vjvnLs649Iahki0rBFJLAnqRHD X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 6:KjAH51OIZxTFfM/INj/F3msxbkxgG6fQPDjQBTpJJXFGhKXe5NUyKhjvw6rHXEv6mI7ZylGpOHU4f9Gycbv62osJuMAcX4IqansUOjjzr8PlEjzYZYBV6Md/gI6M5X8qWJ1nyY8S8OaY5GB9Cb9BkZIzeZpNh6kG5ezrslQ2stgtc6BcWa5jrGji/G6H1kWkA2XTGlhpDXrLJsEDEezSZxaENNkIFH+kK7jfiuZ1JmuOzCN+lD8YDvSw28KqOV4HZ73nHTvH8vJwMrBYp86pCClhlpHREmNH5iML8niTPQ0DP0EkK/kHNteAUb9F6UmGEC0h0vVdAak15PbobMMrC01+uAfpfqNDBjQJX5YRjt7b2XZZrB4A/BgMH7prFMxdi0fju4OPiKf7/qUcOcWKZmnnz3m1CK3BE53mISVcoSFZey78T0xt5J5KnOJvCbDim9EXlbRY2g+uEokb/T9xag==; 5:ptRM9b4b5ZmViuNWv7q81eBPsq3sphUOUllFSFmRZdggXsp1GnUYJPxKSjxBqHAgK/eXvK+csnf4uoI9OBRJpH2fDUCNYWgXOi3YFl03EubnUTSXYLiSE288qpO98vvcjHS4m5JLhUa/Zwx7ezcctt9vGy/B9Ry+id6kwd8NNCg=; 24:5zht9DsTEScpBKXdcwmTmDRxzaEs1/TIfjuiTdel1OuPaXInoLfuvAOXyEybItF5kgXpwdbBlGk8DFp9MgpMPQa45fhecX9sWtQhz+dVgQM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 7:KVAcngZgpTCoPkq1ikNM18N69LsNscrF9UZg0/vNVc930NLqicM4662aTVGsPaISpeIdvnBkFQE3PlVfP9tDdtAHypO21AUJb9/wGZTt8qy4cxU4oJLvY2jrhMVIM1NPkl8jLu70uhMPocj/Elg3mcHrJS07PuBt70MMQ/0rcTftEf5QjCSnnrN6f3Me3DC7+9g5ynzS5ySWAeXUXNIj4WaZtttoGhOOOfvIyn7jQ9vu6iS2hNrwqQqXfENcEjYP X-MS-Office365-Filtering-Correlation-Id: 94487c2d-6bd4-4418-908b-08d5c70c44a3 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2018 15:36:23.5710 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 94487c2d-6bd4-4418-908b-08d5c70c44a3 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0501MB3868 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805310174 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:36:33 -0000 On 5/30/2018 2:56 AM, IJsbrand Wijnands wrote: > Not all HW is capable (or desirable) to look at the IP header to determine the IP version and this might also have a performance impact. If we make it SHOULD, we might also introduce interoperability problems where vendor A uses two labels and vendor B uses the IP header. > > I think we should keep this as MUST. > I agree with Ice here, and it seems to me that this reasoning completely settles the issue. > If you want to use IP proto, it needs to be signalled so the ingress at least knows what is expected. I suppose one could have an option to use the same label for both v4 and v6 on a given P-tunnel if one knows via signaling that all the egress nodes of that P-tunnel support the necessary functionality. If someone wants to write a draft specifying that signaling, please don't forget to take P-tunnel segmentation into account. As an aside, I note that the generalization "don't have too many options in a protocol" always seems to be forgotten when discussing individual cases ;-) I'd also note that simply repeating the same opinions multiple times with increasing degrees of forcefulness doesn't make them any more valid. From nobody Thu May 31 09:48:44 2018 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C0A12426E; Thu, 31 May 2018 09:48:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , bier@ietf.org, Reshad Rahman , aretana.ietf@gmail.com, rrahman@cisco.com, rfc-editor@rfc-editor.org, draft-ietf-bier-ospf-bier-extensions@ietf.org, bier-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152778532220.12042.16120687150303549233.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2018 09:48:42 -0700 Archived-At: Subject: [Bier] Protocol Action: 'OSPFv2 Extensions for BIER' to Proposed Standard (draft-ietf-bier-ospf-bier-extensions-17.txt) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 16:48:43 -0000 The IESG has approved the following document: - 'OSPFv2 Extensions for BIER' (draft-ietf-bier-ospf-bier-extensions-17.txt) as Proposed Standard This document is the product of the Bit Indexed Explicit Replication Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/ Technical Summary This document describes the OSPFv2 protocol extension for Bit Index Explicit Replication (BIER) with MPLS encapsulation. Working Group Summary This document was presented and discussed at IETF91, IETF92 and IETF95. There were discussions on whether there was a mismatch with an example in the MPLS encapsulation draft, that was resolved by clarifying the text in that draft. The discussions on IPv6 support resulted in the decision to do a separate document for OSPFv3 BIER Extensions. There was a discussion on the BIER alias regarding allowing 0 for the label range size and, with WG agreement, a change was made. The WG is still discussing whether to change the BAR size from 8 bits to 16 (or with a type/subtype) for future-proofing to potentially allow interaction with an individual draft in a different WG. This discussion erupted on the list well after WGLC. IF there is clear WG consensus to make this change, then I will ensure a 1 week WGLC for this technical change. Document Quality Major vendors on the author list have working implementations or are working on the implementation of the extensions. Acee Lindem has done a thorough review of the document. Personnel The Document Shepherd is Reshad Rahman. The Responsible Area Director is Alvaro Retana. From nobody Thu May 31 18:07:38 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16B124239; Thu, 31 May 2018 18:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 2LCmoXaa1tPa; Thu, 31 May 2018 18:07:34 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791211241F5; Thu, 31 May 2018 18:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=96wPF+wALRp/XjTJp9w5rxoBZ3Lll+/JlA0O1F+B6vE=; b=lj9v42pdiI8JldDS81ie6D5AS07Y5S2VoOxkcRI0X2vWIn/VkSRQnQ9g9RShkUigT0pjttY+Ox65XOdad/TXuwmaEvUhQABMa9fiLL3+sGQpiodWiybGDFybh4ezpVs6coHDd71/EZjA51Gl1nJj/zTDdCHmiSKUzxTzTu4Jg/s= Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com (10.168.155.146) by AM5PR0701MB1858.eurprd07.prod.outlook.com (10.167.216.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Fri, 1 Jun 2018 01:07:28 +0000 Received: from AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192]) by AM5PR0701MB2867.eurprd07.prod.outlook.com ([fe80::7023:ac0c:35a7:192%5]) with mapi id 15.20.0841.006; Fri, 1 Jun 2018 01:07:28 +0000 From: "Dolganow, Andrew (Nokia - SG/Singapore)" To: IJsbrand Wijnands , "Bidgoli, Hooman (Nokia - CA/Ottawa)" CC: BIER WG , "draft-ietf-bier-mvpn@ietf.org" , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA///EiAD//5ZysIAA62wA///+9+CAAJ/bu4AAaoMA//96wEAAIpuVAAAlyWOA Date: Fri, 1 Jun 2018 01:07:28 +0000 Message-ID: References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com> <69231D2A-EAC0-4DD3-B727-85D8A8D306BB@cisco.com> <3DBA3451-3ECA-4920-B513-F3F2016E6FCF@cisco.com> In-Reply-To: <3DBA3451-3ECA-4920-B513-F3F2016E6FCF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.dolganow@nokia.com; x-originating-ip: [131.228.32.172] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1858; 7:F/cvYSLy7KZxqBVA3bUNUo0g/q4b645O5w79sUkfMk5FLQSAbJ0lTcybUvgYD4UzPC0+/qEPttrZPWhwF++/oKY8nkJGoa+VuQ8knWovzvcUqjVp22azU+7zqvgHoqe0TqwemgfWAFlKXYiKODYuvZYGALSuezSrza8+VdaqFE8nHGp7F1Mpy1Zt3tlIvem5WufWbxKbr1bfwEIrgIpESV8uQoxEiVsUkCtjQBCBlsb/KQHX1hUEseAvg7f7qPEk x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(39380400002)(396003)(376002)(366004)(199004)(189003)(13464003)(102836004)(3846002)(3660700001)(53936002)(81166006)(4326008)(6306002)(446003)(6636002)(6512007)(6436002)(68736007)(110136005)(54906003)(2906002)(305945005)(6506007)(6116002)(26005)(5003630100001)(76176011)(229853002)(53546011)(3280700002)(6246003)(66066001)(58126008)(966005)(5660300001)(97736004)(14454004)(2900100001)(6486002)(36756003)(5250100002)(105586002)(106356001)(7736002)(486006)(25786009)(186003)(83716003)(93886005)(99286004)(82746002)(2616005)(11346002)(8936002)(33656002)(45080400002)(86362001)(476003)(8676002)(316002)(81156014)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1858; H:AM5PR0701MB2867.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:AM5PR0701MB1858; x-ms-traffictypediagnostic: AM5PR0701MB1858: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(109105607167333)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB1858; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB1858; x-forefront-prvs: 0690E5FF22 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kefsYOtFZbAmmKBUQG0u47r1pTXe94Rst9NSuKMmNBUWvGkks9AjNcb5SgjGjaS63bma+huaHUje1ndttlJY85FGEfmdWgFWgw+d8qy8fCxopiDSLxO9nHtZx492C2Ef991o6iKzVqD1TOHOm1qBMaQT8WuAY33LrRFySOYTL9FaxYnk7ILEFBFLkyN7MLHEosTr6zUXM/Mpv7pR+bJWdEv8z9XKVqYDW/TfxX1+q7mVS+zj41fjQHnrMky9QpxV spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0C19ACC88408BD47958F2674E8E972DD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 79898920-96da-4ccb-3f8c-08d5c75c0b45 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79898920-96da-4ccb-3f8c-08d5c75c0b45 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2018 01:07:28.1398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1858 Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 01:07:37 -0000 SWNlLA0KDQpXaXRob3V0IGEgc2luZ2xlIGxhYmVsIHlvdSBoYXZlIHRvIGRvIHRvbnMgb2YgZXh0 cmEgcHJvY2Vzc2luZyBmb3IgY2FzZXMgd2hlbiBib3RoIHY0IGFuZCB2NiBleGlzdHMgYnV0IHlv dSBuZWVkIHRvIHRyZWF0IHRyYWZmaWMgYXMgbXVsdGljYXN0IC0gaXJyZXNwZWN0aXZlIG9mIElQ IHZlcnNpb24uIFRoaXMgaXMgZG9hYmxlIGF0IHRoZSBlZGdlIGJ1dCBwcmV0dHkgbXVjaCBpbXBv c3NpYmxlIGluIGRvd25zdHJlYW0gcm91dGVycy4gQXMgcGVvcGxlIG1vdmUgdG8gdjYgc3VjaCBi YXNpYyBmdW5jdGlvbmFsaXR5IHJlcXVpcmVtZW50IGlzIGNvbW1vbi4gDQoNCkkgY291bGQgc2Vl IGEgc29sdXRpb24gdmlhIHNpZ25hbGluZyBkb2FibGUgYnV0IHdlIHdvdWxkIGF0IGxlYXN0IG5l ZWQgdG8gcG9pbnQgdG8gdGhhdCBoZXJlLg0KDQpBbmRyZXcNCg0K77u/LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206ICIoSWNlKSBJSnNicmFuZCBXaWpuYW5kcyIgPGljZUBjaXNjby5j b20+DQpEYXRlOiBUaHVyc2RheSwgTWF5IDMxLCAyMDE4IGF0IDExOjA1IFBNDQpUbzogSG9vbWFu IEJpZGdvbGkgPGhvb21hbi5iaWRnb2xpQG5va2lhLmNvbT4NCkNjOiBBbmRyZXcgRG9sZ2Fub3cg PGFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+LCBCSUVSIFdHIDxiaWVyQGlldGYub3JnPiwgImRy YWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1iaWVyLW12cG5AaWV0Zi5v cmc+LCAiYmllci1jaGFpcnNAaWV0Zi5vcmciIDxiaWVyLWNoYWlyc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbQmllcl0gZHJhZnQtaWV0Zi1iaWVyLW12cG4NCg0KICAgIEhpIEhvb21hbiwNCiAg ICANCiAgICA+PiBFYWNoIFBFIGhhcyAxTSBsYWJlbHMgdG8gaXRzIGRpc3Bvc2FsLCB0aGVyZSBp cyBubyBzaG9ydGFnZSBvZiBsYWJlbHMgaW4gdGhpcyBjYXNlLg0KICAgID4gDQogICAgPiBUaGVy ZSBhcmUgSFcgbGltaXRhdGlvbnMgaGVyZSBhcyB3ZWxsLCBub3QgYWxsIEhXIHN1cHBvcnQgMU0g bGFiZWwgc3BhY2UsIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGlzIHN0YXRlbWVudC4gSW4gY29yZSBQ RSB5b3UgY291bGQgaGF2ZSAxMEtzIG9mIFZQTnMgbXVsdGlwbHkgdGhhdCBieSAyLCBpdCBpcyBh IGxhcmdlIGxhYmVsIHNwYWNlLg0KICAgID4gVGhyb3cgYSBtcGxzIHVuaWNhc3QgcHJvdG9jb2wg b24gdG9wIG9mIHRoYXQgYW5k4oCmDQogICAgDQogICAgSSBkb27igJl0IGZpbmQgdGhhdCBjb252 aW5jaW5nIGF0IGFsbC4gSWYgeW91IHJlYWxseSB3YW50IHRvIG1ha2UgdGhlIHVwc3RyZWFtIGxh YmVsIHNwYWNlIHNtYWxsZXIsIHRoZSBzb2x1dGlvbiBmb3IgdGhhdCBpcyBkb2N1bWVudGVkIGlu IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16emhhbmctYmVzcy1tdnBuLWV2cG4t YWdncmVnYXRpb24tbGFiZWwtMDEuDQogICAgDQogICAgQXJlIHRoZXJlIGV4YW1wbGVzIGluIElF VEYgd2hlcmUgZm9yIE1QTFMgZm9yd2FyZGluZyB3ZSB1c2UgdGhlIElQIHByb3RvIHRvIGRpc3Bh dGNoIGJldHdlZW4gSVB2NC9JUHY2Pw0KICAgIA0KICAgID4gSSB0aGluayBib3RoIGlzc3VlcyBu ZWVkIHRvIGJlIGNvbnNpZGVyZWQsIGhlcmUgaXMgdGhlIHBhcmFncmFwaCBJIHN1Z2dlc3QNCiAg ICA+IA0KICAgID4gICAgICBJZiB0aGUgdHdvIHJvdXRlcyBkbyBub3QgaGF2ZSB0aGUgc2FtZSBB ZGRyZXNzIEZhbWlseSBJZGVudGlmaWVyDQogICAgPiAgICAgIChBRkkpIHZhbHVlLCB0aGVuIHRo ZWlyIHJlc3BlY3RpdmUgUFRBcyBNQVkgY29udGFpbiBhIHNpbmdsZSBsYWJlbCwgDQogICAgPiAg ICAgIEluIHRoaXMgY2FzZSB0aGUgZWdyZXNzIFBFIHdpbGwgaWRlbnRpZnkgdGhlIEFGSSBiYXNl IG9uIHRoZSBJUCBwYXlsb2FkIGhlYWRlci4NCiAgICA+ICAgICAgQWx0ZXJuYXRpdmVseSB0aGVp ciByZXNwZWN0aXZlIFBUQXMgTUFZIGNvbnRhaW4gZGlmZmVyZW50IE1QTFMgbGFiZWwgdmFsdWVz Lg0KICAgID4gICAgICBJbiB0aGlzIGNhc2Ugd2hlbiBhbiBlZ3Jlc3MgUEUgcmVjZWl2ZXMgYQ0K ICAgID4gICAgICBkYXRhIHBhY2tldCB3aXRoIHRoZSBnaXZlbiBsYWJlbCwgdGhlIGVncmVzcyBQ RSBjYW4gaW5mZXIgZnJvbSB0aGUNCiAgICA+ICAgICAgbGFiZWwgd2hldGhlciB0aGUgcGF5bG9h ZCBpcyBhbiBJUHY0IHBhY2tldCBvciBhbiBJUHY2IHBhY2tldC4NCiAgICANCiAgICBUaGlzIHdp bGwgbGVhZCB0byBhbGwgc29ydCBvZiBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4gSWYgeW91IHdh bnQgdG8gdXNlIElQIHByb3RvLCBpdCBuZWVkcyB0byBiZSBzaWduYWxsZWQgc28gdGhlIGluZ3Jl c3MgYXQgbGVhc3Qga25vd3Mgd2hhdCBpcyBleHBlY3RlZC4NCiAgICANCiAgICBUaHgsDQogICAg DQogICAgSWNlLg0KICAgIA0KICAgID4gDQogICAgPiBSZWdhcmRzDQogICAgPiANCiAgICA+IEhv b21hbg0KICAgID4gDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJv bTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElKc2Jy YW5kIFdpam5hbmRzDQogICAgPiBTZW50OiBUaHVyc2RheSwgTWF5IDMxLCAyMDE4IDI6MzEgQU0N CiAgICA+IFRvOiBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHL1NpbmdhcG9yZSkgPGFuZHJl dy5kb2xnYW5vd0Bub2tpYS5jb20+DQogICAgPiBDYzogQklFUiBXRyA8YmllckBpZXRmLm9yZz47 IEJpZGdvbGksIEhvb21hbiAoTm9raWEgLSBDQS9PdHRhd2EpIDxob29tYW4uYmlkZ29saUBub2tp YS5jb20+OyBkcmFmdC1pZXRmLWJpZXItbXZwbkBpZXRmLm9yZzsgYmllci1jaGFpcnNAaWV0Zi5v cmcNCiAgICA+IFN1YmplY3Q6IFJlOiBbQmllcl0gZHJhZnQtaWV0Zi1iaWVyLW12cG4NCiAgICA+ IA0KICAgID4gQW5kcmV3LA0KICAgID4gDQogICAgPj4gQXMgSG9vbWFuIHNhaWQsIHRoZSBNVVNU IHdpbGwgZm9yY2UgZHVwbGljYXRlIGxhYmVscyBhbmQgdW5uZWNlc3NhcnkgaXB2NCBhbmQgaXB2 NiBzZXBhcmF0aW9uLg0KICAgID4gDQogICAgPiBNVVNUIHdpbGwgbWFrZSBzdXJlIHdl4oCZbGwg ZW5kIHVwIHdpdGggaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMsIGFuZCB0aGVyZSBpcyBh IG5lZWQgdG8gdHJlYXQgSVB2NCBhbmQgSVB2NiBkaWZmZXJlbnRseS4NCiAgICA+IA0KICAgID4+ IEl0IGlzIDIwMTggYW5kIHRpbWUgZm9yIHVzIGFzIGluZHVzdHJ5IHRvIHN0b3AgdHJlYXRpbmcg aXB2NCBhbmQgaXB2NiBzZXBhcmF0ZS4NCiAgICA+IA0KICAgID4gVGhhdCBpcyBhIG5vbi1hcmd1 bWVudC4NCiAgICA+IA0KICAgID4+IFdlIG5lZWQgdG8gY2hhbmdlIHRoZSBNVVNULiBFdmVuIFNI T1VMRCBpcyB0b28gc3Ryb25nIHRvIGJlIGhvbmVzdC4gV2Ugc2hvdWxkIHJlYWxseSBzYXkgU0hP VUxEIGZvciBvbmUgbGFiZWwgYW5kIE1BWSBmb3IgdHdvIGFuZCBleHBsYWluIHdoeSAyIGxhYmVs cyBjYW4gIGJlIHVzZWQuIA0KICAgID4+IA0KICAgID4+IDIgbGFiZWxzIGFkZCBjb3N0IG5vdCBv bmx5IGJlY2F1c2Ugb2YgbGFiZWwgc3BhY2UgYnV0IGFsc28gYmVjYXVzZSBvZiBkdXBsaWNhdGlv biBvZiBvcGVyYXRpb25hbCBhbmQgbWFuYWdlbWVudCBjb3N0LiBXZSBzaG91b2QgIGJlIGNsZWFy IG9uIHRoaXMuIA0KICAgID4gDQogICAgPiBFYWNoIFBFIGhhcyAxTSBsYWJlbHMgdG8gaXRzIGRp c3Bvc2FsLCB0aGVyZSBpcyBubyBzaG9ydGFnZSBvZiBsYWJlbHMgaW4gdGhpcyBjYXNlLg0KICAg ID4gDQogICAgPiBJZiB5b3Ugd2FudCB0byBzY2FsZSBkb3duIHRoZSBudW1iZXIgb2YgbGFiZWxz IGluIHRoZSBNUExTIEZJQiBvbiB0aGUgZWdyZXNzLCBjaGVja291dCBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtenpoYW5nLWJlc3MtbXZwbi1ldnBuLWFnZ3JlZ2F0aW9uLWxhYmVs LTAxIFRoaXMgZHJhZnRzIHByb3Bvc2VzIHRvIHVzZSBhIGdsb2JhbCBsYWJlbHMgZm9yIHRoZSBk aXNwb3NpdGlvbiwgc3VjaCB0aGF0IHRoZXJlIGlzIG5vIHBlciBQRSBNUExTIHN0YXRlLiBZb3Xi gJlsbCBlbmQgdXAgd2l0aCB0aGUgbnVtYmVyIG9mIGxhYmVscyBlcXVhbCB0byB0aGUgbnVtYmVy IG9mIFZQTuKAmXMsIHRpbWVzIDIgaWYgYm90aCBJUHY0IGFuZCBJUHY2IGFyZSBlbmFibGVkLiBO b3QgYW4gaXNzdWUuDQogICAgPiANCiAgICA+IFRoeCwNCiAgICA+IA0KICAgID4gSWNlLg0KICAg ID4gDQogICAgPj4gDQogICAgPj4gUmVnYXJkcywNCiAgICA+PiBBbmRyZXcNCiAgICA+PiBTZW50 IGZyb20gbXkgaVBob25lIE91dGxvb2sNCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgID4+IEZyb206IEJpZGdvbGksIEhvb21hbiAoTm9raWEgLSBDQS9PdHRhd2EpIDxo b29tYW4uYmlkZ29saUBub2tpYS5jb20+DQogICAgPj4gU2VudDogVGh1cnNkYXksIE1heSAzMSwg MjAxOCAxOjE3IEFNDQogICAgPj4gU3ViamVjdDogUkU6IFtCaWVyXSBkcmFmdC1pZXRmLWJpZXIt bXZwbg0KICAgID4+IFRvOiBJSnNicmFuZCBXaWpuYW5kcyA8aWNlQGNpc2NvLmNvbT4NCiAgICA+ PiBDYzogRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRy9TaW5nYXBvcmUpIDxhbmRyZXcuZG9s Z2Fub3dAbm9raWEuY29tPiwgPGRyYWZ0LWlldGYtYmllci1tdnBuQGlldGYub3JnPiwgQklFUiBX RyA8YmllckBpZXRmLm9yZz4sIDxiaWVyLWNoYWlyc0BpZXRmLm9yZz4NCiAgICA+PiANCiAgICA+ PiANCiAgICA+PiBIaSBJY2UNCiAgICA+PiANCiAgICA+Pj4gSSBkb27igJl0IHNlZSBhbnkgYmVu ZWZpdCBpbiB0cnlpbmcgdG8gc3VwcG9ydCB0aGlzIHdpdGggYSBzaW5nbGUgbGFiZWwgdmFsdWUu DQogICAgPj4gDQogICAgPj4gVGhlIGJlbmVmaXQgaXMgdGhlIHNhdmluZyBpbiB0aGUgbGFiZWwg c3BhY2UuDQogICAgPj4gDQogICAgPj4gUmVnYXJkcw0KICAgID4+IA0KICAgID4+IEhvb21hbg0K ICAgID4+IA0KICAgID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPj4gRnJvbTog SUpzYnJhbmQgV2lqbmFuZHMgW21haWx0bzppY2VAY2lzY28uY29tXSANCiAgICA+PiBTZW50OiBX ZWRuZXNkYXksIE1heSAzMCwgMjAxOCAxMDo0MiBBTQ0KICAgID4+IFRvOiBCaWRnb2xpLCBIb29t YW4gKE5va2lhIC0gQ0EvT3R0YXdhKSA8aG9vbWFuLmJpZGdvbGlAbm9raWEuY29tPg0KICAgID4+ IENjOiBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHL1NpbmdhcG9yZSkgPGFuZHJldy5kb2xn YW5vd0Bub2tpYS5jb20+OyBkcmFmdC1pZXRmLWJpZXItbXZwbkBpZXRmLm9yZzsgQklFUiBXRyA8 YmllckBpZXRmLm9yZz47IGJpZXItY2hhaXJzQGlldGYub3JnDQogICAgPj4gU3ViamVjdDogUmU6 IFtCaWVyXSBkcmFmdC1pZXRmLWJpZXItbXZwbg0KICAgID4+IA0KICAgID4+IEhvb21hbiwNCiAg ICA+PiANCiAgICA+Pj4gVGhhdCBzYWlkIEkgdGhpbmsgZnJvbSBCSUVSIGFuZCBtdWx0aWNhc3Qg dGVjaG5vbG9neSBwZXJzcGVjdGl2ZSBwdXJlbHksIGFzc2lnbmluZyAyIGxhYmVsIGZvciBpcHY0 IGFuZCBpcHY2IGFkZHJlc3MgZmFtaWx5IGlzIG5vdCBuZWNlc3NhcnkuIE1heWJlIEhXIGxpbWl0 YXRpb25zIHNob3VsZCBiZSBoYW5kbGVkIGJhc2Ugb24gdGhlIGltcGxlbWVudGF0aW9uPyANCiAg ICA+PiANCiAgICA+PiBGb3IgaW50ZXJvcGVyYWJpbGl0eSByZWFzb25zLCB3ZSBzaG91bGQgaGF2 ZSBvbmx5IG9uZSB3YXkgdG8gc3VwcG9ydCB0aGlzLiBZb3UgZG9u4oCZdCB3YW50IHRvIGVuZCB1 cCBpbiBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VuZGluZyByb3V0ZXIgc2VuZHMgdGhlIHBhY2tl dCB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGVncmVzcyByb3V0ZXIgd2lsbCBsb29rIGF0 IHRoZSBJUCBoZWFkZXIsIHdoaWxlIHRoZSBlZ3Jlc3Mgcm91dGVyIHdhcyBleHBlY3RpbmcgdGhl IGxhYmVsIHRvIGlkZW50aWZ5IHRoZSBJUCB2ZXJzaW9uLg0KICAgID4+IA0KICAgID4+IEkgZG9u 4oCZdCBzZWUgYW55IGJlbmVmaXQgaW4gdHJ5aW5nIHRvIHN1cHBvcnQgdGhpcyB3aXRoIGEgc2lu Z2xlIGxhYmVsIHZhbHVlLg0KICAgID4+IA0KICAgID4+IFRoeCwNCiAgICA+PiANCiAgICA+PiBJ Y2UuDQogICAgPj4gDQogICAgPj4gDQogICAgPj4gDQogICAgPiANCiAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBCSUVSIG1haWxpbmcg bGlzdA0KICAgID4gQklFUkBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9iaWVyDQogICAgDQogICAgDQoNCg== From nobody Thu May 31 21:59:03 2018 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0507C127010; Thu, 31 May 2018 21:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 c9RzC-2apYTA; Thu, 31 May 2018 21:58:57 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D2ADC126C0F; Thu, 31 May 2018 21:58:56 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id AC93D9B99225C; Fri, 1 Jun 2018 05:58:51 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 1 Jun 2018 05:58:52 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Fri, 1 Jun 2018 12:58:40 +0800 From: Xiejingrong To: "Jeffrey (Zhaohui) Zhang" , "Dolganow, Andrew (Nokia - SG/Singapore)" , "Bidgoli, Hooman (Nokia - CA/Ottawa)" , IJsbrand Wijnands CC: BIER WG , "draft-ietf-bier-mvpn@ietf.org" , "bier-chairs@ietf.org" Thread-Topic: [Bier] draft-ietf-bier-mvpn Thread-Index: AdP0MVnjVbVRJ4vQTFuo+qYfUw+f3ADz8YkA//8+bACAAHs3AIAABqYAgAArnICAAHM3gP//NUPQgAGp9YD//nqIkA== Date: Fri, 1 Jun 2018 04:58:40 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99A7D017@nkgeml514-mbx.china.huawei.com> References: <9FF3AF9F-7E5A-48DB-9F87-E8ADDAB5790E@nokia.com> <28B0168E-904B-473E-BCDB-294D8C9C9ED2@cisco.com> <3E81C763-360B-4CA4-8234-4F30287E2AC8@cisco.com>, <16253F7987E4F346823E305D08F9115A99A7ABEF@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115A99A7D017nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] draft-ietf-bier-mvpn X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 04:59:01 -0000 --_000_16253F7987E4F346823E305D08F9115A99A7D017nkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks jeffery for the answering about another 'MUST' word for segmented mv= pn. For the question about whether an upstream-assigned VpnLabel should be used= for IPv4 and IPv6, I just mentioned my opinion. (1) RFC8296 use a Proto=3D2 for upstream-assigned packet, but do not di= fferentiate further upstream-assigned IPv4 packet, upstream-assigned IPv6 p= acket, upstream-assigned ETH packet, and so on. (2) The opportunity to differentiate the further payload format is by t= he VpnLabel. (3) If we do not use different VpnLabels for IPv4 and IPv6, then how ab= out the possible ETH payload ? (4) Then we have to deep-detect the format of a payload in data-plane. = It is inefficient and not good I think. (5) The upstream-assigned VpnLabel is the first usage in industry until= BIER ? At least I am not aware any inter-operation problems because of exi= sting implementation. Is anyone aware of ? From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Thursday, May 31, 2018 6:59 PM To: Xiejingrong ; Dolganow, Andrew (Nokia - SG/Sing= apore) ; Bidgoli, Hooman (Nokia - CA/Ottawa) ; IJsbrand Wijnands Cc: BIER WG ; draft-ietf-bier-mvpn@ietf.org; bier-chairs@iet= f.org Subject: RE: [Bier] draft-ietf-bier-mvpn Hi Jingrong, I also have the following in https://tools.ietf.org/html/draft-zzhang-bess-= mvpn-evpn-aggregation-label-01: 2.2.2.3. Alternative to the per-PMSI Label Allocation The per-PMSI label allocation in case of segmentation, whether for S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to be able to label switch traffic w/o having to do IP or MAC lookup in VRFs (the segmentation points typically do not have those VRFs at all). If the label scaling becomes a concern, altertatively the segmenation points could use (C-S,C-G) lookup in VRFs for flows identifyed by the S-PMSIs. This allows the S-PMSIs for the same VPN/ BD to share the a VPN/BD-identifying label that leads to lookup in the VRFs. That label should be different from the label used in the per-PE/region I-PMSIs though, so that the segmentation points can label switch other traffic (not identified by those S-PMSIs). However, this moves the scaling problem from the number of labels to the number of (C-S/*,C-G) routes in VRFs on the segmentation points. I did not realized that you had the following in your email: ? Also I have submitted a new draft to describe why it is important and va= luable to use an alternative forwarding procedure in segmented MVPN, by usi= ng IP lookup instead of requiring Per-Flow Labels. I will add an informative reference to your draft next time when I update m= y draft. I agree with you that for the particular issue of the "MUST" wording in dra= ft-ietf-bier-mvpn, it can stay MUST because the assumption is that segmenta= tion points do label switching. I have not read about the use case that Hoo= man/Adnrew have. Jeffrey From: BIER > On Behalf = Of Xiejingrong Sent: Thursday, May 31, 2018 12:26 AM To: Dolganow, Andrew (Nokia - SG/Singapore) >; Bidgoli, Hooman (Nokia - CA/Ottawa) >; IJsbrand Wijnands > Cc: BIER WG >; draft-ietf-bier-mvpn@iet= f.org; bier-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Hi folks, I have similar question regarding the MUST word in this draft 2.1 about the= Segmented mvpn scenario. One can see at https://www.ietf.org/mail-archive/= web/bier/current/msg02242.html. A word of 'MUST' may be necessary for a method to gain interoperation, but = not necessary or even a block for another method. Maybe a 'MUST do something when using xxxx method' can meet the concerns o= f interoperation and flexibility both. To quote RFC2119 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, Andrew (No= kia - SG/Singapore) Sent: Thursday, May 31, 2018 5:40 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) >; IJsbrand Wijnands > Cc: BIER WG >; draft-ietf-bier-mvpn@iet= f.org; bier-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Ice, As Hooman said, the MUST will force duplicate labels and unnecessary ipv4 a= nd ipv6 separation. It is 2018 and time for us as industry to stop treating= ipv4 and ipv6 separate. We need to change the MUST. Even SHOULD is too str= ong to be honest. We should really say SHOULD for one label and MAY for two= and explain why 2 labels can be used. 2 labels add cost not only because of label space but also because of dupli= cation of operational and management cost. We shouod be clear on this. Regards, Andrew Sent from my iPhone Outlook _____________________________ From: Bidgoli, Hooman (Nokia - CA/Ottawa) > Sent: Thursday, May 31, 2018 1:17 AM Subject: RE: [Bier] draft-ietf-bier-mvpn To: IJsbrand Wijnands > Cc: Dolganow, Andrew (Nokia - SG/Singapore) >, >, BIER WG >, = > Hi Ice > I don't see any benefit in trying to support this with a single label val= ue. The benefit is the saving in the label space. Regards Hooman -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com] Sent: Wednesday, May 30, 2018 10:42 AM To: Bidgoli, Hooman (Nokia - CA/Ottawa) > Cc: Dolganow, Andrew (Nokia - SG/Singapore) >; draft-ietf-bier-mvpn@ietf.org; BIER WG >; bi= er-chairs@ietf.org Subject: Re: [Bier] draft-ietf-bier-mvpn Hooman, > That said I think from BIER and multicast technology perspective purely, = assigning 2 label for ipv4 and ipv6 address family is not necessary. Maybe = HW limitations should be handled base on the implementation? For interoperability reasons, we should have only one way to support this. = You don't want to end up in a situation where the sending router sends the = packet with the assumption that the egress router will look at the IP heade= r, while the egress router was expecting the label to identify the IP versi= on. I don't see any benefit in trying to support this with a single label value= . Thx, Ice. --_000_16253F7987E4F346823E305D08F9115A99A7D017nkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks jeffery for the= answering about another ‘MUST’ word for segmented mvpn.

 

For the question about= whether an upstream-assigned VpnLabel should be used for IPv4 and IPv6, I = just mentioned my opinion.

(1) &nb= sp;   RFC8296 use a = Proto=3D2 for upstream-assigned packet, but do not differentiate further up= stream-assigned IPv4 packet, upstream-assigned IPv6 packet, upstream-assigned ETH packet, and so on.

(2) &nb= sp;   The opportunit= y to differentiate the further payload format is by the VpnLabel.

(3) &nb= sp;   If we do not u= se different VpnLabels for IPv4 and IPv6, then how about the possible ETH p= ayload ?

(4) &nb= sp;   Then we have t= o deep-detect the format of a payload in data-plane. It is inefficient and = not good I think.

(5) &nb= sp;   The upstream-a= ssigned VpnLabel is the first usage in industry until BIER ? At least I am = not aware any inter-operation problems because of existing implementation. Is anyone  aware of ? <= /p>

 

 

From: = Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Thursday, May 31, 2018 6:59 PM
To: Xiejingrong <xiejingrong@huawei.com>; Dolganow, Andrew (No= kia - SG/Singapore) <andrew.dolganow@nokia.com>; Bidgoli, Hooman (Nok= ia - CA/Ottawa) <hooman.bidgoli@nokia.com>; IJsbrand Wijnands <ice= @cisco.com>
Cc: BIER WG <bier@ietf.org>; draft-ietf-bier-mvpn@ietf.org; bi= er-chairs@ietf.org
Subject: RE: [Bier] draft-ietf-bier-mvpn

 

Hi Jingrong,

 

I also have the following in https://tools.ietf.org/html/draft-zzhang-bess-mvpn-evpn-aggregation-label-0= 1:

2.2.2.3<= /b>.&nbs= p; Alternative to the per-PMSI Label Allocation

   The per-PMSI label= allocation in case of segmentation, whether for

   S-PMSI or for per-= PE/Region I-PMSI, is for the segmentation points to

   be able to label s= witch traffic w/o having to do IP or MAC lookup in

   VRFs (the segmenta= tion points typically do not have those VRFs at

   all).  If the= label scaling becomes a concern, altertatively the

   segmenation points= could use (C-S,C-G) lookup in VRFs for flows

   identifyed by the = S-PMSIs.  This allows the S-PMSIs for the same VPN/<= /p>

   BD to share the a = VPN/BD-identifying label that leads to lookup in

   the VRFs.  Th= at label should be different from the label used in the

   per-PE/region I-PM= SIs though, so that the segmentation points can

   label switch other= traffic (not identified by those S-PMSIs).

   However, this move= s the scaling problem from the number of labels to

   the number of (C-S= /*,C-G) routes in VRFs on the segmentation points.

 

I did not realized that you had the fol= lowing in your email:

 

&Oslas= h;  Also I have submitted a new draft to describe why it is imp= ortant and valuable to use an alternative forwarding procedure in segmented= MVPN, by using IP lookup instead of requiring Per-Flow Labels.

 

I will add an informative reference to = your draft next time when I update my draft.

 

I agree with you that for the particula= r issue of the “MUST” wording in draft-ietf-bier-mvpn, it can s= tay MUST because the assumption is that segmentation points do label switching. I have not read about the use case that Hooman/Adnrew = have.

 

Jeffrey

 

From: = BIER <bier-bounces@ietf.org= > On Behalf Of Xiejingrong
Sent: Thursday, May 31, 2018 12:26 AM
To: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>; Bidgoli, Hooman= (Nokia - CA/Ottawa) <hooman= .bidgoli@nokia.com>; IJsbrand Wijnands <ice@cisco.com>
Cc: BIER WG <bier@ietf.org&g= t;; draft-ietf-bier-mvpn@ietf.org; = bier-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

 

Hi folks,

 

I have similar questio= n regarding the MUST word in this draft 2.1 about the Segmented mvpn scenar= io. One can see at https://www.ietf.org/mail-archive/web/bier/current/msg02242.html.<= /o:p>

 

A word of ‘MUST&= #8217; may be necessary for a method to gain interoperation, but not necess= ary or even a block for another method.

 

Maybe a ‘MUST do= something when using xxxx method’  can meet the concerns of int= eroperation and flexibility both.

 

To quote RFC2119<= /o:p>

6. Guidance in the use= of these Imperatives

   Imperativ= es of the type defined in this memo must be used with care

   and spari= ngly.  In particular, they MUST only be used where it is

   actually = required for interoperation or to limit behavior which has

   potential= for causing harm (e.g., limiting retransmisssions)  For

   example, = they must not be used to try to impose a particular method

   on implem= entors where the method is not required for

   interoper= ability.

 

 

From: = BIER [mailto:bier-bounces@ietf.org= ] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Thursday, May 31, 2018 5:40 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>; IJsbrand Wijnands <= ;ice@cisco.com>
Cc: BIER WG <bier@ietf.org&g= t;; draft-ietf-bier-mvpn@ietf.org; = bier-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

 

Ice,

 

As Hooman said, the MUST will f= orce duplicate labels and unnecessary ipv4 and ipv6 separation. It is 2018 = and time for us as industry to stop treating ipv4 and ipv6 separate. We nee= d to change the MUST. Even SHOULD is too strong to be honest. We should really say SHOULD for one label and MAY= for two and explain why 2 labels can  be used. 

 

2 labels add cost not only beca= use of label space but also because of duplication of operational and manag= ement cost. We shouod  be clear on this. 

 

Regards,

Andrew

Sent from my iPhone Outlook

= _____________________________
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Sent: Thursday, May 31, 2018 1:17 AM
Subject: RE: [Bier] draft-ietf-bier-mvpn
To: IJsbrand Wijnands <ice@cisco.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>, <draft-ietf-bier-mvpn@ietf.org>, BIER = WG <bier@ietf.org>, <bier-chairs@ietf.org>

Hi Ice

> I don’t see any benefit in trying to support this with a single = label value.

The benefit is the saving in the label space.

Regards

Hooman

-----Original Message-----
From: IJsbrand Wijnands [mailto:ice@cisco.= com]
Sent: Wednesday, May 30, 2018 10:42 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Cc: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>; draft-ietf-bier-mvpn@ietf.= org; BIER WG <bier@ietf.org>= ; bier-chairs@ietf.org
Subject: Re: [Bier] draft-ietf-bier-mvpn

Hooman,

> That said I think from BIER and multicast technology perspective purel= y, assigning 2 label for ipv4 and ipv6 address family is not necessary. May= be HW limitations should be handled base on the implementation?

For interoperability reasons, we should have only one way to support this. = You don’t want to end up in a situation where the sending router send= s the packet with the assumption that the egress router will look at the IP= header, while the egress router was expecting the label to identify the IP version.

I don’t see any benefit in trying to support this with a single label= value.

Thx,

Ice.

--_000_16253F7987E4F346823E305D08F9115A99A7D017nkgeml514mbxchi_--