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

From: Marco Marzetti <[email-masked]>
Date: Thu, 14 Dec 2017 12:25:18 +0100

Dear members of the WG and authors of the draft,

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 .
"""
URL to RFC6514 section 5: https://tools.ietf.org/html/rfc6514#section-5

Thank you

Regards

-- 
Marco

---

From: Thomas Morin <[email-masked]>
Date: Thu, 14 Dec 2017 14:39:37 +0100

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?

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

---

From: Marco Marzetti <[email-masked]>
Date: Thu, 14 Dec 2017 15:20:34 +0100

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

-- 
Marco

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 14 Dec 2017 18:24:59 +0000

Hi Marco,

If an implementation doesn’t add PMSI to an IMET route, then that implementation is broken. RFC 7432 says:
“In order to identify the P-tunnel used for sending broadcast, unknown
   unicast, or multicast traffic, the Inclusive Multicast Ethernet Tag
   route MUST carry a Provider Multicast Service Interface (PMSI) Tunnel
   attribute as specified in [RFC6514<https://tools.ietf.org/html/rfc6514>].”
An section 9 of evpn-overlay says:
“This route is tagged
   with the PMSI Tunnel attribute, which is used to encode the type of
   multicast tunnel to be used as well as the multicast tunnel
   identifier. The tunnel encapsulation is encoded by adding the BGP
   Encapsulation extended community as per section 5.1.1.”

There should be no ambiguity here. The BGP encapsulation EC can be optional if MPLS encap or static config is used – ie, section 5.1.3 says” if the BGP Encapsulation extended community is not present, then either MPLS encapsulation or a statically configured encapsulation is assumed”.

Cheers,
Ali

From: BESS <[email-masked]> on behalf of Marco Marzetti <[email-masked]>
Date: Thursday, December 14, 2017 at 6:20 AM
To: Thomas Morin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
Hi Marco,

-Thomas

--
Marco

---

From: "Fedyk, Don" <[email-masked]>
Date: Thu, 14 Dec 2017 20:33:14 +0000

Hi

I came across this as well.  I would suggest that wording in draft-ietf-bess-evpn-overlay-10 be explicit on the expected behaviour.  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. If you are using point to point VXLAN/NVGRE  tunnels then ingress replication is default 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.

I can see two possible fixes:

-          Specify that the PMSI attribute MUST be set if there is an IMET route and specify correct attribute.

-          Allow that ingress replication is default when PMSI is absent but accept PMSI that specifies ingress replication.

Cheers
Don

From: BESS [mailto:[email-masked]] On Behalf Of Marco Marzetti
Sent: Thursday, December 14, 2017 9:21 AM
To: Thomas Morin <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

Hello,

Thanks

-Thomas

--
Marco

---

From: Thomas Morin <[email-masked]>
Date: Fri, 15 Dec 2017 11:42:24 +0100

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)

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

> 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.
>  
> On Thu, Dec 14, 2017 at 2:39 PM, Thomas Morin <[email-masked]
> m> wrote:
> > Hi Marco,
> >

---

From: Marco Marzetti <[email-masked]>
Date: Fri, 15 Dec 2017 12:42:04 +0100

Hello,

My comments as #MARCO.

>          + 6 - Ingress Replication

#MARCO.
Agreed that Ingress Replicaiton is cited here, but there's no reference in
the paragraphs down to the end of the section.

"""
Except for Ingress Replication, ....
""""

I am not saying that the draft is necessarily unclear or it's missing
something and I don't know if developers of the non-conforming
implementation simply overlooked or totally mis-interpreted that part, but
the fact is they got it wrong.
I sent them a copy of your last emails, i am confident that they will amend
their code as suggested.

> rationale to do so except coping with an implementation that assumed a

#MARCO
Agreed.
If their behavior is wrong we should ask them to fix it instead of
seconding what they're doing.

-- 
Marco

---

From: John E Drake <[email-masked]>
Date: Fri, 15 Dec 2017 14:52:08 +0000

Thomas,

I completely agree w/ your email, below.

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Thomas Morin
> Sent: Friday, December 15, 2017 5:42 AM
> To: Fedyk, Don <[email-masked]>; Marco Marzetti
> <[email-masked]>
> Cc: [email-masked]
> 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'.
> 
> 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).
> 
> 
> 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.
> 
> 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
> 
> 
> 
> > 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.
> >
> > > 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
> > > and RFC6514 are more than an inspiration here, these are specs that
> > > the document refers to explicitly)
> > >
> _______________________________________________
> BESS mailing list
> [email-masked]
> 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=

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 15 Dec 2017 15:34:50 +0000

Hi Thomas

I'm good with the interpretation of RFC7432 and RFC6514 in this area as I said.  But at least one implementation got it wrong.   

You Wrote: 
That is, unless we  explicitly identify an ambiguous piece of text.

I think section  9. Support for Multicast could use a slight rewording.  Perhaps citing  RFC7432 as well.  
I know I read this part several times.  The draft specifies a Multicast tunnel with attribute Ingress replication that you don't use for multicast traffic.

   For example,
   the PMSI Tunnel attribute may indicate the multicast tunnel is of
   type PIM-SM; whereas, the BGP Encapsulation extended community may
   indicate the encapsulation for that tunnel is of type VxLAN. 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

   Except for Ingress Replication, this multicast tunnel is used by the
   PE originating the route for sending multicast traffic to other PEs,
   and is used by PEs that receive this route for receiving the traffic
   originated by hosts connected to the PE that originated the route.
<<<<<

Cheers
Don 

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Friday, December 15, 2017 9:52 AM
To: EXT - [email-masked] <[email-masked]>; Fedyk, Don <[email-masked]>; Marco Marzetti <[email-masked]>
Cc: [email-masked]
Subject: RE: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

Thomas,

Yours Irrespectively,

John

> To: Fedyk, Don <[email-masked]>; Marco Marzetti <[email-masked]>
> Cc: [email-masked]
> > ingress replication and then has a section on Multicast tunnels 
> > which excludes ingress replication traffic from the tunnels.
> 
> any text in the specs we are discussing that would imply such a 'default'.
> 
> 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
> 
> 
> 
> > Such behavior breaks interoperability with other implementations 
> > that are dropping the NLRI if PMSI is not attached.
> >
> > > absence of anything being specifically said for Ingress 
> > > Replication, an implementation should follow what is said in RFC7432 and RFC6514.
> > > (What
> > > and RFC6514 are more than an inspiration here, these are specs 
> > > that the document refers to explicitly)
> > >

---

From: Thomas Morin <[email-masked]>
Date: Fri, 15 Dec 2017 17:42:24 +0100

Hi Don,

Fedyk, Don, 2017-12-15 15:34:
> I know I read this part several times.  The draft specifies a
> Multicast tunnel with attribute Ingress replication that you don't
> use for multicast traffic.
> 
> > > > > > 
> 
>    For example,

Honestly, interpreting the above as "The draft specifies a Multicast
tunnel with attribute Ingress replication that you don't use for
multicast traffic" is in my opinion really far fetched, for two
reasons:
- the paragraph does not talk about the advertised routes, but what is
used in the dataplane (the actual dataplane construct corresponding to
the PMSI Tunnel Attribute)
- the paragraph only talks about the traffic flowing from advertiser to
remote PEs, so it does not exclude the other direction of traffic from
being used in the case of ingress replication

So well, it's not the first time that additional text aiming at helping
people understand, rather than add precisions required for interop,
ends up being a source of questions.

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.

Best,

-Thomas

-----Original Message-----
> To: EXT - [email-masked] <[email-masked]>; Fedyk,
> Don <[email-masked]>; Marco Marzetti <[email-masked]>
> Cc: [email-masked]
> > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with
> > Ingress 
> > Replication
> > 
> > Hi Don,
> > 
> > > I have encountered an implementation that is not attaching any
> > > PMSI 
> > > to the IMET.
> > > On Thu, Dec 14, 2017 at 2:39 PM, Thomas Morin
> > 
> > <[email-masked]
> > > m> wrote:
> > > > Hi Marco,
> > > > 
> > > > > 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
> > > > > Replication and Tunnel Identifier set to a routable address
> > > > > of
> > > > 
> > > > the PE
> > > > > 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 .
> > > > > """
> > > >

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 15 Dec 2017 18:09:29 +0000

