IETF Logo Mail Archive

Re: [Bier] One specific transition churn ...

"Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com> Sat, 27 September 2014 13:27 UTC

Return-Path: <naikumar@cisco.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875CE1A1B11 for <bier@ietfa.amsl.com>; Sat, 27 Sep 2014 06:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level:
X-Spam-Status: No, score=-15.286 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 9fXhDNAbhhha for <bier@ietfa.amsl.com>; Sat, 27 Sep 2014 06:27:02 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F091A1B18 for <bier@ietf.org>; Sat, 27 Sep 2014 06:27:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14369; q=dns/txt; s=iport; t=1411824422; x=1413034022; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=afTwGhV1PFj7i2x0hIGhtpA9cUb0gwXUkJ/BZpxbMwc=; b=G7B4ofOUIu3eNLG0qjO4XqlikZNLuxeIKaJ/QBuOFXSRKvDlcSZSqSeB /3+ORYRzfMFlGltA6b1MYV0zZtpxNGurC5tZSqjNMiNQIh7bfuDJH1dx9 mpPbfZwTBntp3epkD0TMdqbd8UZ7oy77rKx91hcrzddTbY+fWE7rao3oJ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFADy6JlStJA2F/2dsb2JhbABfgkhGU1uCfcURgW2HTgIZZhYBe4QDAQEBBCNWEAIBCBEDAQIoAwICAjAUCQgCBAENBYg+DakslXgBF5ANEQeCeIFTBZFjhDqHCYFik3qDY2yBSIECAQEB
X-IronPort-AV: E=Sophos; i="5.04,609,1406592000"; d="scan'208,217"; a="81776200"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 27 Sep 2014 13:27:01 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8RDR1dl025409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 13:27:01 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.166]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Sat, 27 Sep 2014 08:27:00 -0500
From: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2cgHxaoM20tboE6sjh+V1W/s35wUOjWAgADQbIA=
Date: Sat, 27 Sep 2014 13:27:00 +0000
Message-ID: <D04C3174.70BA9%naikumar@cisco.com>
References: <CA+b+ERmNEnhTDjPXkAs6vNqC8_UBNid8gFwRsb1aUKZgzDLQLg@mail.gmail.com> <EE6E4363-E19D-44A1-ACDA-6C5A16C41DB3@cisco.com> <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se> <CA+b+ERkDSxtkX8j9o0AUQw0STPbNjhjr+OFZxDpEy0RkAOx_qg@mail.gmail.com> <DA5C56DD-22F5-4E0C-A7BA-103E84749D69@cisco.com> <CA+b+ERn+5BbucSpOQzv_Wfps7oYbV8RGJfHN4cnMzP4sSSBgxQ@mail.gmail.com>
In-Reply-To: <CA+b+ERn+5BbucSpOQzv_Wfps7oYbV8RGJfHN4cnMzP4sSSBgxQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.21.96.121]
Content-Type: multipart/alternative; boundary="_000_D04C317470BA9naikumarciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/P2AihJHmQqsDjIPEVmdw2zQ_QJ0
Cc: "Eric Rosen (erosen)" <erosen@cisco.com>, "bier@ietf.org" <bier@ietf.org>, Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: Re: [Bier] One specific transition churn ...
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sat, 27 Sep 2014 13:27:06 -0000

Hi Robert,

Take SPRING IPv6 ... why extension header could not list all egress nodes as well as ​

​list of transit BFRs where replication to said egress nodes is to take place ?

Or going step further .. send list of BFRs (like SNs) and program the required replication out of band (from controller) avoiding carrying bitstring or network protocols to build a tree to accomplish easy way of optimal replication ? Is keeping multicast groups such an overkill for even an average network device these days ?

<Nagendra> BiER doesn’t need any IGP calculation for every multicast group joined by BFER. Infact, it simply leverage the unicast tale and populate the BIFT table. So instead of programming different transit nodes for optimal replication for every new group, I think it is simple to have the tree built once (which doesn’t need additional SPF other than unicast calculation) and still achieve optimal forwarding.

Last but not least how is said bitstring to be honored, accepted and used between domains ? What NNI is to be agreed for BIER to make it usable between AS under different administrations ?

<Nagendra> I think this is slightly covered in below draft,

http://tools.ietf.org/html/draft-rosen-l3vpn-mvpn-bier-00

Thanks,
Nagendra

From: "robert@raszuk.net<mailto:robert@raszuk.net>" <robert@raszuk.net<mailto:robert@raszuk.net>>
Date: Friday, September 26, 2014 at 5:01 PM
To: IJsbrand Wijnands <ice@cisco.com<mailto:ice@cisco.com>>
Cc: "bier@ietf.org<mailto:bier@ietf.org>" <bier@ietf.org<mailto:bier@ietf.org>>, "Eric Rosen (erosen)" <erosen@cisco.com<mailto:erosen@cisco.com>>, Antoni Przygienda <antoni.przygienda@ericsson.com<mailto:antoni.przygienda@ericsson.com>>
Subject: Re: [Bier] One specific transition churn ...

BIER is totally unrelated to SPRING, completely different data-plane!

​Perhaps it is today, but the question is - does it need to be a yet one more completely new data-plane ?

Take SPRING IPv6 ... why extension header could not list all egress nodes as well as ​

​list of transit BFRs where replication to said egress nodes is to take place ?

Or going step further .. send list of BFRs (like SNs) and program the required replication out of band (from controller) avoiding carrying bitstring or network protocols to build a tree to accomplish easy way of optimal replication ? Is keeping multicast groups such an overkill for even an average network device these days ?

Last but not least how is said bitstring to be honored, accepted and used between domains ? What NNI is to be agreed for BIER to make it usable between AS under different administrations ?

Thx,
r.

v2.23.0 | Report a Bug | By Email