Return-Path: 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 DEAB7120110; Thu, 9 May 2019 11:46:17 -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, HTML_MESSAGE=0.001, 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 header.b=LDUVXgbH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JcM33NWg 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 tHrU643SLK2v; Thu, 9 May 2019 11:46:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122671200B9; Thu, 9 May 2019 11:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9008; q=dns/txt; s=iport; t=1557427574; x=1558637174; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=axG8WH5hJ4Ol4Zsg+ZoVCAUuy0pjwY+b/H7wYBoWT50=; b=LDUVXgbHMreJcwST4rFucoi9NkgYOImSpWUrPWz07XFv+m5pwuB+cOA1 Pezc+0WoIyZ/CiI/RMweW2hy+Ed4RJzifwsQ8L+ijFshiGAkjEIOXs0EU ogxEtXgirlbu9pKBErRbdUO3XG4bMhkojUXHqtI7AvHbpNLYgjum4wgKj 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A7lQvhxcNl98IhDhunOVCaI1JlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aiU8H81HVURN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAACydNRc/5hdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEOL1ADaVUgBAsoh1gDhFKKK5UvhE2BLoEkA1QJAQE?= =?us-ascii?q?BDAEBGAEMCAIBAYRAAoIIIzQJDgEDAQEEAQECAQRtHAyFSwIEAQEQLgEBLAs?= =?us-ascii?q?BDwIBCA4xBycLFBECBA4FIoMAAYEdTQMdAQIMoiICgTWIX4IggnkBAQWFBRi?= =?us-ascii?q?CDwMGgTIBi04XgUA/gREnH4JMPoJhAQECAYILgw+CJpIolDxlCQKCCYYdjDc?= =?us-ascii?q?bghCGRo0DknKOKgIEAgQFAg4BAQWBTziBV3AVGiEqAYJBgg+Db4UUhT9yAQG?= =?us-ascii?q?BJ45WAQE?= X-IronPort-AV: E=Sophos;i="5.60,450,1549929600"; d="scan'208,217";a="560635552" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2019 18:46:13 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x49IkDpm002611 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 18:46:14 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 13:46:13 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 14:46:04 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 May 2019 14:46:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ID5o6Wh/4DX1MCtnEOobegvM0JbVfhHB8lcRkVx/T8A=; b=JcM33NWgIHB9kI7wib42oNwPmNsoOn2FTYskPgVv3BCZtXaWvfaYHSEmzRqD9/IWO7NecxKOrhxbxa8kX+LOIgb+ywnZutid0cszsBrhgw7nhd6V0xqtPXqFZsTaFSItAaovE6pz1wGN2R0Z4PpwfZkDGtHKpWSOsnk2xt9FCnk= Received: from BYAPR11MB3685.namprd11.prod.outlook.com (20.178.237.158) by BYAPR11MB3557.namprd11.prod.outlook.com (20.178.206.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Thu, 9 May 2019 18:46:03 +0000 Received: from BYAPR11MB3685.namprd11.prod.outlook.com ([fe80::1d00:29b6:ddb9:61ff]) by BYAPR11MB3685.namprd11.prod.outlook.com ([fe80::1d00:29b6:ddb9:61ff%2]) with mapi id 15.20.1856.012; Thu, 9 May 2019 18:46:03 +0000 From: "Mankamana Mishra (mankamis)" To: Jeffrey Haas CC: "draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org" , "bess@ietf.org" Thread-Topic: [bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy Thread-Index: AQHVBn3gG8d0oG4J40+BXT3awN2FdqZjIemA Date: Thu, 9 May 2019 18:46:02 +0000 Message-ID: <244538F5-D256-469D-BE2F-31D884DC7526@cisco.com> References: <20190509154217.GA16412@pfrc.org> In-Reply-To: <20190509154217.GA16412@pfrc.org> 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:2840:1250:f547:4a30:dd0:6052] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b317220c-e836-4b78-1098-08d6d4ae9654 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR11MB3557; x-ms-traffictypediagnostic: BYAPR11MB3557: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(199004)(54896002)(966005)(6512007)(6306002)(25786009)(86362001)(236005)(478600001)(8936002)(81156014)(81166006)(8676002)(76116006)(316002)(6436002)(36756003)(6486002)(229853002)(606006)(14454004)(91956017)(71190400001)(71200400001)(53936002)(66574012)(54906003)(6246003)(64756008)(66476007)(66556008)(66446008)(66946007)(73956011)(68736007)(4326008)(83716004)(5660300002)(99286004)(7736002)(256004)(33656002)(82746002)(6116002)(76176011)(2906002)(102836004)(53546011)(6506007)(11346002)(446003)(486006)(186003)(2616005)(46003)(476003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3557; 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: yoPVd4urGBNPtPr7js+KfwQ6eX58rcwVleI6MPtCoZjHgVH3I1aZiz+T3kPikEkk+WdZKYY4iKWM5cmgpsTz9Wv/DHJyDJJp5QNa0DiTIDt9gEcxz8baLv3sSQ4wb8dayP7XAXv8uLhLuVsAztLDZ8M8cvZRIoL/a2nxaUleCaA28ojx5v+1yeQSUNslz8UuaIHrlTYCNM5soh34hUwxRURN9ROiAwNijIkQQ9mQztl1FPiBB5m7U8udgIJpHWDrtc2XUjcQPtldlAIONbHlPi2l918CCCR22Lh+Wd8544PW3E7Nz2LghBLtevjOI7gM1WagtRrAPjwTrySjNb1fmrKceC9YTr5Qo9hDGI69qCIQ/1bGR/i8A6+NQwP2lKDBUz8ci3JVFVmGaP/ZNDbCq4anuO+EIU910OLqGCMAGs4= Content-Type: multipart/alternative; boundary="_000_244538F5D256469DBE2F31D884DC7526ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b317220c-e836-4b78-1098-08d6d4ae9654 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 18:46:02.9302 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3557 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 18:46:18 -0000 --_000_244538F5D256469DBE2F31D884DC7526ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeffery, Thanks for comment. Please find some comment / Question inline to understa= nd your comments better. On May 9, 2019, at 11:42 AM, Jeffrey Haas > wrote: I have a few comments on this draft, in particular on the BGP PDU encoding procedures: Section 7.1: The lengths of the various fields and their consistency should be spelled out in more detail. For example, a source could be 0 for (*,G), or should be the length of an IPv4 or IPv6 host address (32/128). Other lengths likely do not make sense= . >From 7.1.1 Constructing the Selective Multicast Ethernet Tag route The Multicast Source length MUST be set to length of multicast source address in bits. In case of a (*, G) Join, the Multicast Source Length is set to 0. in case of (*,G) join , source length would be 0. and it does say in this s= ection. The length of a multicast group also likely should be a "host" length - 32/128. For the source and the group, it is likely an error if the lengths do not agree. E.g. S may be 0, but when 32 or 128 the group must be 32 or 128 respectively. Do you mean, draft should spell out different possible errored length ? o= r may be statement similar to https://tools.ietf.org/html/rfc6514 would be = good enough ? The originator router also should likely be a host length, although I'm a bit unclear what the intent of the contents of this field should be. Is this intended to be a loopback? If so, how does one choose it among several, if more than one is available? Should the length of the originato= r also agree with the S,G fields? Do you mean (S,G) len should be driving factor Originator len / IP ? Some discussion about what to do when the fields are syntactially valid but semantically invalid (e.g. mis-matched lengths) is needed. See RFC 7606 about what to discuss. Likely "treat as withdraw" semantics are desired. The flags field is somewhat confusing when the addresses are IPv6 and thus the procedures are expected to be for MLD rather than IGMP. The draft as a whole, in spite of its title, is worded heavily toward IGMP. I would suggest requesting some appropriate review to help normalize the terminolog= y here. However, the flags field should be clarified for MLD cases. This is being already addressed in next version. Similar comments apply to section 7.2 and 7.3. Section 7.3 does not discuss the two new fields Leave Group Synchornization and Maximum Response Time or the procedures for these fields. It should refer back to section 4.2. -- Jeff _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess --_000_244538F5D256469DBE2F31D884DC7526ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9440FC410DF7764E84FC037DA3B604E2@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Jeffery, 
Thanks for comment. Please find some comment / Question &nb= sp;inline to understand your comments better. 



On May 9, 2019, at 11:42 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

I have a few comments on this draft, in particular on the B= GP PDU encoding
procedures:

Section 7.1:
The lengths of the various fields and their consistency should be spelled out in more detail.  

For example, a source could be 0 for (*,G), or should be the length of an IPv4 or IPv6 host address (32/128).  Other lengths likely do not make = sense.

From 7.1.1 Constructing the Selective Multicast Ethernet Tag route

   The Multicast Source length MUST be set to length of mu=
lticast source
   address in bits. In case of a (*, G) Join, the Multicast Source
   Length is set to 0.


in case of (*,G) join , source length would be 0. and it does say in t= his section. 


The length of a multicast group also likely should be a "host" le= ngth -
32/128.

For the source and the group, it is likely an error if the lengths do not agree.  E.g. S may be 0, but when 32 or 128 the group must be 32 or 12= 8
respectively.

Do you mean,  draft should spell out different possible errored l= ength ?  or may be statement similar to https://tools.ietf.org/html/rfc6514&n= bsp;would be good enough ? 


The originator router also should likely be a host length, although I'm a bit unclear what the intent of the contents of this field should be.  = Is
this intended to be a loopback?  If so, how does one choose it among several, if more than one is available?  Should the length of the orig= inator
also agree with the S,G fields?

Do you mean (S,G) len should be driving factor Originator len / IP &nb= sp;? 


Some discussion about what to do when the fields are syntactially valid but=
semantically invalid (e.g. mis-matched lengths) is needed.  See RFC 76= 06
about what to discuss.  Likely "treat as withdraw" semantics= are desired.

The flags field is somewhat confusing when the addresses are IPv6 and thus<= br class=3D""> the procedures are expected to be for MLD rather than IGMP.  The draft= as a
whole, in spite of its title, is worded heavily toward IGMP.  I would<= br class=3D""> suggest requesting some appropriate review to help normalize the terminolog= y
here.  However, the flags field should be clarified for MLD cases.

This is being already addressed in next version. 


Similar comments apply to section 7.2 and 7.3.

Section 7.3 does not discuss the two new fields Leave Group Synchornization=
and Maximum Response Time or the procedures for these fields.  It shou= ld
refer back to section 4.2.

-- Jeff

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--_000_244538F5D256469DBE2F31D884DC7526ciscocom_--