Hi Don,

On 12/15/17, 7:35 AM, "BESS on behalf of Fedyk, Don" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Thomas

    You Wrote: 

Ali> You have completely misinterpreted this paragraph. This paragraph talks about the originator of the route is the same as the PE who sources the traffic for such multicast tunnels (except for ingress replication where the originator of the route is the receiver of the traffic!!). 

Cheers,
Ali 

       For example,
    
             + 3 - PIM-SSM Tree
             + 4 - PIM-SM Tree
             + 5 - BIDIR-PIM Tree

    Cheers
    Don 
    
    -----Original Message-----
    From: John E Drake [mailto:[email-masked]] 
    Sent: Friday, December 15, 2017 9:52 AM
    To: EXT - [email-masked] <[email-masked]>; Fedyk, Don <[email-masked]>; Marco Marzetti <[email-masked]>
    Cc: [email-masked]
    Subject: RE: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication
    
    Thomas,

    Yours Irrespectively,
    
    John

    > > Ingress Replication
    
    _______________________________________________
    BESS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bess

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 15 Dec 2017 18:21:21 +0000

Hi Thomas,

On 12/15/17, 8:42 AM, "BESS on behalf of Thomas Morin" <[email-masked] on behalf of [email-masked]> wrote:

OK, I will remove it in the next rev.
  
