Re: [bess] [pim] WGLC: draft-ietf-bier-mvpn-05

"Swadesh Agrawal (swaagraw)" <swaagraw@cisco.com> Wed, 21 June 2017 20:18 UTC

Return-Path: <swaagraw@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96220129484; Wed, 21 Jun 2017 13:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 Wr991v9rb9ej; Wed, 21 Jun 2017 13:18:49 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1371294A2; Wed, 21 Jun 2017 13:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3576; q=dns/txt; s=iport; t=1498076326; x=1499285926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+pvImV7TwXvg05i+UyLFbDt01FiKW0SVszfiUEIkPjs=; b=Mk5ITaHMva0VCAtAJOKxvK/AAkfO3wIuKXvm72FqLHO0mwygoyxV5VxI kSiTKbv54jb5t+C7T10lKOLSJJWNw1R2YLmpEl+hYzNnzs9S45gCzNjtL eGZOkw+gF9RbpPK6Y2WikA2Mls3COIV9ZwcSYECuTagjHixoUoD4oEyWV U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAABW00pZ/4MNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNYYoENB4NlihmRXZV4ghEhC4V4AhqCXD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEBAQMBASEROgsQAgEIGAICJgICAiULFRACBAENBR+KDRCqaYImi14BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYELhWKBYCuCeYRCKBeCezCCMQWeYgKTYJIOlRA?= =?us-ascii?q?BHziBCnQVSRIBhnx2iF2BDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.39,370,1493683200"; d="scan'208";a="250458970"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 20:18:45 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5LKIjw2018826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2017 20:18:45 GMT
Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Jun 2017 15:18:44 -0500
Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1210.000; Wed, 21 Jun 2017 15:18:44 -0500
From: "Swadesh Agrawal (swaagraw)" <swaagraw@cisco.com>
To: Eric C Rosen <erosen@juniper.net>, Stig Venaas <stig@venaas.com>, "Greg Shepherd" <gjshep@gmail.com>
CC: "bier@ietf.org" <bier@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] [pim] WGLC: draft-ietf-bier-mvpn-05
Thread-Index: AQHS6sfxMwFeoJ4KnECB+RPTXGDFU6IvnxaAgAAA/AA=
Date: Wed, 21 Jun 2017 20:18:44 +0000
Message-ID: <286DA533-EB53-4D90-A478-EE31DA5D0837@cisco.com>
References: <CABFReBoN6YbJr+fqigLuWBStUS2-4rfHuVKONSJdNU4RRK9qaw@mail.gmail.com> <CAHANBtL5s9+vh8qzc8dBuYP3YbQMV6znfpoPqb+NKj8BJT=QYA@mail.gmail.com> <d711f2a8-df72-246a-9105-d1944679cc56@juniper.net> <492F2A90-C3B0-437E-A0CA-420B7E89883C@cisco.com> <39643fa5-d3b3-f9dd-3f45-7d110e5cfbcf@juniper.net> <BBA04AC3-3017-4D03-9AEB-3517204DDC22@cisco.com>
In-Reply-To: <BBA04AC3-3017-4D03-9AEB-3517204DDC22@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.32.198.22]
Content-Type: text/plain; charset="utf-8"
Content-ID: <21076F0034AECC4BB3F3F7DE6A2E9BAE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/pppyicOfGHtqcftaPms6wWa5JTM>
Subject: Re: [bess] [pim] WGLC: draft-ietf-bier-mvpn-05
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jun 2017 20:18:52 -0000

We won’t need signaling. It will depend on ingress PE. If ingress PE does not send ipv6 explicit NULL, it should announce different upstream assigned label for afi.
Egress PE should work in both scenario without any signaling of what ingress PE has implemented.

Regards
Swadesh 

On 6/21/17, 1:15 PM, "BESS on behalf of Swadesh Agrawal (swaagraw)" <bess-bounces@ietf.org on behalf of swaagraw@cisco.com> wrote:

    Rosen MLDP MVPN(vpnid) and many other profiles have same tunnel for v4 and v6. I think it’s pretty standard to send ipv6 traffic with ipv6 explicit NULL.
    It was never required to be explicitly mention in RFC. 
    Mandating to have different upstream assign label does not look correct. Should mention both option and leave it to implementation. 
    
    Regards
    Swadesh
    
    On 6/21/17, 12:52 PM, "Eric C Rosen" <erosen@juniper.net> wrote:
    
        On 6/21/2017 2:22 PM, Swadesh Agrawal (swaagraw) wrote:
        > It can be achieved by having ipv6 explicit NULL in data path. We may not need different label to identify AFI.
        
        We could have a rule saying that if MVPN payload packet is an IPv6 
        packet, then v6 explicit null must be pushed before the 
        upstream-assigned label is pushed.
        
        But hen someone would claim that we're favoring v4 over v6, and the rule 
        should be that if the MVPN payload is a v4 packet, v4 explicit null must 
        be pushed before the upstream-assigned label is pushed.
        
        If we don't have one rule or the other, we risk multi-vendor interop 
        problems.
        
        People will disagree about which rule is best, so someone will claim 
        that we need a configuration item to say which payload type is the 
        default and which requires explicit null.
        
        Then someone would say that we need to add to the signaling an 
        indication of which payload type is the default and which requires 
        explicit null.
        
        Then someone would say that the root cause of the problem is the lack of 
        a protocol type field in MPLS, and we should fix the root cause instead 
        of using explicit null.
        
        So although your observation is absolutely correct, I think it's simpler 
        if we just use different upstream-assigned labels for the different AFIs.
        
        
        
        
    
    _______________________________________________
    BESS mailing list
    BESS@ietf.org
    https://www.ietf.org/mailman/listinfo/bess