Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Alvaro,

Regarding your two remaining comments, let me address them directly here:

1)  I will get a registry for them set up when there will be more than one flag. Currently, there is only a single flag defined and we do not anticipate any additional flags at this point.

2) regarding removing P2MP mention (so that it get generalized to MP2MP), I will do that but will add a sentence to say the other tunnel types that are supported by EVPN - e.g., currently P2MP are supported but in the future MP2MP can also be supported. So, I don't wan to exclude MP2MP. I can add his sentence during the RFC editing phase, is that OK?

Cheers,
Ali


From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, June 7, 2017 at 5:10 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Thomas Morin <[e-mail]<mailto:[e-mail]>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>> wrote:

Ali:

Hi!  Sorry for the long RTT, busy days...

I have two remaining comments (below).  Once the registry is defined, then we can start the IESTF LC.

Thanks!

Alvaro.


...
> > > M6. Definition of the E-TREE Extended Community
> > >
> > > M6.1. Only one Flag is defined.  What about the others?  Please set up a registry.
> >
> > If needed in the future, we will setup a registry.
>
> Please set it up now.
>
> OK, I will set it up.

Please do.


...
> > > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says that "the high-
> > > order bit of the tunnel type field (C bit - Composite tunnel bit) is set while the
> > > remaining low-order seven bits indicate the tunnel type as before."   But 3.3.1 says
> > > that the "new composite tunnel type is advertised by the root PE to simultaneously
> > > indicate a P2MP tunnel in transmit direction and an ingress-replication tunnel in the
> > > receive direction...".  Knowing, from 5.2 that when the C bit is set "Tunnel
> > > Types...0x06 'Ingress Replication' is invalid", then does the C bit have a set meaning
> > > or ???   [BTW, s/is/are]
> >
> > The description in section 3.3.1 is consistent with this section 5.2. Basically, Composite
> > Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in the transmit
> > direction and a MP2P tunnel in the receive direction. The MP2P tunnel in the receive
> > direction is used by Leaf PE devices for their BUM traffic transmission. The "ingress
> > replication tunnel type" is not valid because for that we don't need composite tunnel
> > type!!
> > I added the following sentence to the 1st paragraph to clarify it  more:
> > "Composite tunnel type is advertised by the root PE to simultaneously indicate a P2MP
> > tunnel in transmit direction and an ingress-replication tunnel in the receive direction
> > for the BUM traffic."
>
> Let me see if I understand what you're saying:
>
> If the C-bit is set, then the receive direction always has an IR tunnel.
> The type of the P2MP tunnel is defined by one of the other bits.  Is that right?
>
> That's correct. The remaining 7 bits indicate the type of tunnel.
>
> If so, are all the other bits valid (always)?  The text already says that 0x00/0x06 are
> invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 0x0A (Assisted-Replication
>  Tunnel [draft-ietf-bess-evpn-optimized-ir])?
>
> How can you be sure that any other type besides 0x00/0x06 will be ok?
>
> Basically composite tunnel type doesn't make sense when ingress replication (0x06)
> is used or when tunnel info is not present (0x00). Other than that, it can be used with
> other tunnel types.

I was asking about 0x07 because that is a MP2MP LSP, and the text says that the bits "indicate a P2MP tunnel":  P2MP, but not other types.  Maybe the solution is to just say "indicate a tunnel".

You said that IR doesn't make sense, but "optimized IR" does?  I'll take your work for it...

Just double checking, no change needed (except s/P2MP//) if any other tunnel can be used.