Cheers,
Ali
    
    Best,
    
    -Thomas

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 15 Dec 2017 19:24:27 +0100

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 15 Dec 2017 18:32:30 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    -m

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 15 Dec 2017 10:33:32 -0800

+1 Martin.
By removing it you assume right interpretation, by wording it unambiguously you provide
the right interpretation.

Cheers,
Jeff

-----Original Message-----
From: BESS <[email-masked]> on behalf of Martin Vigoureux <[email-masked]>
Date: Friday, December 15, 2017 at 10:24
To: <[email-masked]>
Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

    -m

---

From: John E Drake <[email-masked]>
Date: Fri, 15 Dec 2017 19:27:05 +0000

I don't think it adds anything to what is already in RFC 7432.

Yours Irrespectively,

John

> From: BESS [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: Friday, December 15, 2017 1:24 PM
> To: [email-masked]
> if the intent was to help people better understand the reasoning behind the
> design, is it really best to remove it?
> > On 12/15/17, 8:42 AM, "BESS on behalf of Thomas Morin" <bess-
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >
> <marco@lamehost.
> >      > > it>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=1x8aFOvk_RP03fyq3IB
> > pZwBtJxjqUj4Q_SUqY-J3hms&s=uWbEHvqg7t78XI-
> MNC1dqHKsE6YtdoeSGy9gdxdSQq8
> > &e=
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=1x8aFOvk_RP03fyq3IB
> > pZwBtJxjqUj4Q_SUqY-J3hms&s=uWbEHvqg7t78XI-
> MNC1dqHKsE6YtdoeSGy9gdxdSQq8
> > &e=
> >
> 
> 3A__www.ietf.org_mailman_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=1x8aFOvk_RP03fyq3IBpZwBtJxjqUj4Q_SUqY-
> J3hms&s=uWbEHvqg7t78XI-MNC1dqHKsE6YtdoeSGy9gdxdSQq8&e=