Hello, My comments as #MARCO.
On Fri, Dec 15, 2017 at 11:42 AM, Thomas Morin <[email protected]> wrote: > Hi Don, > > Fedyk, Don, 2017-12-14 20:33: > > I think the gray area is that this draft talks about BUM traffic and > > ingress replication and then has a section on Multicast tunnels which > > excludes ingress replication traffic from the tunnels. > > No, ingress replication is not excluded at all: > > The following tunnel types as defined in [RFC6514] can be used in > the PMSI tunnel attribute for VXLAN/NVGRE: > > + 3 - PIM-SSM Tree > + 4 - PIM-SM Tree > + 5 - BIDIR-PIM Tree > + 6 - Ingress Replication > #MARCO. Agreed that Ingress Replicaiton is cited here, but there's no reference in the paragraphs down to the end of the section. """ Except for Ingress Replication, .... """" I am not saying that the draft is necessarily unclear or it's missing something and I don't know if developers of the non-conforming implementation simply overlooked or totally mis-interpreted that part, but the fact is they got it wrong. I sent them a copy of your last emails, i am confident that they will amend their code as suggested. > > > If you are using point to point VXLAN/NVGRE tunnels then ingress > > replication is default [...] > > This formulation surprises me: that some implementations behave as you > describe is possibly true (this seems to be the case of the > implementation that triggered this discussion), but I don't know about > any text in the specs we are discussing that would imply such a > 'default'. > > You might have implementations that in the absence of any local > configuration for an EVPN instance on which type of tunnel to use for > BUM, will default to ingress replication: this is fine, out of the > scope of what is specified for interop, and not breaking other > implementations (as long, of course, that what is chosen locally is > then advertised as expected in a PMSI Tunnel Attribute). > > > > but IMET is being used to identify the NVE IP. I read RFC7432 and > > RFC6514 in this area and thought that the PMSI attribute MUST be set > > when there is an Inclusive Multicast Ethernet tag IMET. > > Yes! (the text of RFC7432 quoted by Ali reminds us that) > > > > I can see two possible fixes: > > - Specify that the PMSI attribute MUST be set if there is an > > IMET route and specify correct attribute. > > Given the content of RFC7432 and the fact that this is a normative ref > of draft-ietf-bess-evpn-overlay, I think that we don't need to repeat > this MUST in draft-ietf-bess-evpn-overlay. That is, unless we > explicitly identify an ambiguous piece of text. > > > - Allow that ingress replication is default when PMSI is > > absent but accept PMSI that specifies ingress replication. > > > > I don't think we should do that. It would overnight make non-compliant > pre-standard implementation of draft-ietf-bess-evpn-overlay, without a > rationale to do so except coping with an implementation that assumed a > bit too much. > #MARCO Agreed. If their behavior is wrong we should ask them to fix it instead of seconding what they're doing. > > Best, > > -Thomas > > > > > From: BESS [mailto:[email protected]] On Behalf Of Marco Marzetti > > Sent: Thursday, December 14, 2017 9:21 AM > > To: Thomas Morin <[email protected]> > > Cc: [email protected] > > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress > > Replication > > > > Hello, > > > > I have encountered an implementation that is not attaching any PMSI > > to the IMET. > > The authors think they don't really need it because they only support > > Ingress Replication. > > Such behavior breaks interoperability with other implementations that > > are dropping the NLRI if PMSI is not attached. > > > > So i looked at draft-ietf-bess-evpn-overlay-10 and noticed that > > there's no clear indication of what the proper behavior is. > > As said i assumed i had to look at RFC7432 and RFC6514 (and i did > > it), but i wasn't 100% sure and i preferred to ask. > > > > Onestly you already made my day by confirming what i thought. > > My suggestion was to make things more clear, but i admit that it > > could look redundant. > > > > Thanks > > > > > > > > > > > > > > > > On Thu, Dec 14, 2017 at 2:39 PM, Thomas Morin <[email protected] > > m> wrote: > > > Hi Marco, > > > > > > Marco Marzetti, 2017-12-14 12:25: > > > > I am writing this email asking you to clarify what's the > > > suggested > > > > behavior when PMSI Tunnel Type is set to "Ingress Replication" > > > (type > > > > 6) as draft-ietf-bess-evpn-overlay-10 only suggests what to do > > > with > > > > multicast tunnel trees. > > > > > > > > I think the originating PE should conform with RFC6514 and > > > RFC7432 > > > > (from which you've taken inspiration) and always (RFC2119 MUST) > > > > attach PMSI Tunnel attribute with the Tunnel Type set to Ingress > > > > Replication and Tunnel Identifier set to a routable address of > > > the PE > > > > itself (more specifically NVE's IP address). > > > > > > > > Is that correct? > > > > In that case i suggest to add the following line at the end of > > > > Section 9. > > > > """ > > > > For Ingress Replication the PE should follow what's stated in > > > RFC6514 > > > > Section 5 . > > > > """ > > > > > > The text of section 9 lists "Ingress Replication" in the list of > > > tunnel > > > types that can be used. My understanding is that, in the absence of > > > anything being specifically said for Ingress Replication, an > > > implementation should follow what is said in RFC7432 and RFC6514. > > > (What > > > other specs could it follow to implement this supported type ? > > > RFC7432 > > > and RFC6514 are more than an inspiration here, these are specs that > > > the > > > document refers to explicitly) > > > > > > So I'm not sure that it is useful or needed to add text. > > > > > > Can you perhaps expand on why the current text would possibly be > > > ambiguous, misleading or incomplete...? > > > > > > -Thomas > > > > > > > > > > > -- > > Marco > -- Marco
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
