Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

Thanks Jorge.  I get it now.

On Sun, Dec 18, 2022 at 11:28 PM Jorge Rabadan (Nokia) <
jorge.raba...@nokia.com> wrote:

> Hi Anoop,
>
>
>
> Note that it is not only the ESI-based filtering procedure (for
> multi-homing) that is performed using the information in the Ethernet
> option TLV, but also the E-Tree flags and the BUM indication. So even if
> you are using local-bias, and you are not using E-Tree, we still want the
> BUM indication to avoid transient packet duplication in certain scenarios.
>
>
>
> So IMO what we want is to RECOMMEND the use of the ethernet option TLV in
> all cases.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Anoop Ghanwani 
> *Date: *Sunday, December 18, 2022 at 3:49 AM
> *To: *Boutros, Sami 
> *Cc: *Boutros, Sami , UTTARO, JAMES <
> ju1...@att.com>, Jorge Rabadan (Nokia) , Matthew
> Bocci (Nokia) , bess@ietf.org ,
> draft-ietf-bess-evpn-gen...@ietf.org  >
> *Subject: *Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and
> Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
>
> Here's a proposed change:
>
>
>
> OLD
>
>
> While "local-bias" MUST be supported along with Geneve encapsulation, the
> use of the Ethernet option-TLV is RECOMMENDED to follow the same procedures
> used by EVPN MPLS.
>
>
>
> NEW
>
>
>
> While "local-bias" MUST be supported along with Geneve encapsulation, the
> use of the Ethernet option-TLV is required if not using local-bias and
> instead following procedures used by EVPN MPLS.
>
>
>
> This allows implementations that implement only local bias to skip
> sending/implementing the TLV.
>
>
>
> Or are you trying to RECOMMEND that implementations also implement the
> EVPN MPLS procedures in addition to local bias?  If so, I would word the
> text as:
>
>
>
> While "local-bias" MUST be supported along with Geneve encapsulation and
> that doesn't require the use of the Ethernet option-TLV, it is RECOMMENDED
> that Geneve implementations also implement the same procedures used by EVPN
> MPLS.
>
>
>
> On Sat, Dec 17, 2022 at 6:33 PM Anoop Ghanwani 
> wrote:
>
> Sami,
>
>
>
> Why is it recommended to carry the TLV if local bias is in use?  (I
> understand the need for it if we're not using local bias.)
>
>
>
> Anoop
>
>
>
> On Sat, Dec 17, 2022 at 2:06 PM Boutros, Sami  wrote:
>
> I’m not sure what tightening you are recommending, I am out of ideas of
> how to tighten this, may be you can propose something.
>
>
>
> It is quite clear to me and to the authors, and I hope to everyone else,
> how the TLV can be used for SH as a mechanism similar to local bias, as
> well it can be used when ETREE support is needed.
>
>
>
> Thanks,
>
>
> Sami
>
> *From: *Anoop Ghanwani 
> *Date: *Saturday, December 17, 2022 at 1:25 PM
> *To: *Boutros, Sami 
> *Cc: *Boutros, Sami , UTTARO, JAMES <
> ju1...@att.com>, Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com>, Bocci, Matthew (Nokia - GB) <
> matthew.bo...@nokia.com>, bess@ietf.org ,
> draft-ietf-bess-evpn-gen...@ietf.org  >
> *Subject: *Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and
> Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
>
> Sami,
>
> I don't believe there was closure on this issue.
>
> I think the text around the option TLV being RECOMMENDED should be
> tightened so that it's recommended only when needed.  The way the draft is
> currently written, it sounds like it is recommending that the TLV always be
> carried if multihoming is in use.  But this is not necessary or even
> valuable if Local Bias is in use.
>
> On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani 
> wrote:
>
> > Hi Sami,
> >
> > Thanks for updating the doc.
> >
> > Regarding this:
> > >>>
> >
> > I find this statement confusing
> >
> >
> >
> >While "local-bias" MUST be supported along with GENEVE encapsulation,
> >
> >the use of the Ethernet option-TLV is RECOMMENDED to follow the same
> >
> >procedures used by EVPN MPLS.
> >
> >
> >
> >
> >
> > I'm not sure how it helps to carry an extra TLV when it is known
> >
> > that its absence or presence results in identical behavior.
> >
> >
> >
> > Sami: The new TLV is not there only for local bias! It is there for bum
> and leaf/root indications too. So, we can’t simply not carry it. As for the
> text above, we are saying setting the ESI label in the TLV will allow us to
> follow the same Split horizon behavior of MPLS-EVPN with no need for local
> bias. It is true local bias must be supported but this mechanism will work
> too if available given that it is optional.
> >
> > >>>
> >
> > I'm not sure I follow what you're saying.  The new TLV is actually not
> > needed for the Local Bias case because we already know how to make that
> > case work without it.  It is, however, needed for the non-Local Bias case
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Jorge Rabadan (Nokia)]

