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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 9 May 2019 11:42:17 -0400

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.

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.

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?

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 terminology
here.  However, the flags field should be clarified for MLD cases.

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

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 9 May 2019 18:46:02 +0000

Hi Jeffery,
Thanks for comment. Please find some comment / Question  inline to understand your comments better.

On May 9, 2019, at 11:42 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Section 7.1:

>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.

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 ?

Do you mean (S,G) len should be driving factor Originator len / IP  ?

This is being already addressed in next version.

-- Jeff

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 9 May 2019 15:02:29 -0400

> 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?

> 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.

> 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?  

> This is being already addressed in next version.

Thanks.

-- Jeff