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

Hi Martin,

It is one of those things that “less may be more”– i.e., difference between route origination and traffic origination for ingress-replication tunnels versus P2MP should be clear to people in the BESS WG. Furthermore, it is consistent with RFC 7432. In other words, if the procedure was different than RFC 7432, then I would have elaborated on this paragraph instead of removing it.

Cheers,
Ali

On 12/15/17, 10:24 AM, "BESS on behalf of Martin Vigoureux" <bess-bounces@ietf.org on behalf of martin.vigoureux@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-bounces@ietf.org on behalf of thomas.morin@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:jdrake@juniper.net]
    >      > Sent: Friday, December 15, 2017 9:52 AM
    >      > To: EXT - thomas.morin@orange.com <thomas.morin@orange.com>; Fedyk,
    >      > Don <don.fedyk@hpe.com>; Marco Marzetti <marco@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-bounces@ietf.org] On Behalf Of Thomas Morin
    >      > > Sent: Friday, December 15, 2017 5:42 AM
    >      > > To: Fedyk, Don <don.fedyk@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-bounces@ietf.org] On Behalf Of Marco
    >      > > > Marzetti
    >      > > > Sent: Thursday, December 14, 2017 9:21 AM
    >      > > > To: Thomas Morin <thomas.morin@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.morin@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