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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 06 September 2019 14:35 UTC

Return-Path: <zzhang@juniper.net>
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 16AD2120B8A for <bier@ietfa.amsl.com>; Fri, 6 Sep 2019 07:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 lvNU-FG6QFIJ for <bier@ietfa.amsl.com>; Fri, 6 Sep 2019 07:35:01 -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 C5675120073 for <bier@ietf.org>; Fri, 6 Sep 2019 07:35:01 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x86EYFVD015963; Fri, 6 Sep 2019 07:34:59 -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=1x7pID0Lm8vT5pdG+CZGWIc7OAepKSgeGvNcIejiGKc=; b=RwWQnXYmelSkA0MSjyaJtIH1Acd7tv3aBEnGw/zK4a/mAv8Dpluj2w7OTA6FQa5xIbLr yuxq1faxYqxDQwLcZ2mFHS41DKoICBcTwnMl44/3W8Bdxmj9FtouGfj1sekWF0h1Dma7 DF2NKPkdxwKWqbGUrGRMCGI2owwfq/tdmyCjvoGXQRpiN26cHsMbA1fPJ8yrFU3VupqO GJkn7CeUM1MID6IGD2FIaRmpOf4YD/nKre76MkgdIvzb4ZwY8DhtIBm9b9K/EZiF8lv6 WCieH8KDbFfzKrO4NJH6AJfj5v7xDMKxBH9Z655wJLI+Pjtd6q8EgORWkbdeQPs0jsy9 8A==
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2054.outbound.protection.outlook.com [104.47.46.54]) by mx0a-00273201.pphosted.com with ESMTP id 2uu4kh2p7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Sep 2019 07:34:58 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MyiUbzJPwgdx4ULDhqQuDUxVmOHEtijSssFGnHT+GMArHPaySDFMx0/3fw7JPkpHJUqftF5U8/iNFqQ9N8L3jm5QM7feK7QsvoArp47pPwyOQ/c7wA/W2oEg1QE+tjKLOYuKgsatM4IhvuKNZvKonJN8Gut/uwtdcXpbFmhy/fvZucnKKGIyMxtRRyf2VzRMaiP1rQO+N/TIbFvGZgQmlEsoZkDlp2vGJuESPRM0XTrmO+qNgHm8davMDtgYn+NUP6Jqgm4zgqv8rtHB0OajR4ZUJKrJuRTRsh7V9aOxrEZ26LRpYyemvsGgMpvmma0h8tR++59XRV/pBY7Z8upAGg==
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=1x7pID0Lm8vT5pdG+CZGWIc7OAepKSgeGvNcIejiGKc=; b=KAkC1pJuWQ8To0S6tvGE6g74U96rUrhzDqvGe//+mcIUvg54JwV1ON2ZELwSulRvX8t4WLf7HZqEi1q0kTv3XQh+W+Tl0X88b2ipecBiSjjqcp/WSN4nKU1LrdtiY6woM4C7y9wbsM34ViX5+UDYoSta2B1HfqeaTvfS4aoWdbzNDQ4QJNh6O2VPI/Lb7/SdlZ+tns1rl8X3ASBN3KlvHtQcOPWtH4Ane45Z6Cw63nq08o1hL55XFwedEm5s3FN8RPOah+FIZT6tMCfvTLx452OMW5+6egZoQHc40cBKKYcRNqQtljA9x0JnVbiHu27oZXUyxBEnhYOysH3iWQLYSA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from DM5PR05MB3548.namprd05.prod.outlook.com (10.174.242.153) by DM5PR05MB3212.namprd05.prod.outlook.com (10.173.224.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.5; Fri, 6 Sep 2019 14:34:55 +0000
Received: from DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::210e:da87:a303:3e74]) by DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::210e:da87:a303:3e74%7]) with mapi id 15.20.2263.005; Fri, 6 Sep 2019 14:34:55 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "stig@venaas.com" <stig@venaas.com>
CC: "mankamis@cisco.com" <mankamis@cisco.com>, "iwijnand@cisco.com" <iwijnand@cisco.com>, "bier@ietf.org" <bier@ietf.org>
Thread-Topic: [Bier] Extending IGMP/MLD with BIER sender parameters?
Thread-Index: AQHVY9/UztScpMJ2O0msaypDt97AfqcetY5QgAACYMA=
Date: Fri, 06 Sep 2019 14:34:55 +0000
Message-ID: <DM5PR05MB35481E597ED809F377ED2C1ED4BA0@DM5PR05MB3548.namprd05.prod.outlook.com>
References: CAHANBtJ4fEN73jH0wvqr7oFAaOEMcecUqumKc65_6ic6tukVdg@mail.gmail.com, CAHANBt+fPGd4=Tf1_+G1LLU5K0eVNg47O6WL6BQT4asbcsP2tA@mail.gmail.com <201909051947591462794@zte.com.cn> <DB7PR07MB474511AB76E22FC1185DEE8591BA0@DB7PR07MB4745.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB474511AB76E22FC1185DEE8591BA0@DB7PR07MB4745.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [173.76.169.147]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 67c61fd0-ce75-45d8-86f2-08d732d762df
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM5PR05MB3212;
x-ms-traffictypediagnostic: DM5PR05MB3212:
x-ms-exchange-purlcount: 3
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <DM5PR05MB3212631C1E5C22E9543F6403D4BA0@DM5PR05MB3212.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(39860400002)(346002)(366004)(376002)(478694002)(51444003)(199004)(189003)(316002)(5660300002)(229853002)(2906002)(26005)(25786009)(4326008)(33656002)(6436002)(296002)(66574012)(2501003)(53936002)(2201001)(186003)(6246003)(55016002)(9686003)(54896002)(6306002)(236005)(86362001)(66946007)(66476007)(76116006)(966005)(64756008)(66446008)(3846002)(790700001)(478600001)(486006)(66556008)(6116002)(606006)(14454004)(53546011)(6506007)(8936002)(102836004)(8676002)(110136005)(52536014)(76176011)(7696005)(11346002)(71190400001)(446003)(66066001)(99286004)(71200400001)(476003)(81156014)(81166006)(14444005)(54906003)(74316002)(7736002)(256004)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3212; H:DM5PR05MB3548.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: bgRHshGcwnT1IIlIDCQ8gpA5C78js6YLZQX8qWyqqtkXrQxx6LiOjahG/NwuE92Tsj6xPLlwx/IAKCZoSzYzev4sDJYoC3s40EfnxGPqsx7WmWwkzasL0ZbalOD9zaYnozFvl+B55pDbo+SPixmcaTWR2fzZF+/4OcWphjLuq/oNMi6PaFZG8fA4E4Jr9R55XmNw43wAQDQjVtRD3ywy6oSjzbJibocDY4moIrYaLr1i0KjyusyDkJTtAooZOOQc4Xv1pIrs+/4+zStDzDwCbSms9BugMa6WexyM/6RG8GIajTF9n8fJJ2BQ16GwvCjeLBg5DQuvBIx51+rYaRPZHN1b+PvHgGdHZLNvM2+Y4vOdwJcvhzO9Iv2MbzBLhgxmpziao29F/MJ1dL9aQDGwyhNNXgiwJY9WsITLRyycZG8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM5PR05MB35481E597ED809F377ED2C1ED4BA0DM5PR05MB3548namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 67c61fd0-ce75-45d8-86f2-08d732d762df
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 14:34:55.2079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yJSoX8zLbdS7GKZLcY+++g1qjMCeWzdxcx04GDbtpV31yqFiirQvlpwQuoAjH446vQfzdIW+umzBkk+FdnlozQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3212
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-06_06:2019-09-04,2019-09-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 phishscore=0 mlxscore=0 malwarescore=0 spamscore=0 impostorscore=0 clxscore=1011 adultscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909060154
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/MUZOUIpay40yUWHK1NHCeyCwYJ4>
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, 06 Sep 2019 14:35:04 -0000

