I don't think it adds anything to what is already in RFC 7432. Yours Irrespectively,
John > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Martin Vigoureux > Sent: Friday, December 15, 2017 1:24 PM > To: [email protected] > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress > Replication > > if the intent was to help people better understand the reasoning behind the > design, is it really best to remove it? > Wouldn't a rephrasing be more appropriate? > > -m > > Le 2017-12-15 à 19:21, Ali Sajassi (sajassi) a écrit : > > Hi Thomas, > > > > On 12/15/17, 8:42 AM, "BESS on behalf of Thomas Morin" <bess- > [email protected] on behalf of [email protected]> wrote: > > > > > > Here I would suggest to authors to consider purely removing this > > paragraph, not because it would be wrong or ambiguous (as said above, > I > > don't think it is), but because as far as I can tell it has never meant > > to specify anything not already implied by RFC7432, but was here only > > to help understand. > > > > OK, I will remove it in the next rev. > > > > Cheers, > > Ali > > > > Best, > > > > -Thomas > > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:[email protected]] > > > Sent: Friday, December 15, 2017 9:52 AM > > > To: EXT - [email protected] <[email protected]>; > Fedyk, > > > Don <[email protected]>; Marco Marzetti <[email protected]> > > > Cc: [email protected] > > > Subject: RE: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress > > > Replication > > > > > > Thomas, > > > > > > I completely agree w/ your email, below. > > > > > > Yours Irrespectively, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: BESS [mailto:[email protected]] On Behalf Of Thomas > Morin > > > > Sent: Friday, December 15, 2017 5:42 AM > > > > To: Fedyk, Don <[email protected]>; Marco Marzetti > <marco@lamehost. > > > > it> > > > > Cc: [email protected] > > > > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with > > > > Ingress > > > > Replication > > > > > > > > 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 > > > > > > > > > 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. > > > > > > > > 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 > > > > > > > > _______________________________________________ > > > > BESS mailing list > > > > [email protected] > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > > > > 3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Sc > > > > bfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > > > > s_xXXup3HzvBSMRj5VE&m=tHiUTn9_QXrhs3cw- > > > > Dn9_qwR3VK2xWv72DcpoOfR_SI&s=VxylPoVhzXC58hBsqToxzhUK6- > 3kfy- > > > > ktUi7A9KZDcs&e= > > > > _______________________________________________ > > BESS mailing list > > [email protected] > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > man_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzo > > CI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=1x8aFOvk_RP03fyq3IB > > pZwBtJxjqUj4Q_SUqY-J3hms&s=uWbEHvqg7t78XI- > MNC1dqHKsE6YtdoeSGy9gdxdSQq8 > > &e= > > > > > > _______________________________________________ > > BESS mailing list > > [email protected] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > man_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzo > > CI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=1x8aFOvk_RP03fyq3IB > > pZwBtJxjqUj4Q_SUqY-J3hms&s=uWbEHvqg7t78XI- > MNC1dqHKsE6YtdoeSGy9gdxdSQq8 > > &e= > > > > _______________________________________________ > BESS mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6S > cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=1x8aFOvk_RP03fyq3IBpZwBtJxjqUj4Q_SUqY- > J3hms&s=uWbEHvqg7t78XI-MNC1dqHKsE6YtdoeSGy9gdxdSQq8&e= _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
