Re: [bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy

Jeffrey Haas <jhaas@pfrc.org> Thu, 09 May 2019 19:02 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 4F434120156; Thu, 9 May 2019 12:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 9K4gsEM9MlUz; Thu, 9 May 2019 12:02:14 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 489E4120143; Thu, 9 May 2019 12:02:05 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4B96F1E2D8; Thu, 9 May 2019 15:02:30 -0400 (EDT)
Date: Thu, 9 May 2019 15:02:29 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
Cc: "draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org" <draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Message-ID: <20190509190229.GA17794@pfrc.org>
References: <20190509154217.GA16412@pfrc.org> <244538F5-D256-469D-BE2F-31D884DC7526@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <244538F5-D256-469D-BE2F-31D884DC7526@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/m8PlJWBs_QY4qXamlpMglMNvN98>
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 <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: Thu, 09 May 2019 19:02:19 -0000

On Thu, May 09, 2019 at 06:46:02PM +0000, Mankamana Mishra (mankamis) wrote:
> On May 9, 2019, at 11:42 AM, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:
> > 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<https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-02#section-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 section.

It does not specify that 32 or 128 is the only other two useful options
though.

Basically, the point is that in the absence of text that "this is a host",
the implication is "this might be a subnet".  

For example, if the length is 24, even properly encoded on the wire for that
length, what do you do with 24 bits of a source?

> > 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 ?  or may be statement similar to https://tools.ietf.org/html/rfc6514 would be good enough ?

Consider 6514, section 4.3:

:   The Multicast Source field contains the C-S address.  If the
:   Multicast Source field contains an IPv4 address, then the value of
:   the Multicast Source Length field is 32.  If the Multicast Source
:   field contains an IPv6 address, then the value of the Multicast
:   Source Length field is 128.

So, yes, that would be what I was expecting here.

> > 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 originator
> > also agree with the S,G fields?
> 
> Do you mean (S,G) len should be driving factor Originator len / IP  ?

If I have ipv4 (S,G), is it reasonable that I got that from a router that is
via IPv6?  

> > 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 terminology
> > here.  However, the flags field should be clarified for MLD cases.
> 
> This is being already addressed in next version.

Thanks.

-- Jeff