Hi Anoop,

Note that it is not only the ESI-based filtering procedure (for multi-homing) 
that is performed using the information in the Ethernet option TLV, but also 
the E-Tree flags and the BUM indication. So even if you are using local-bias, 
and you are not using E-Tree, we still want the BUM indication to avoid 
transient packet duplication in certain scenarios.

So IMO what we want is to RECOMMEND the use of the ethernet option TLV in all 
cases.

Thanks.
Jorge

From: Anoop Ghanwani 
Date: Sunday, December 18, 2022 at 3:49 AM
To: Boutros, Sami 
Cc: Boutros, Sami , UTTARO, JAMES 
, Jorge Rabadan (Nokia) , Matthew 
Bocci (Nokia) , bess@ietf.org , 
draft-ietf-bess-evpn-gen...@ietf.org 
Subject: Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and 
Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
Here's a proposed change:

OLD

While "local-bias" MUST be supported along with Geneve encapsulation, the use 
of the Ethernet option-TLV is RECOMMENDED to follow the same procedures used by 
EVPN MPLS.

NEW

While "local-bias" MUST be supported along with Geneve encapsulation, the use 
of the Ethernet option-TLV is required if not using local-bias and instead 
following procedures used by EVPN MPLS.

This allows implementations that implement only local bias to skip 
sending/implementing the TLV.

Or are you trying to RECOMMEND that implementations also implement the EVPN 
MPLS procedures in addition to local bias?  If so, I would word the text as:

While "local-bias" MUST be supported along with Geneve encapsulation and that 
doesn't require the use of the Ethernet option-TLV, it is RECOMMENDED that 
Geneve implementations also implement the same procedures used by EVPN MPLS.

On Sat, Dec 17, 2022 at 6:33 PM Anoop Ghanwani 
mailto:an...@alumni.duke.edu>> wrote:
Sami,

