Re: [Bier] Extending IGMP/MLD with BIER sender parameters?

"Mankamana Mishra (mankamis)" <mankamis@cisco.com> Fri, 30 August 2019 22:05 UTC

Return-Path: <mankamis@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 EFD45120803 for <bier@ietfa.amsl.com>; Fri, 30 Aug 2019 15:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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 header.b=RTE3sa+C; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VWVlnAYL
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 pxaeRO6t6igj for <bier@ietfa.amsl.com>; Fri, 30 Aug 2019 15:05:29 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB1E120077 for <bier@ietf.org>; Fri, 30 Aug 2019 15:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4411; q=dns/txt; s=iport; t=1567202729; x=1568412329; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c9ITIvo8T4X4Wg+7s2P7FlfcGzFvMJdTh18dZNEINmw=; b=RTE3sa+CvuO27uYotrmscVlzJOHNKAoPBbFkbtqSCEnamqYcXe//hoAH I4WWYmU2+37BnVLn1R+nQFhrzYRUXcJ3EIyP7hY9szOYKIGNeSBC15A4S pdReJft7iDS0ex6OzoXh003aWv0Lqi2CsEeG6354LueRVuxsvUe1euhe6 w=;
IronPort-PHdr: 9a23:tl4fpxVmhRan1tvhUOvP1EEgVEfV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtank/FcJBXVpk5FmwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AgAADTnGld/5xdJa1mGQEBAQEBAQEBAQEBAQcBAQEBAQGBVgEBAQEBAQsBgURQA21WIAQLKodoA4p0gjcll2yCUgNUCQEBAQwBARgLCgIBAYQ/AoJgIzcGDgIDCAEBBAEBAQIBBgRthS4MhUoBAQEBAgEBARAoBgEBLAsBBAsCAQgYHhAnCyUCBAENBSKDAAGBagMODwECDKMoAoE4iGGCJYJ8AQEFgkeCTBiCFgMGgTQBhHyGexiBQD+BEScME4JMPoJhAQGBYYM9giaMTZ9GCoIflFcblSKDQI1ymEQCBAIEBQIOAQEFgWYigVhwFTsqAYJBgkKDcoUUhT9ygSmODwEB
X-IronPort-AV: E=Sophos;i="5.64,447,1559520000"; d="scan'208";a="623519357"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 22:05:28 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7UM5SEB013853 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 22:05:28 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 17:05:27 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 17:05:26 -0500
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 18:05:25 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VK5DTljcsIcLM6IFpfNv6NlOWfe20VsBTbIiBgJVOpQZuBD7C7eJNZNpzFAnac39YYwnFu4gm2w7U2oHj7+nbiUMG+PWb/Bmh9YRasxcpRYbQGC+2ddt3nHJ0hLvZDIUirJohmXTztoup7jCCSt1iP9UTjcvNqGqBLlm7LQ/s0N0RdwKcV/+x1k/xF5lwE9e57Wi5WWvKiLdB6+6Xwjafgo3w2hthFS4nhafa7lnQyKH3p/f8HM5xWwYkns/ons/BE5yh8jaJIgKDpbDqwaccV8K87WTMmx9d9T5hYyu2mXJXLULX9dRYpe5RTNzzhcPlaxn1CWYJHkjsRVe6nOgRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lB81RvcinPpI8DwMpC1z+u1eBk5vjB2g787ShQ5CWR4=; b=R97hkMSVEhbg6xGRcVNDPjp7wloK+D64QY5ghpzqomOL4R2qHZ/Jy1FEtvKtvcHxfNz1GUbddjSf+EuTTWBm84v2xblHN1NdorpyvG5tzLTAHKcOkSnhkiF0HF/ZUiXkNz5ftjUnE6oaRDJJpTKcOvwpdoKxxeEO/y/O9d1/pSVLtmDei3tm9Hgr7fn/ZdoIQnpSeSFX7aMaQtObuCo3jCdUoEU/+zO/1RJVZCfYsZAjh10QG8f7+JjzEVBd/mKie8AlD6JK6cT3VztBd8LrhZyPzJ/ZbVFPWLtj1CBvMfCZayFNg/XeGKfaMAo/BJUcfff6WnGm5oZROUiMKNzBtQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lB81RvcinPpI8DwMpC1z+u1eBk5vjB2g787ShQ5CWR4=; b=VWVlnAYLe7EE9/gbHfaJd868DPeqIDgokYelrIIcMSX3fH48kM7dl3hCtguXx+9LnT8IfEufU/9Qf7h0C3JjFwfkFgFB3vI38ZA6HHO02dD2fZxTXbvfUnCZ0m6t0QQkFxif//m8PKqNWWl3/Wya+MSo2QFmvy8xSHSBLEsAsHE=
Received: from BYAPR11MB3685.namprd11.prod.outlook.com (20.178.237.158) by BYAPR11MB2853.namprd11.prod.outlook.com (52.135.228.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Fri, 30 Aug 2019 22:05:24 +0000
Received: from BYAPR11MB3685.namprd11.prod.outlook.com ([fe80::cc1b:6af7:8174:e33a]) by BYAPR11MB3685.namprd11.prod.outlook.com ([fe80::cc1b:6af7:8174:e33a%6]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 22:05:24 +0000
From: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
To: "IJsbrand Wijnands (iwijnand)" <iwijnand@cisco.com>, Stig Venaas <stig@venaas.com>
CC: BIER WG <bier@ietf.org>
Thread-Topic: [Bier] Extending IGMP/MLD with BIER sender parameters?
Thread-Index: AQHVV3nXkyOkGEfO1U+V+uCwhAEjKqcPl10AgACzyACABAPxgA==
Date: Fri, 30 Aug 2019 22:05:24 +0000
Message-ID: <92040486-968A-4F92-B093-E32DB973BA1B@cisco.com>
References: <CAHANBtJ4fEN73jH0wvqr7oFAaOEMcecUqumKc65_6ic6tukVdg@mail.gmail.com> <CAHANBtJCdkZGNC4O6UY45np+q1ePX+3L+0qpkFt2epa1iPyoTQ@mail.gmail.com> <929D2C29-0AC8-46B6-9A90-01F4218C501E@cisco.com>
In-Reply-To: <929D2C29-0AC8-46B6-9A90-01F4218C501E@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=mankamis@cisco.com;
x-originating-ip: [2001:420:30d:1254:ec7a:a2b7:6ff2:8ec]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 86791451-6480-4077-5d80-08d72d962879
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2853;
x-ms-traffictypediagnostic: BYAPR11MB2853:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB2853812B36B83AB15F8F31D9DFBD0@BYAPR11MB2853.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0145758B1D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(51444003)(189003)(199004)(478694002)(2616005)(486006)(478600001)(71190400001)(25786009)(7736002)(229853002)(305945005)(316002)(2906002)(6506007)(8676002)(81166006)(81156014)(256004)(66574012)(14454004)(14444005)(4326008)(99286004)(66446008)(64756008)(76116006)(66476007)(66946007)(66556008)(76176011)(186003)(6306002)(476003)(53546011)(6512007)(966005)(5660300002)(102836004)(46003)(71200400001)(36756003)(6486002)(8936002)(6246003)(6436002)(446003)(86362001)(110136005)(53936002)(6116002)(33656002)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2853; H:BYAPR11MB3685.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: +5Iv8WbsJiPEHDU/6eZSzKaG4zWjpy+OGwftY6naADQ/a0XdpC/cKIPWba/CR1QlnMiGm0L1zQBNPnnO5BStXPxTKiwv9DFW9BoXQ/gR8t8qSKjp7tJ8Xtt9UOLh6Y520odyx3g9hJD+OU1C0lOSMRDPyjvrEAOS4jvIC0tyN2xUcEy/aLxciEsKapVthsGkRGeanvsSwXTbg0xoO+RUG8jSNyAnBEBSmwyYeuCfHPvLQJQRhcZlqFLJt/aaNVjLQAY7U/tmi3gOC9MhpfHtknFCvNr/nwhQHqLc00jQWX2Jcqzl6Xeh7sEfCyY3WaYOAi+ZfKpOeBUs4e4wD9amFB5q6O06aQAaixaeCfcEHhs7HBPvyQQDLiLSdHoMpCGRYupBRs0ayFz1lXuQtuLJNAcsfRuAz3pR8F8jYyOSxAQ=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EF87371510634E4AB138F3F35594B52F@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 86791451-6480-4077-5d80-08d72d962879
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 22:05:24.1942 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tSQzEqS3JtRi/aNBrDLl3MO1svReqOvVU9B+g46bpYniNi+MNpOXm9husYcUpimGx0zgDQ6Ojrr7klHqx7i7CA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2853
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/GmfHzqQWb5D4mAImVv-Yw-CERRA>
Subject: Re: [Bier] Extending IGMP/MLD with BIER sender parameters?
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: Fri, 30 Aug 2019 22:05:32 -0000

Hi Stig, 
if we plan to extend IGMP RFC, then may be it would be good to provision something which can be used even in future. Using additional data as is might solve the problem for now but what if something new comes in future which want to use same set of data. So may be we can add some extra field as type which can indicate what is the additional data carrying. 

Mankamana 

> On Aug 28, 2019, at 1:46 AM, IJsbrand Wijnands (iwijnand) <iwijnand@cisco.com> wrote:
> 
> Hi Stig, I think that is a good idea..
> 
> Sent from my iPhone
> 
>> On 28 Aug 2019, at 00:03, Stig Venaas <stig@venaas.com> wrote:
>> 
>> Hi
>> 
>> Anyone got any thoughts on this? Is it a good idea, or just try to
>> publish what we have?
>> 
>> Thanks,
>> Stig
>> 
>>> On Tue, Aug 20, 2019 at 10:06 AM Stig Venaas <stig@venaas.com> wrote:
>>> 
>>> Hi
>>> 
>>> As I mentioned in the last meeting, it may be good to store BIER sender
>>> info in IGMP/MLD messages, like BIER prefix, BFR-ID and sub-domain.
>>> I would like to hear your thoughts on this.
>>> 
>>> Currently in the IGMP/MLD overlay we require that the source address of
>>> reports is the BFR prefix, allowing the BFR-ID of the sender to be
>>> derived assuming we know the sub-domain. However we have no good
>>> way of knowing the sub-domain. Alternatively one could get this information
>>> from the BIER header, but this information is often not visible to upper layer
>>> protocols.
>>> 
>>> For pim we decided to add a join attribute with sub-domain-id, BFR-ID
>>> and BFR-prefix. This is similar to the PMSI tunnel attribute defined
>>> for MVPN containing
>>> 
>>>         +---------------------------------+
>>>         |  Sub-domain-id (1 octet)        |
>>>         +---------------------------------+
>>>         |  BFR-id (2 octets)              |
>>>         +---------------------------------+
>>>         |  BFR-prefix (4 or 16 octets)    |
>>>         +---------------------------------+
>>> 
>>> Do you think we should extend IGMP/MLD messages over BIER to
>>> include this information?
>>> 
>>> Currently IGMP and MLD RFCs have some text about additional data.
>>> E.g. RFC 3376 in 4.1.10 and 4.2.11. For reports it says:
>>> 
>>> 4.1.10. Additional Data
>>> 
>>>  If the Packet Length field in the IP header of a received Query
>>>  indicates that there are additional octets of data present, beyond
>>>  the fields described here, IGMPv3 implementations MUST include those
>>>  octets in the computation to verify the received IGMP Checksum, but
>>>  MUST otherwise ignore those additional octets.  When sending a Query,
>>>  an IGMPv3 implementation MUST NOT include additional octets beyond
>>>  the fields described here.
>>> 
>>> Hence I think we could define an extended message for use with BIER.
>>> Existing implementations (non-BIER routers) would ignore any additional
>>> octets. While routers implementing IGMP/MLD over BIER can parse the
>>> additional data. I would suggest that the extra data is like the PMSI
>>> tunnel attribute above. However, I also think there is a chance that IGMP
>>> messages might have additional data for other reasons in the future, so I
>>> think we should define a type, so we might add something like:
>>> 
>>>         +---------------------------------+
>>>         |  Extension type (1 octet)       |
>>>         +---------------------------------+
>>>         |  Sub-domain-id (1 octet)        |
>>>         +---------------------------------+
>>>         |  BFR-id (2 octets)              |
>>>         +---------------------------------+
>>>         |  BFR-prefix (4 or 16 octets)    |
>>>         +---------------------------------+
>>> 
>>> where say extension type 1 means BIER with the format above. Any
>>> other use of IGMP/MLD additional data should get its own type,
>>> so that a BIER IGMP/MLD router can ignore it (by checking for
>>> the BIER extension type).
>>> 
>>> What do you think? Should we do this?
>>> 
>>> Thanks,
>>> Stig
>> 
>> _______________________________________________
>> 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