Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

[John E Drake <[e-mail]>]

I don't think it adds anything to what is already in RFC 7432.

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[e-mail]] On Behalf Of Martin Vigoureux
> Sent: Friday, December 15, 2017 1:24 PM
> To: [e-mail]
> 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-
> [e-mail] on behalf of [e-mail]> 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:[e-mail]]
> >      > Sent: Friday, December 15, 2017 9:52 AM
> >      > To: EXT - [e-mail] <[e-mail]>;
> Fedyk,
> >      > Don <[e-mail]>; Marco Marzetti <[e-mail]>
> >      > Cc: [e-mail]
> >      > 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:[e-mail]] On Behalf Of Thomas
> Morin
> >      > > Sent: Friday, December 15, 2017 5:42 AM
> >      > > To: Fedyk, Don <[e-mail]>; Marco Marzetti
> <marco@lamehost.
> >      > > it>
> >      > > Cc: [e-mail]
> >      > > 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:[e-mail]] On Behalf Of Marco
> >      > > > Marzetti
> >      > > > Sent: Thursday, December 14, 2017 9:21 AM
> >      > > > To: Thomas Morin <[e-mail]>
> >      > > > Cc: [e-mail]
> >      > > > 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
> >      > >
> >      > > <[e-mail]
> >      > > > 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
> >      > > [e-mail]
> >      > > 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
> >      [e-mail]
> >
> > 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
> > [e-mail]
> > 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
> [e-mail]
> 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=