That’s why added the information to draft-ietf-bier-pim-signaling (section 3.1.4) 😊
Stig is trying to bring parity to IGMP/MLD signaling.

From: BIER <bier-bounces@ietf.org> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Friday, September 6, 2019 10:25 AM
To: EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; stig@venaas.com
Cc: mankamis@cisco.com; iwijnand@cisco.com; bier@ietf.org
Subject: Re: [Bier] Extending IGMP/MLD with BIER sender parameters?

Just playing the devil’s advocate

How is this different then the PIM case? If we said these info is needed because of HW specific reasons I would imagine it is needed on both protocols.

Regards

Hooman

From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>
Sent: Thursday, September 5, 2019 7:48 AM
To: stig@venaas.com<mailto:stig@venaas.com>
Cc: bier@ietf.org<mailto:bier@ietf.org>; iwijnand@cisco.com<mailto:iwijnand@cisco.com>; mankamis@cisco.com<mailto:mankamis@cisco.com>
Subject: Re: [Bier] Extending IGMP/MLD with BIER sender parameters?


Hi Stig,



IMO it does make sense.



Sandy


原始邮件
发件人:StigVenaas <stig@venaas.com<mailto:stig@venaas.com>>
收件人:Mankamana Mishra (mankamis) <mankamis@cisco.com<mailto:mankamis@cisco.com>>;
抄送人:IJsbrand Wijnands <iwijnand@cisco.com<mailto:iwijnand@cisco.com>>;BIER WG <bier@ietf.org<mailto:bier@ietf.org>>;
日 期 :2019年08月31日 06:27
主 题 :Re: [Bier] Extending IGMP/MLD with BIER sender parameters?
_______________________________________________
BIER mailing list
BIER@ietf.org<mailto:BIER@ietf.org>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!8WoA6RjC81c!QJ7wKOYMZJTp--_7kMOfhoLJKO3AQiJE7wobo-_NG_naf3Y3Nrcjd1tIWPs5nxI9$>
Agree. That is why I added an Extension Type field.

Stig


On Fri, Aug 30, 2019, 15:05 Mankamana Mishra (mankamis) <mankamis@cisco.com<mailto:mankamis@cisco.com>> wrote:
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<mailto: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<mailto: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<mailto: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<mailto:BIER@ietf.org>
>> https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!8WoA6RjC81c!QJ7wKOYMZJTp--_7kMOfhoLJKO3AQiJE7wobo-_NG_naf3Y3Nrcjd1tIWPs5nxI9$>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org<mailto:BIER@ietf.org>
> https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!8WoA6RjC81c!QJ7wKOYMZJTp--_7kMOfhoLJKO3AQiJE7wobo-_NG_naf3Y3Nrcjd1tIWPs5nxI9$>