Hi Martin,
On second thought, I replaced that paragraph with the following one to better
clarify the need for IMET route for setting up different underlay tunnels for
locally-assigned VNIs versus globally-assigned VNIs.
“In case of VxLAN and NVGRE encapsulation with locally-assigned VNIs,
just as in [RFC7432], each PE MUST advertise an IMET route to other
PEs in an EVPN instance for the multicast tunnel type that it uses
(i.e., ingress replication, PIM-SM, PIM-SSM, or Bidir-PIM tunnel).
However, for globally-assigned VNIs, each PE MUST advertise IMET
route to other PEs in an EVPN instance for ingress replication or
PIM-SSM tunnel, and MAY advertise IMET route for PIM-SM or Bidir-PIM
tunnel. In case of PIM-SM or Bidir-PIM tunnel, no information in the
IMET route is needed by the PE to setup these tunnels. “
Cheers,
Ali
On 12/15/17, 10:24 AM, "BESS on behalf of Martin Vigoureux"
<bess-boun...@ietf.org on behalf of martin.vigour...@nokia.com> wrote:
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-boun...@ietf.org on behalf of thomas.mo...@orange.com> 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:jdr...@juniper.net]
> > Sent: Friday, December 15, 2017 9:52 AM
> > To: EXT - thomas.mo...@orange.com <thomas.mo...@orange.com>; Fedyk,
> > Don <don.fe...@hpe.com>; Marco Marzetti <ma...@lamehost.it>
> > Cc: bess@ietf.org
> > 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:bess-boun...@ietf.org] On Behalf Of Thomas
Morin
> > > Sent: Friday, December 15, 2017 5:42 AM
> > > To: Fedyk, Don <don.fe...@hpe.com>; Marco Marzetti
<marco@lamehost.
> > > it>
> > > Cc: bess@ietf.org
> > > 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:bess-boun...@ietf.org] On Behalf Of Marco
> > > > Marzetti
> > > > Sent: Thursday, December 14, 2017 9:21 AM
> > > > To: Thomas Morin <thomas.mo...@orange.com>
> > > > Cc: bess@ietf.org
> > > > 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
> > >
> > > <thomas.mo...@orange.co
> > > > 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
> > > BESS@ietf.org
> > > 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
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
