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)" <[email protected]<mailto:[email protected]>> Date: Wednesday, June 7, 2017 at 5:10 AM To: Cisco Employee <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Thomas Morin <[email protected]<mailto:[email protected]>> Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09 On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
