IETF Logo Mail Archive

Re: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

IJsbrand Wijnands <ice@cisco.com> Wed, 10 October 2018 20:31 UTC

Return-Path: <ice@cisco.com>
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 D6652130FAB for <bier@ietfa.amsl.com>; Wed, 10 Oct 2018 13:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.957
X-Spam-Level:
X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 k9hCvKaSw0TG for <bier@ietfa.amsl.com>; Wed, 10 Oct 2018 13:31:13 -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 2F1931292F1 for <bier@ietf.org>; Wed, 10 Oct 2018 13:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2539; q=dns/txt; s=iport; t=1539203472; x=1540413072; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KJbKjepbHfiKdBI/R/ZayiEF/ctO4rMj4psuxAlXmQc=; b=lZJS2wAuP+pkNv9FrOECSJTP3XTDo4cPWCZ7p1YnEF35Ljybu7XPhxG1 ztaebfoClVoehVxiagi7lwWQ1huFUbxd5DwpbqwzxMKJJsKHt3Y/heJkF x6GvsKbdh4RON9GMLC5nEOqd0tqbZ0An6bIXOqSjvQneV81PDFQxXCq5e 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACfYL5b/xbLJq1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgmltEiiDdYgVX4wjAQEBAQEGgRAliH+Nf4F6CwEBI4RJAoRxNA0NAQMBAQIBAQJtHAyFOQEBAQECASNWBQcECxEEAQEBAgImAgJPCAYTG4MGAYF0BQgPpj2BLoQzBz2EYgWBC4pHeYEHgRInDBOCTIMbAgIBAYFQDYMBMYIEIgKeBgmGUYYng1kXgXGOGowwhmWCUAIEBgUCFIFCOIFVTSMVZQGCQT6BaAUSERiIMYVAPTCKE4JLAQE
X-IronPort-AV: E=Sophos;i="5.54,365,1534809600"; d="scan'208";a="7146944"
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; 10 Oct 2018 20:31:10 +0000
Received: from ams-iwijnand-8813.cisco.com (ams-iwijnand-8813.cisco.com [10.60.202.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9AKV9VY011440 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Oct 2018 20:31:10 GMT
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: IJsbrand Wijnands <ice@cisco.com>
In-Reply-To: <CY1PR05MB23005F944881AEE61392959ED4E00@CY1PR05MB2300.namprd05.prod.outlook.com>
Date: Wed, 10 Oct 2018 22:31:09 +0200
Cc: Antoni Przygienda <prz@juniper.net>, "bier@ietf.org" <bier@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <533DB2F1-E4C0-4DE0-8920-A4B9C0A4CE57@cisco.com>
References: <497C28F0-AF6B-48B5-A979-165C82AF27E1@juniper.net> <95A70C7D-6E74-473A-BF52-750BBE5BC994@cisco.com> <CY1PR05MB2300D2A2021E7F4FF48AFF65D4E00@CY1PR05MB2300.namprd05.prod.outlook.com> <FB5031E7-93E8-496B-AB32-F16B3A0C9EB7@cisco.com> <6093F946-F9C0-4298-83B3-1948AB918D30@cisco.com> <CY1PR05MB23005F944881AEE61392959ED4E00@CY1PR05MB2300.namprd05.prod.outlook.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
X-Mailer: Apple Mail (2.3445.5.20)
X-Outbound-SMTP-Client: 10.60.202.84, ams-iwijnand-8813.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/KaNYjAOq4W7hTROCNPR2hE1liiA>
Subject: Re: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 20:31:23 -0000

Hi Jeffrey,

I’m proposing to remove this section of the draft:

***
The payload after BIER header is IPv4 or IPv6 (i.e., the Proto
field in the BIER header is 4 or 6).
Notice that in this case the Destination Address in the IPv4/IPv6
header must be in the address space for the BIER layer.
***

If that is your thinking too, we are in sync.


Thx,

Ice.

> On 10 Oct 2018, at 21:52, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:
> 
> Hi Ice,
>  
> I think we're on the same page - I said the following earlier:
>  
> > More importantly, I would expect MVPN/GTM/EVPN kind of deployment is the more appropriate scenario, where there will be a VPN/BD label used, which can associate the packets with a virtual RPF interface. If we're just transitioning an existing PIM deployment to using BIER, then there is no explicit set of edge routers (the premise of PHP is really that some edge routers, like VPN/EVPN PEs, cannot be upgraded to support BIER forwarding) - we can just run PIM if a router does not support BIER yet.
>  
> Notice the red text above – I am assuming you’re talking about BGP based overlay signaling.
>  
> Jeffrey
>  
> > -----Original Message-----
> > From: IJsbrand Wijnands <ice@cisco.com>
> > Sent: Wednesday, October 10, 2018 12:18 PM
> > To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> > Cc: Antoni Przygienda <prz@juniper.net>; bier@ietf.org
> > Subject: Re: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-
> > zzhang-bier-php/
> >
> > Jeffrey,
> >
> > >> The egress RPF would either disable the RPF check or specify any "core
> > interfaces" to be expected incoming interface. This is similar to using P2MP
> > tunnels to send multicast traffic w/o signaling (a deployment scenario that has
> > been supported by certain vendors already).
> >
> > Thinking a bit more about this.. Disabling the RPF check I don’t like too much.
> > Considering that modifications to the control-plane are allowed, it would be a
> > good deployment practise to *always* advertise a downstream label, also for
> > the global table scenario, maybe even make it mandatory for this solution...
> > That way at least you can map the incoming interface to the BIER Virtual
> > interface, which I think is good enough. Or, define BIER_IPV4_EXPLICIT_NULL
> > and BIER_IPV6_EXPLICIT_NULL if we can get it. Something to consider..
> >
> > Thx,
> >
> > Ice.

v2.23.0 | Report a Bug | By Email