Why is it recommended to carry the TLV if local bias is in use?  (I understand 
the need for it if we're not using local bias.)

Anoop

On Sat, Dec 17, 2022 at 2:06 PM Boutros, Sami 
mailto:sbout...@ciena.com>> wrote:
I’m not sure what tightening you are recommending, I am out of ideas of how to 
tighten this, may be you can propose something.

It is quite clear to me and to the authors, and I hope to everyone else, how 
the TLV can be used for SH as a mechanism similar to local bias, as well it can 
be used when ETREE support is needed.

Thanks,

Sami
From: Anoop Ghanwani mailto:an...@alumni.duke.edu>>
Date: Saturday, December 17, 2022 at 1:25 PM
To: Boutros, Sami mailto:sbout...@ciena.com>>
Cc: Boutros, Sami 
mailto:40ciena@dmarc.ietf.org>>, 
UTTARO, JAMES mailto:ju1...@att.com>>, Rabadan, Jorge (Nokia - 
US/Mountain View) mailto:jorge.raba...@nokia.com>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-gen...@ietf.org<mailto:draft-ietf-bess-evpn-gen...@ietf.org>
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and 
Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
Sami,

I don't believe there was closure on this issue.

I think the text around the option TLV being RECOMMENDED should be
tightened so that it's recommended only when needed.  The way the draft is
currently written, it sounds like it is recommending that the TLV always be
carried if multihoming is in use.  But this is not necessary or even
valuable if Local Bias is in use.

On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani 
mailto:an...@alumni.duke.edu>>
wrote:

> Hi Sami,
>
> Thanks for updating the doc.
>
> Regarding this:
> >>>
>
> I find this statement confusing
>
>
>
>While "local-bias" MUST be supported along with GENEVE encapsulation,
>
>the use of the Ethernet option-TLV is RECOMMENDED to follow the same
>
>procedures used by EVPN MPLS.
>
>
>
>
>
> I'm not sure how it helps to carry an extra TLV when it is known
>
> that its absence or presence results in identical behavior.
>
>
>
> Sami: The new TLV is not there only for local bias! It is there for bum and 
> leaf/root indications too. So, we can’t simply not carry it. As for the text 
> above, we are saying setting the ESI label in the TLV will allow us to follow 
> the same Split horizon behavior of MPLS-EVPN with no need for local bias. It 
> is true local bias must be supported but this mechanism will work too if 
> available given that it is optional.
>
> >>>
>
> I'm not sure I follow what you're saying.  The new TLV is actually not
> needed for the Local Bias case because we already know how to make that
> case work without it.  It is, however, needed for the non-Local Bias case
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

Here's a proposed change:

OLD

While "local-bias" MUST be supported along with Geneve encapsulation, the
use of the Ethernet option-TLV is RECOMMENDED to follow the same procedures
used by EVPN MPLS.

NEW

While "local-bias" MUST be supported along with Geneve encapsulation, the
use of the Ethernet option-TLV is required if not using local-bias and
instead following procedures used by EVPN MPLS.

This allows implementations that implement only local bias to skip
sending/implementing the TLV.

Or are you trying to RECOMMEND that implementations also implement the EVPN
MPLS procedures in addition to local bias?  If so, I would word the text as:

While "local-bias" MUST be supported along with Geneve encapsulation and
that doesn't require the use of the Ethernet option-TLV, it is RECOMMENDED
that Geneve implementations also implement the same procedures used by EVPN
MPLS.

On Sat, Dec 17, 2022 at 6:33 PM Anoop Ghanwani 
wrote:

> Sami,
>
> Why is it recommended to carry the TLV if local bias is in use?  (I
> understand the need for it if we're not using local bias.)
>
> Anoop
>
> On Sat, Dec 17, 2022 at 2:06 PM Boutros, Sami  wrote:
>
>> I’m not sure what tightening you are recommending, I am out of ideas of
>> how to tighten this, may be you can propose something.
>>
>>
>>
>> It is quite clear to me and to the authors, and I hope to everyone else,
>> how the TLV can be used for SH as a mechanism similar to local bias, as
>> well it can be used when ETREE support is needed.
>>
>>
>>
>> Thanks,
>>
>>
>> Sami
>>
>> *From: *Anoop Ghanwani 
>> *Date: *Saturday, December 17, 2022 at 1:25 PM
>> *To: *Boutros, Sami 
>> *Cc: *Boutros, Sami , UTTARO, JAMES
>> , Rabadan, Jorge (Nokia - US/Mountain View) <
>> jorge.raba...@nokia.com>, Bocci, Matthew (Nokia - GB) <
>> matthew.bo...@nokia.com>, bess@ietf.org ,
>> draft-ietf-bess-evpn-gen...@ietf.org <
>> draft-ietf-bess-evpn-gen...@ietf.org>
>> *Subject: *Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR
>> and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
>>
>> Sami,
>>
>> I don't believe there was closure on this issue.
>>
>> I think the text around the option TLV being RECOMMENDED should be
>> tightened so that it's recommended only when needed.  The way the draft is
>> currently written, it sounds like it is recommending that the TLV always
>> be
>> carried if multihoming is in use.  But this is not necessary or even
>> valuable if Local Bias is in use.
>>
>> On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani 
>> wrote:
>>
>> > Hi Sami,
>> >
>> > Thanks for updating the doc.
>> >
>> > Regarding this:
>> > >>>
>> >
>> > I find this statement confusing
>> >
>> >
>> >
>> >While "local-bias" MUST be supported along with GENEVE encapsulation,
>> >
>> >the use of the Ethernet option-TLV is RECOMMENDED to follow the same
>> >
>> >procedures used by EVPN MPLS.
>> >
>> >
>> >
>> >
>> >
>> > I'm not sure how it helps to carry an extra TLV when it is known
>> >
>> > that its absence or presence results in identical behavior.
>> >
>> >
>> >
>> > Sami: The new TLV is not there only for local bias! It is there for bum
>> and leaf/root indications too. So, we can’t simply not carry it. As for the
>> text above, we are saying setting the ESI label in the TLV will allow us to
>> follow the same Split horizon behavior of MPLS-EVPN with no need for local
>> bias. It is true local bias must be supported but this mechanism will work
>> too if available given that it is optional.
>> >
>> > >>>
>> >
>> > I'm not sure I follow what you're saying.  The new TLV is actually not
>> > needed for the Local Bias case because we already know how to make that
>> > case work without it.  It is, however, needed for the non-Local Bias
>> case
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

Sami,

Why is it recommended to carry the TLV if local bias is in use?  (I
understand the need for it if we're not using local bias.)

Anoop

On Sat, Dec 17, 2022 at 2:06 PM Boutros, Sami  wrote:

> I’m not sure what tightening you are recommending, I am out of ideas of
> how to tighten this, may be you can propose something.
>
>
>
> It is quite clear to me and to the authors, and I hope to everyone else,
> how the TLV can be used for SH as a mechanism similar to local bias, as
> well it can be used when ETREE support is needed.
>
>
>
> Thanks,
>
>
> Sami
>
> *From: *Anoop Ghanwani 
> *Date: *Saturday, December 17, 2022 at 1:25 PM
> *To: *Boutros, Sami 
> *Cc: *Boutros, Sami , UTTARO, JAMES <
> ju1...@att.com>, Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com>, Bocci, Matthew (Nokia - GB) <
> matthew.bo...@nokia.com>, bess@ietf.org ,
> draft-ietf-bess-evpn-gen...@ietf.org  >
> *Subject: *Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and
> Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
>
> Sami,
>
> I don't believe there was closure on this issue.
>
> I think the text around the option TLV being RECOMMENDED should be
> tightened so that it's recommended only when needed.  The way the draft is
> currently written, it sounds like it is recommending that the TLV always be
> carried if multihoming is in use.  But this is not necessary or even
> valuable if Local Bias is in use.
>
> On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani 
> wrote:
>
> > Hi Sami,
> >
> > Thanks for updating the doc.
> >
> > Regarding this:
> > >>>
> >
> > I find this statement confusing
> >
> >
> >
> >While "local-bias" MUST be supported along with GENEVE encapsulation,
> >
> >the use of the Ethernet option-TLV is RECOMMENDED to follow the same
> >
> >procedures used by EVPN MPLS.
> >
> >
> >
> >
> >
> > I'm not sure how it helps to carry an extra TLV when it is known
> >
> > that its absence or presence results in identical behavior.
> >
> >
> >
> > Sami: The new TLV is not there only for local bias! It is there for bum
> and leaf/root indications too. So, we can’t simply not carry it. As for the
> text above, we are saying setting the ESI label in the TLV will allow us to
> follow the same Split horizon behavior of MPLS-EVPN with no need for local
> bias. It is true local bias must be supported but this mechanism will work
> too if available given that it is optional.
> >
> > >>>
> >
> > I'm not sure I follow what you're saying.  The new TLV is actually not
> > needed for the Local Bias case because we already know how to make that
> > case work without it.  It is, however, needed for the non-Local Bias case
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Boutros, Sami]

I’m not sure what tightening you are recommending, I am out of ideas of how to 
tighten this, may be you can propose something.

It is quite clear to me and to the authors, and I hope to everyone else, how 
the TLV can be used for SH as a mechanism similar to local bias, as well it can 
be used when ETREE support is needed.

Thanks,

Sami
From: Anoop Ghanwani 
Date: Saturday, December 17, 2022 at 1:25 PM
To: Boutros, Sami 
Cc: Boutros, Sami , UTTARO, JAMES 
, Rabadan, Jorge (Nokia - US/Mountain View) 
, Bocci, Matthew (Nokia - GB) 
, bess@ietf.org , 
draft-ietf-bess-evpn-gen...@ietf.org 
Subject: Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and 
Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
Sami,

I don't believe there was closure on this issue.

I think the text around the option TLV being RECOMMENDED should be
tightened so that it's recommended only when needed.  The way the draft is
currently written, it sounds like it is recommending that the TLV always be
carried if multihoming is in use.  But this is not necessary or even
valuable if Local Bias is in use.

On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani 
wrote:

> Hi Sami,
>
> Thanks for updating the doc.
>
> Regarding this:
> >>>
>
> I find this statement confusing
>
>
>
>While "local-bias" MUST be supported along with GENEVE encapsulation,
>
>the use of the Ethernet option-TLV is RECOMMENDED to follow the same
>
>procedures used by EVPN MPLS.
>
>
>
>
>
> I'm not sure how it helps to carry an extra TLV when it is known
>
> that its absence or presence results in identical behavior.
>
>
>
> Sami: The new TLV is not there only for local bias! It is there for bum and 
> leaf/root indications too. So, we can’t simply not carry it. As for the text 
> above, we are saying setting the ESI label in the TLV will allow us to follow 
> the same Split horizon behavior of MPLS-EVPN with no need for local bias. It 
> is true local bias must be supported but this mechanism will work too if 
> available given that it is optional.
>
> >>>
>
> I'm not sure I follow what you're saying.  The new TLV is actually not
> needed for the Local Bias case because we already know how to make that
> case work without it.  It is, however, needed for the non-Local Bias case
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

Sami,

I don't believe there was closure on this issue.

I think the text around the option TLV being RECOMMENDED should be
tightened so that it's recommended only when needed.  The way the draft is
currently written, it sounds like it is recommending that the TLV always be
carried if multihoming is in use.  But this is not necessary or even
valuable if Local Bias is in use.

On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani 
wrote:

> Hi Sami,
>
> Thanks for updating the doc.
>
> Regarding this:
> >>>
>
> I find this statement confusing
>
>
>
>While "local-bias" MUST be supported along with GENEVE encapsulation,
>
>the use of the Ethernet option-TLV is RECOMMENDED to follow the same
>
>procedures used by EVPN MPLS.
>
>
>
>
>
> I'm not sure how it helps to carry an extra TLV when it is known
>
> that its absence or presence results in identical behavior.
>
>
>
> Sami: The new TLV is not there only for local bias! It is there for bum and 
> leaf/root indications too. So, we can’t simply not carry it. As for the text 
> above, we are saying setting the ESI label in the TLV will allow us to follow 
> the same Split horizon behavior of MPLS-EVPN with no need for local bias. It 
> is true local bias must be supported but this mechanism will work too if 
> available given that it is optional.
>
> >>>
>
> I'm not sure I follow what you're saying.  The new TLV is actually not
> needed for the Local Bias case because we already know how to make that
> case work without it.  It is, however, needed for the non-Local Bias case.
> What value is to be had by knowing the frame was a BUM frame?  Since the
> encapsulated frame is an L2 frame, the I/G bit of the address will say if
> it B or M (from BUM).  And if it was unknown unicast and the address is
> unknown at the receiving VTEP, then it will be treated as U, otherwise if
> the address is known, it will be forwarded normally (just as happens today
> in VXLAN without this TLV).  So I'm not understanding what value we get by
> carrying this TLV for Local Bias.  The statement above says we want to
> carry it for consistency.  I'm asking why that consistency is important.
>
> Thanks,
> Anoop
>
> On Mon, May 23, 2022 at 9:38 PM Boutros, Sami  wrote:
>
>> Hi Anoop,
>>
>>
>>
>> Please see comments inline below in red. I updated the document with your
>> relevant comments and uploaded it
>>
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-geneve-04.txt
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Sami
>>
>>
>>
>> Technical comments
>>
>>
>>
>> Section 4.1
>>
>>
>>
>> I find this statement confusing
>>
>>
>>
>>While "local-bias" MUST be supported along with GENEVE encapsulation,
>>
>>the use of the Ethernet option-TLV is RECOMMENDED to follow the same
>>
>>procedures used by EVPN MPLS.
>>
>>
>>
>>
>>
>> I'm not sure how it helps to carry an extra TLV when it is known
>>
>> that its absence or presence results in identical behavior.
>>
>>
>>
>> Sami: The new TLV is not there only for local bias! It is there for bum and 
>> leaf/root indications too. So, we can’t simply not carry it. As for the text 
>> above, we are saying setting the ESI label in the TLV will allow us to 
>> follow the same Split horizon behavior of MPLS-EVPN with no need for local 
>> bias. It is true local bias must be supported but this mechanism will work 
>> too if available given that it is optional.
>>
>>
>>
>> I also find the encoding confusing.  Why is the Type=0, instead of
>>
>> using EVPN-OPTION with a length of 0x1 instead of 0x2?
>>
>> What does Type=0 indicate?  Is this assigned by IANA?
>>
>>
>>
>> Sami: Fixed type to be EVPN-OPTION not 0, and yes we request this from IANA 
>> as per the draft text.
>>
>>
>>
>>
>>
>> Section 6
>>
>>
>>
>> What is inter-AS option B?  Can we provide a reference?
>>
>>
>>
>> Sami: This is a well-known inter-AS option however it is described in the 
>> document itself as follow:
>>
>> “For inter-AS option B, the ASBRs re-advertise these routes
>>
>>with NEXT_HOP attribute set to their IP addresses as per > target="RFC4271"/>.”
>>
>>
>>
>>
>>
>>
>>
>> Section 8
>>
>>
>>
>> Doesn't IANA also need to allocate a codepoint for the
>>
>> EVPN-OPTION type?
>>
>>
>>
>> --
>>
>>
>>
>> Editorial comments
>>
>>
>>
>> Entire document
>>
>>
>>
>> - 3 of the references listed as drafts are now RFCs.  Those should
>>
>>   be fixed both in the reference section and in the text.
>>
>>
>>
>> - There are several uses of GENEVE and Geneve in the document.
>>
>>   Recommend replacing GENEVE with Geneve, including in the
>>
>>   abbreviations and terminology section.
>>
>>
>>
>> Section 1
>>
>>
>>
>> Change
>>
>>
>>
>>This EVPN control plane extension will allow an NVE to express what
>>
>>Geneve option TLV types it is capable of receiving from, or sending
>>
>>to, over the Geneve tunnel with its peers.
>>
>>
>>
>> To
>>
>>
>>
>>This EVPN control plane extension will allow an NVE to express what
>>
>>Geneve option TLV types it is capable of

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

Hi Sami,

Thanks for updating the doc.

Regarding this:
>>>

I find this statement confusing



   While "local-bias" MUST be supported along with GENEVE encapsulation,

   the use of the Ethernet option-TLV is RECOMMENDED to follow the same

   procedures used by EVPN MPLS.





I'm not sure how it helps to carry an extra TLV when it is known

that its absence or presence results in identical behavior.



Sami: The new TLV is not there only for local bias! It is there for
bum and leaf/root indications too. So, we can’t simply not carry it.
As for the text above, we are saying setting the ESI label in the TLV
will allow us to follow the same Split horizon behavior of MPLS-EVPN
with no need for local bias. It is true local bias must be supported
but this mechanism will work too if available given that it is
optional.

>>>

I'm not sure I follow what you're saying.  The new TLV is actually not
needed for the Local Bias case because we already know how to make that
case work without it.  It is, however, needed for the non-Local Bias case.
What value is to be had by knowing the frame was a BUM frame?  Since the
encapsulated frame is an L2 frame, the I/G bit of the address will say if
it B or M (from BUM).  And if it was unknown unicast and the address is
unknown at the receiving VTEP, then it will be treated as U, otherwise if
the address is known, it will be forwarded normally (just as happens today
in VXLAN without this TLV).  So I'm not understanding what value we get by
carrying this TLV for Local Bias.  The statement above says we want to
carry it for consistency.  I'm asking why that consistency is important.

Thanks,
Anoop

On Mon, May 23, 2022 at 9:38 PM Boutros, Sami  wrote:

> Hi Anoop,
>
>
>
> Please see comments inline below in red. I updated the document with your
> relevant comments and uploaded it
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-geneve-04.txt
>
>
>
> Thanks,
>
>
>
> Sami
>
>
>
> Technical comments
>
>
>
> Section 4.1
>
>
>
> I find this statement confusing
>
>
>
>While "local-bias" MUST be supported along with GENEVE encapsulation,
>
>the use of the Ethernet option-TLV is RECOMMENDED to follow the same
>
>procedures used by EVPN MPLS.
>
>
>
>
>
> I'm not sure how it helps to carry an extra TLV when it is known
>
> that its absence or presence results in identical behavior.
>
>
>
> Sami: The new TLV is not there only for local bias! It is there for bum and 
> leaf/root indications too. So, we can’t simply not carry it. As for the text 
> above, we are saying setting the ESI label in the TLV will allow us to follow 
> the same Split horizon behavior of MPLS-EVPN with no need for local bias. It 
> is true local bias must be supported but this mechanism will work too if 
> available given that it is optional.
>
>
>
> I also find the encoding confusing.  Why is the Type=0, instead of
>
> using EVPN-OPTION with a length of 0x1 instead of 0x2?
>
> What does Type=0 indicate?  Is this assigned by IANA?
>
>
>
> Sami: Fixed type to be EVPN-OPTION not 0, and yes we request this from IANA 
> as per the draft text.
>
>
>
>
>
> Section 6
>
>
>
> What is inter-AS option B?  Can we provide a reference?
>
>
>
> Sami: This is a well-known inter-AS option however it is described in the 
> document itself as follow:
>
> “For inter-AS option B, the ASBRs re-advertise these routes
>
>with NEXT_HOP attribute set to their IP addresses as per  target="RFC4271"/>.”
>
>
>
>
>
>
>
> Section 8
>
>
>
> Doesn't IANA also need to allocate a codepoint for the
>
> EVPN-OPTION type?
>
>
>
> --
>
>
>
> Editorial comments
>
>
>
> Entire document
>
>
>
> - 3 of the references listed as drafts are now RFCs.  Those should
>
>   be fixed both in the reference section and in the text.
>
>
>
> - There are several uses of GENEVE and Geneve in the document.
>
>   Recommend replacing GENEVE with Geneve, including in the
>
>   abbreviations and terminology section.
>
>
>
> Section 1
>
>
>
> Change
>
>
>
>This EVPN control plane extension will allow an NVE to express what
>
>Geneve option TLV types it is capable of receiving from, or sending
>
>to, over the Geneve tunnel with its peers.
>
>
>
> To
>
>
>
>This EVPN control plane extension will allow an NVE to express what
>
>Geneve option TLV types it is capable of receiving or sending
>
>over the Geneve tunnel with its peers.
>
>
>
>
>
> Section 4
>
>
>
> Change
>
>
>
>This document adds an extension to the [I-D.ietf-nvo3-geneve
>
>   [datatracker.ietf.org] 
> >]
>
>encapsulation that are relevant to the operation of EVPN.
>
>
>
> To
>
>
>
>This document adds an extension to the [I-D.ietf-nvo3-geneve
>
> 

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Boutros, Sami]

Hi Anoop,

Please see comments inline below in red. I updated the document with your 
relevant comments and uploaded it

https://www.ietf.org/archive/id/draft-ietf-bess-evpn-geneve-04.txt

Thanks,

Sami


Technical comments



Section 4.1



I find this statement confusing



   While "local-bias" MUST be supported along with GENEVE encapsulation,

   the use of the Ethernet option-TLV is RECOMMENDED to follow the same

   procedures used by EVPN MPLS.





I'm not sure how it helps to carry an extra TLV when it is known

that its absence or presence results in identical behavior.



Sami: The new TLV is not there only for local bias! It is there for bum and 
leaf/root indications too. So, we can’t simply not carry it. As for the text 
above, we are saying setting the ESI label in the TLV will allow us to follow 
the same Split horizon behavior of MPLS-EVPN with no need for local bias. It is 
true local bias must be supported but this mechanism will work too if available 
given that it is optional.



I also find the encoding confusing.  Why is the Type=0, instead of

using EVPN-OPTION with a length of 0x1 instead of 0x2?

What does Type=0 indicate?  Is this assigned by IANA?



Sami: Fixed type to be EVPN-OPTION not 0, and yes we request this from IANA as 
per the draft text.





Section 6



What is inter-AS option B?  Can we provide a reference?



Sami: This is a well-known inter-AS option however it is described in the 
document itself as follow:

“For inter-AS option B, the ASBRs re-advertise these routes

   with NEXT_HOP attribute set to their IP addresses as per .”







Section 8



Doesn't IANA also need to allocate a codepoint for the

EVPN-OPTION type?



--



Editorial comments



Entire document



- 3 of the references listed as drafts are now RFCs.  Those should

  be fixed both in the reference section and in the text.



- There are several uses of GENEVE and Geneve in the document.

  Recommend replacing GENEVE with Geneve, including in the

  abbreviations and terminology section.



Section 1



Change



   This EVPN control plane extension will allow an NVE to express what

   Geneve option TLV types it is capable of receiving from, or sending

   to, over the Geneve tunnel with its peers.



To



   This EVPN control plane extension will allow an NVE to express what

   Geneve option TLV types it is capable of receiving or sending

   over the Geneve tunnel with its peers.





Section 4



Change



   This document adds an extension to the [I-D.ietf-nvo3-geneve

>]

   encapsulation that are relevant to the operation of EVPN.



To



   This document adds an extension to the [I-D.ietf-nvo3-geneve

>]

   encapsulation that is relevant to the operation of EVPN.



End



Section 4.1



Change



   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses

   ingress replication to flood unknown unicast traffic to the egress

   NVEs, the ingress NVE needs to indicate to the egress NVE that the

   Encapsulated packet is a BUM traffic type.



To



   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses

   ingress replication to flood unknown unicast traffic to the egress

   NVEs, the ingress NVE needs to indicate to the egress NVE that the

   Encapsulated packet is a BUM packet.





Change



   For GENEVE, we need a bit to for this purpose.



To



   For GENEVE, we need a bit for this purpose.





Expand first use of AC and add to abbreviations and terminology.



ecnapsulations -> encapsulations





GENVE -> Geneve



(There are 2 instances of this.)





"20- bit MPLS label" -> "20-bit MPLS label"





Add figure captions for the 2 figures showing the TLVs.



Expand first use of ES and ESI and add to abbreviations and terminology.



Change



   The ESI-label value is encoded in the high-order 20 bits

   of the Source-ESI field.



To



   The ESI-label value is encoded in the high-order 20 bits

   of the Source-ID field.





Change



   The egress NVEs that make use of ESIs in the data path because they

   have a local multi-homed ES or support [RFC8317

>]
 SHOULD advertise

   their Ethernet A-D p

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

I support the publication of this draft.  I have the following comments
and suggested edits.

--

Technical comments

Section 4.1

I find this statement confusing

   While "local-bias" MUST be supported along with GENEVE encapsulation,
   the use of the Ethernet option-TLV is RECOMMENDED to follow the same
   procedures used by EVPN MPLS.


I'm not sure how it helps to carry an extra TLV when it is known
that its absence or presence results in identical behavior.

I also find the encoding confusing.  Why is the Type=0, instead of
using EVPN-OPTION with a length of 0x1 instead of 0x2?
What does Type=0 indicate?  Is this assigned by IANA?

Section 6

What is inter-AS option B?  Can we provide a reference?

Section 8

Doesn't IANA also need to allocate a codepoint for the
EVPN-OPTION type?

--

Editorial comments

Entire document

- 3 of the references listed as drafts are now RFCs.  Those should
  be fixed both in the reference section and in the text.

- There are several uses of GENEVE and Geneve in the document.
  Recommend replacing GENEVE with Geneve, including in the
  abbreviations and terminology section.

Section 1

Change

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving from, or sending
   to, over the Geneve tunnel with its peers.

To

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving or sending
   over the Geneve tunnel with its peers.


Section 4

Change

   This document adds an extension to the [I-D.ietf-nvo3-geneve
]
   encapsulation that are relevant to the operation of EVPN.

To

   This document adds an extension to the [I-D.ietf-nvo3-geneve
]
   encapsulation that is relevant to the operation of EVPN.

End

Section 4.1

Change

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM traffic type.

To

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM packet.


Change

   For GENEVE, we need a bit to for this purpose.

To

   For GENEVE, we need a bit for this purpose.


Expand first use of AC and add to abbreviations and terminology.

ecnapsulations -> encapsulations


GENVE -> Geneve

(There are 2 instances of this.)


"20- bit MPLS label" -> "20-bit MPLS label"


Add figure captions for the 2 figures showing the TLVs.

Expand first use of ES and ESI and add to abbreviations and terminology.

Change

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ESI field.

To

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ID field.


Change

   The egress NVEs that make use of ESIs in the data path because they
   have a local multi-homed ES or support [RFC8317
] SHOULD advertise
   their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV
   and in addition to the ESI-label Extended Community.

Remove "and".


On Tue, Sep 28, 2021 at 8:47 AM Boutros, Sami  wrote:

> I support the publication and not aware of any IPR.
>
>
>
> Thanks,
>
>
>
> Sami
>
> *From: *"UTTARO, JAMES" 
> *Date: *Tuesday, September 28, 2021 at 7:29 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" <
> bess@ietf.org>
> *Cc: *"draft-ietf-bess-evpn-gen...@ietf.org" <
> draft-ietf-bess-evpn-gen...@ietf.org>
> *Subject: *[**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and
> Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
> *Resent-From: *
> *Resent-To: *, , <
> sbout...@ciena.com>, , 
> *Resent-Date: *Tuesday, September 28, 2021 at 7:29 AM
>
>
>
> *Support.*
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *From:* BESS  *On Behalf Of * Rabadan, Jorge
> (Nokia - US/Mountain View)
> *Sent:* Tuesday, September 28, 2021 5:04 AM
> *To:* Bocci, Matthew (Nokia - GB) ; bess@ietf.org
> *Cc:* draft-ietf-bess-evpn-gen...@ietf.org
> *Subject:* Re: [bess] CORRECTION WG Last Call, IPR and Implementation
> Poll for *draft-ietf-bess-evpn-geneve-03*
>
>
>
> As co-author, I support this document for publication as standards track
> RFC.
>
> Not aware of any relevant IPR.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Bocci, Matthew (Nokia - GB) 
> *Date: *Tuesday, September 28, 2021 at 11:00 AM
> *To: *bess@ietf.org 
> *Cc: *draft-ietf-bess-evpn-gen...@ietf.org <
> draft-ietf-bess-evpn-gen...@ietf.org>
> *Subject: *CORRECTION WG Last Call, IPR and Implementation Poll

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Boutros, Sami]

I support the publication and not aware of any IPR.

Thanks,

Sami
From: "UTTARO, JAMES" 
Date: Tuesday, September 28, 2021 at 7:29 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Cc: "draft-ietf-bess-evpn-gen...@ietf.org" 

Subject: [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation 
Poll for *draft-ietf-bess-evpn-geneve-03*
Resent-From: 
Resent-To: , , 
, , 
Resent-Date: Tuesday, September 28, 2021 at 7:29 AM

Support.

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Tuesday, September 28, 2021 5:04 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: draft-ietf-bess-evpn-gen...@ietf.org
Subject: Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*

As co-author, I support this document for publication as standards track RFC.
Not aware of any relevant IPR.

Thanks.
Jorge

From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, September 28, 2021 at 11:00 AM
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*
Folks

Please note this WG last call is for version 03 of the draft (not 02 as stated 
in the subject line of the email)

The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
for 
Geneve

Apologies for the error.

Matthew

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, 28 September 2021 at 09:56
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-geneve-02
This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors and contributors.
There are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess