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

[Marco Marzetti <[e-mail]>]

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