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

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

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
> <[e-mail]>
> 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=