Hi Thomas,
On 12/15/17, 8:42 AM, "BESS on behalf of Thomas Morin" <[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://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
