Re: [bess] Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

[Anoop Ghanwani]

Thanks Jorge!

On Wed, Dec 19, 2018 at 1:18 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Anoop,
>
> Thank you for your review. We took all your comments.
> Please see in-line how we are resolving them in rev 07.
>
> Thanks.
> Jorge
>
> -Original Message-
> From: BESS  on behalf of "Satya Mohanty (satyamoh)" 
> 
> Date: Friday, December 7, 2018 at 6:09 PM
> To: Anoop Ghanwani , "bess@ietf.org" 
> Subject: Re: [bess] Last Call: 
>  (Framework for EVPN 
> Designated Forwarder Election Extensibility) to Proposed Standard
>
> Hi Anoop,
>
> Thank you very much for your editorial comments and review.
> We will take care of it.
>
> Best,
> --Satya
>
>
> On 12/7/18, 1:01 AM, "BESS on behalf of Anoop Ghanwani" 
>  wrote:
>
> I have reviewed the doc and I have mostly editorial comments.
>
> Thanks,
> Anoop
>
> ==
>
> Throughout
>
> VLAN Bundle, VLAN bundle, VLAN-Bundle, VLAN-bundle -- make consistent
> VLAN Aware Bundle, VLAN-aware bundle, VLAN-Aware Bundle -- make 
> consistent
> bridge table, Bridge Table -- make consistent (also add definition to
> terminology section)
> DF election, DF Election -- make consistent
> Default DF Election, default DF Election -- make consistent
> non-DF -> NDF
> [JORGE] done, thx
>
> Section 1
>
> double Q-in-Q tags -> Q-in-Q tags
>
> double is redundant
> [JORGE] done, thx
>
> Section 2.1
>
> Fig 1 is a bit confusing.  If the idea of the rectangle is to show a
> core, then why have connections between PE1 and PE2, PE3, but not
> between PE1 and PE4?
> [JORGE] good point, fixed it, thx
>
> Change
> >>>
> Layer-2 devices are particularly susceptible to forwarding loops
> because of the broadcast nature of the Ethernet traffic.
> >>>
> to
> The effect of forwarding loops in a Layer-2 network is particularly
> severe because of the broadcast nature of Ethernet traffic and the
> lack of a TTL.
> [JORGE] done, thanks.
>
> Section 2.2.1
>
> a v4 or v6 peering -> an IPv4 or IPv6 peering
> [JORGE] done, thanks.
>
> >>>
> >From a forwarding perspective, this is
> a churn, as it results in re-programming the PE ports as either
> blocking or non-blocking at potentially all PEs when the DF changes.
> >>>
>
> Why would the reprogramming change at all PEs?  It should change for
> at most 2 PEs for each (ES,EVI) being reprogrammed.  Maybe authors
> were trying to convey something else?
> [JORGE] changed to:
> ***From a forwarding perspective, this is
>a churn, as it results in re-programming the PE ports as either
>blocking or non-blocking at the PEs where the DF state changes.***
>
>
> Section 2.3
>
> >>>
> DF Election procedure Generally
> >>>
> Missing a period.
> [JORGE] done, thanks.
>
>
> Section 3
>
> specification in EVPN -> EVPN specification
> [JORGE] done, thanks.
>
>
> Section 3.1
>
> DF WAIT, DF_WAIT -- make consistent
> [JORGE] done, thanks.
>
> DF Wait timer -- where is this defined?
> [JORGE] This is defined in [RFC7432]. I added a reference.
>
> Ethernet Segment Route -> Ethernet Segment route
> stop DF timer ->  stop DF wait timer (?)
> start DF timer -> start DF wait timer (?)
> [JORGE] done, thanks.
>
> Section 4
>
> rather than the state of the server states -> rather than the state of
> the server (?)
> [JORGE] done, thanks.
>
> Section 4.2
>
> Si is the IP address of server i -> Si is the IP address of PE i
> [JORGE] done, thanks.
>
> operator chooses so -> operator so chooses
> [JORGE] done, thanks.
>
> Note 0 <= i,j <= Number of PEs -- should this be "< Number of PEs"?
> Weight(V, Es, Sk) -> Weight(v, Es, Sk)
> Pseudo-random -> pseudo-random
> efficient deterministic -> efficient and deterministic
> V4 -> IPv4
> V6 -> IPv6
> [JORGE] all of them changed. Thanks.
>
> ___
> 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

Re: [bess] Comment on draft-ietf-bess-service-chaining-06

[Andrew G. Malis]

Stuart,

Thanks for your reply. I can see your point about wanting to do service
chaining without the NSH (as I'm sure you're aware, draft-ietf-mpls-sfc is
another example of this), but would you never have the need for service
chain per-packet metadata as it's being used in the SFC WG?

Even if the answer to that question is currently no, my other point remains
that this draft provides an excellent label distribution mechanism for NSH
over MPLS, which usage I'm confident will be defined in the future. I agree
that doesn't require an anticipatory reference in the draft. But it might
be nice ... :-)

Cheers,
Andy


On Wed, Dec 19, 2018 at 5:59 PM Stuart Mackie  wrote:

> Hi Andy,
>
>
>
> I‘m struggling to make the connection, since
> draft-ietf-bess-service-chaining is specifically about how to do service
> chaining without needing a new protocol like NSH, so SFF labels would never
> be used.
>
>
>
> In draft-ietf-bess-service-chaining , if MPLS transport were used between
> Service Function Forwarders, a label would be allocated for a SF interface
> when a route pointing to it is installed (by the controller). This would be
> advertised to the controller and from there sent to the forwarders with
> egress interfaces for the previous SF in the chain. The label would be used
> at the bottom of the MPLS stack as is done normally.
>
>
>
> Cheers
>
>
>
> Stuart
>
> -914 886 2534
>
>
>
> *From: *"Andrew G. Malis" 
> *Date: *Tuesday, December 4, 2018 at 5:10 PM
> *To: *"bess@ietf.org" , "
> draft-ietf-bess-service-chain...@ietf.org" <
> draft-ietf-bess-service-chain...@ietf.org>
> *Cc: *"draft-ietf-mpls-sfc-encapsulat...@ietf.org" <
> draft-ietf-mpls-sfc-encapsulat...@ietf.org>
> *Subject: *Comment on draft-ietf-bess-service-chaining-06
> *Resent-From: *
> *Resent-To: *, , , <
> brunorijs...@gmail.com>, , 
> *Resent-Date: *Tuesday, December 4, 2018 at 5:10 PM
>
>
>
> I just read the new revision of draft-ietf-bess-service-chaining. Although
> the draft doesn't use the RFC 8300 NSH, it could very easily take advantage
> of features provided by the NSH (such as metadata) by adding NSH over MPLS
> as defined in draft-ietf-mpls-sfc-encapsulation to the list of
> encapsulations listed in section 2.5. And this draft provides an excellent
> label distribution mechanism for NSH over MPLS. It would make a lot of
> sense to add a reference to draft-ietf-mpls-sfc-encapsulation in the list
> of encapsulations in section 2.5.
>
>
>
> Thanks,
>
> Andy
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comment on draft-ietf-bess-service-chaining-06

[Stuart Mackie]

Hi Andy,

I‘m struggling to make the connection, since draft-ietf-bess-service-chaining 
is specifically about how to do service chaining without needing a new protocol 
like NSH, so SFF labels would never be used.

In draft-ietf-bess-service-chaining , if MPLS transport were used between 
Service Function Forwarders, a label would be allocated for a SF interface when 
a route pointing to it is installed (by the controller). This would be 
advertised to the controller and from there sent to the forwarders with egress 
interfaces for the previous SF in the chain. The label would be used at the 
bottom of the MPLS stack as is done normally.

Cheers

Stuart
-914 886 2534

From: "Andrew G. Malis" 
Date: Tuesday, December 4, 2018 at 5:10 PM
To: "bess@ietf.org" , 
"draft-ietf-bess-service-chain...@ietf.org" 

Cc: "draft-ietf-mpls-sfc-encapsulat...@ietf.org" 

Subject: Comment on draft-ietf-bess-service-chaining-06
Resent-From: 
Resent-To: , , , 
, , 
Resent-Date: Tuesday, December 4, 2018 at 5:10 PM

I just read the new revision of draft-ietf-bess-service-chaining. Although the 
draft doesn't use the RFC 8300 NSH, it could very easily take advantage of 
features provided by the NSH (such as metadata) by adding NSH over MPLS as 
defined in draft-ietf-mpls-sfc-encapsulation to the list of encapsulations 
listed in section 2.5. And this draft provides an excellent label distribution 
mechanism for NSH over MPLS. It would make a lot of sense to add a reference to 
draft-ietf-mpls-sfc-encapsulation in the list of encapsulations in section 2.5.

Thanks,
Andy

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

[bess] bess - New Meeting Session Request for IETF 104

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by mankamana prasad 
mishra, a Secretary of the bess working group.


-
Working Group Name: BGP Enabled ServiceS
Area Name: Routing Area
Session Requester: mankamana mishra

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 80
Conflicts to Avoid: 
 First Priority:  idr nvo3
 Second Priority:  spring sfc mpls pim bier pals
 Third Priority:  i2rs l2sm


People who must be present:
  Matthew Bocci
  Martin Vigoureux
  Stephane Litkowski
  mankamana prasad mishra

Resources Requested:

Special Requests:
  last few sessions had a very busy agenda, it would be great to get 2h30  
slot. 
-

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

Re: [bess] Referencing material behind a paywall

[Satya Mohanty (satyamoh)]

Thank you Stephen, Carsten and Heather for your input.
Jorge will be publishing the revised version soon.

Best Regards,
--Satya

On 12/10/18, 2:14 PM, "Stephen Farrell"  wrote:



On 10/12/2018 20:41, Heather Flanagan wrote:
> Ekr offered an interesting proposal that would have this kind of
> reference be treated in a fashion similar to IPR declarations.

Not a bad idea. I'd also make it like the downref registry [1]
though, since once we've got a normative reference in one RFC
to e.g. some IEEE 802 thing, then it shouldn't need new process
to have a 2nd RFC do the same.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/downref/


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

[bess] Genart last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05

[Pete Resnick]

Reviewer: Pete Resnick
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-evpn-vpls-seamless-integ-0
Reviewer: Pete Resnick
Review Date: 2018-12-19
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with some nits, but one process issue/query.

Major issues: None

Minor issues:

This document is intended for Proposed Standard. It doesn't have protocol as
much as operational configuration information for integration. RFC 2026 section
5 says:

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.
   [...]
   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.

That sounds like what this document is doing. It also sounds like this document
is unlike to advance to Internet Standard, as there's not the kind of iterative
implementation that protocols go through. It's not a big deal either way, but
this does seem better suited to a BCP.

Nits/editorial comments:

Abstract: s/draft/document/g

Introduction: "Many Service Providers (SPs) who...". You don't use "SP"
anywhere else in the document, and other places where you use the phrase it
isn't capitalized. Suggest just saying "Many service providers who..."

§1, Definitions:

   (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this
   abbreviation is used when the text applies to both technologies.

It says EVPN in the second sentence. I don't understand. Did you mean VPLS?

§2: The 4 "MUST"s and 1 "MAY" aren't requirements on the implementation;
they're the requirements this document will satisfy. Seems like they shouldn't
be capitalized.

§3.2, second bullet, 3.4.1, last paragraph, §4.2, second bullet, and §4.4.1,
last paragraph: Why are the "must"s not capitalized?


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

Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited

[Greg Mirsky]

Hi Anoop, et al.,
appreciate your check of the final version of the update to the draft.
Below is the new text as in the working version:
   One use of VXLAN is in data centers interconnecting VMs of a tenant.
   VXLAN addresses requirements of the Layer 2 and Layer 3 data center
   network infrastructure in the presence of VMs in a multi-tenant
   environment, discussed in section 3 [RFC7348], by providing Layer 2
   overlay scheme on a Layer 3 network.  Another use is as an
   encapsulation for Ethernet VPN [RFC8365].

   This document is written assuming the use of VXLAN for virtualized
   hosts and refers to VMs and VTEPs in hypervisors.  However, the
   concepts are equally applicable to non-virtualized hosts attached to
   VTEPs in switches.

Kind regards,
Greg

On Wed, Dec 19, 2018 at 6:28 AM Greg Mirsky  wrote:

> Hi Anoop,
> thank you for the great text you've contributed. Accepted. I'll update the
> working text and publish later today.
>
> Kind regards,
> Greg
>
> On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman) 
> wrote:
>
>> +1 to Anoop's comments. I've made similar comment to Greg privately, and
>> Anoop's proposed text clears things up.
>>
>> Regards,
>> Reshad (no hat).
>>
>> On 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" <
>> rtg-bfd-boun...@ietf.org on behalf of an...@alumni.duke.edu> wrote:
>>
>> Hi Greg,
>>
>> Yes this captures what I was trying to get added.
>>
>> Perhaps the last sentence can be changed to:
>>
>> "This document is written assuming the use of VXLAN for virtualized
>> hosts and refers to VMs and VTEPs in hypervisors.  However, the
>> concepts are equally applicable to non-virtualized hosts attached to
>> VTEPs in switches."
>>
>> Thanks,
>> Anoop
>>
>> On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky 
>> wrote:
>> >
>> > Hi Anoop,
>> > thank you for your comments and the suggested text. To clarify the
>> extent of the update, would the following accurately reflect the change in
>> Introduction you're proposing:
>> > OLD TEXT:
>> >VXLAN is typically deployed in data centers interconnecting
>> >virtualized hosts of a tenant.  VXLAN addresses requirements of
>> the
>> >Layer 2 and Layer 3 data center network infrastructure in the
>> >presence of VMs in a multi-tenant environment, discussed in
>> section 3
>> >[RFC7348], by providing Layer 2 overlay scheme on a Layer 3
>> network.
>> > NEW TEXT:
>> >   One use of VXLAN is in data centers interconnecting
>> >   VMs of a tenant.  VXLAN addresses requirements of the
>> >Layer 2 and Layer 3 data center network infrastructure in the
>> >presence of VMs in a multi-tenant environment, discussed in
>> section 3
>> >of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
>> network.
>> >Another use is as an encapsulation for EVPN [RFC 8365].
>> >
>> >   In the remainder of this document the terms VM and End Station
>> >   are used interchangeably.
>> >
>> > If my understanding of the proposed update is correct, I'd be glad
>> to use it (adding RFC 8365 as Informational reference).  Should note that
>> in the draft we never used "End Station". Perhaps the last sentence is not
>> required.
>> >
>> > What do you think?
>> >
>> > Regards,
>> > Greg
>> >
>> > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani <
>> an...@alumni.duke.edu> wrote:
>> >>
>> >> I would change the introduction to the following to mention the
>> use of
>> >> VXLAN by BGP EVPN.
>> >>
>> >> Thanks,
>> >> Anoop
>> >>
>> >> ==
>> >>
>> >>"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348]
>> provides
>> >>an encapsulation scheme that allows building an overlay network
>> by
>> >>decoupling the address space of the attached virtual hosts from
>> that
>> >>of the network.
>> >>
>> >>   One use of VXLAN is in data centers interconnecting
>> >>   VMs of a tenant.  VXLAN addresses requirements of the
>> >>Layer 2 and Layer 3 data center network infrastructure in the
>> >>presence of VMs in a multi-tenant environment, discussed in
>> section 3
>> >>of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
>> network.
>> >>Another use is as an encapsulation for EVPN [RFC 8365].
>> >>
>> >>   In the remainder of this document the terms VM and End Station
>> >>   are used interchangeably.
>> >>
>> >>In the absence of a router in the overlay, a VM can communicate
>> with
>> >>another VM only if they are on the same VXLAN segment.  VMs are
>> >>unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a
>> VXLAN
>> >>Tunnel End Point (VTEP) (hypervisor/TOR).  VTEPs
>> (hypervisor/TOR) are
>> >>responsible for encapsulating and decapsulating frames exchanged
>> >>among VMs.
>> >>

Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited

[Greg Mirsky]

Hi Anoop,
thank you for the great text you've contributed. Accepted. I'll update the
working text and publish later today.

Kind regards,
Greg

On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman) 
wrote:

> +1 to Anoop's comments. I've made similar comment to Greg privately, and
> Anoop's proposed text clears things up.
>
> Regards,
> Reshad (no hat).
>
> On 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" <
> rtg-bfd-boun...@ietf.org on behalf of an...@alumni.duke.edu> wrote:
>
> Hi Greg,
>
> Yes this captures what I was trying to get added.
>
> Perhaps the last sentence can be changed to:
>
> "This document is written assuming the use of VXLAN for virtualized
> hosts and refers to VMs and VTEPs in hypervisors.  However, the
> concepts are equally applicable to non-virtualized hosts attached to
> VTEPs in switches."
>
> Thanks,
> Anoop
>
> On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky 
> wrote:
> >
> > Hi Anoop,
> > thank you for your comments and the suggested text. To clarify the
> extent of the update, would the following accurately reflect the change in
> Introduction you're proposing:
> > OLD TEXT:
> >VXLAN is typically deployed in data centers interconnecting
> >virtualized hosts of a tenant.  VXLAN addresses requirements of
> the
> >Layer 2 and Layer 3 data center network infrastructure in the
> >presence of VMs in a multi-tenant environment, discussed in
> section 3
> >[RFC7348], by providing Layer 2 overlay scheme on a Layer 3
> network.
> > NEW TEXT:
> >   One use of VXLAN is in data centers interconnecting
> >   VMs of a tenant.  VXLAN addresses requirements of the
> >Layer 2 and Layer 3 data center network infrastructure in the
> >presence of VMs in a multi-tenant environment, discussed in
> section 3
> >of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
> network.
> >Another use is as an encapsulation for EVPN [RFC 8365].
> >
> >   In the remainder of this document the terms VM and End Station
> >   are used interchangeably.
> >
> > If my understanding of the proposed update is correct, I'd be glad
> to use it (adding RFC 8365 as Informational reference).  Should note that
> in the draft we never used "End Station". Perhaps the last sentence is not
> required.
> >
> > What do you think?
> >
> > Regards,
> > Greg
> >
> > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani <
> an...@alumni.duke.edu> wrote:
> >>
> >> I would change the introduction to the following to mention the use
> of
> >> VXLAN by BGP EVPN.
> >>
> >> Thanks,
> >> Anoop
> >>
> >> ==
> >>
> >>"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348]
> provides
> >>an encapsulation scheme that allows building an overlay network
> by
> >>decoupling the address space of the attached virtual hosts from
> that
> >>of the network.
> >>
> >>   One use of VXLAN is in data centers interconnecting
> >>   VMs of a tenant.  VXLAN addresses requirements of the
> >>Layer 2 and Layer 3 data center network infrastructure in the
> >>presence of VMs in a multi-tenant environment, discussed in
> section 3
> >>of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
> network.
> >>Another use is as an encapsulation for EVPN [RFC 8365].
> >>
> >>   In the remainder of this document the terms VM and End Station
> >>   are used interchangeably.
> >>
> >>In the absence of a router in the overlay, a VM can communicate
> with
> >>another VM only if they are on the same VXLAN segment.  VMs are
> >>unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a
> VXLAN
> >>Tunnel End Point (VTEP) (hypervisor/TOR).  VTEPs
> (hypervisor/TOR) are
> >>responsible for encapsulating and decapsulating frames exchanged
> >>among VMs.
> >>
> >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas 
> wrote:
> >> >
> >> > BESS Working Group members,
> >> >
> >> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04
> >> >
> >> > BFD has finished working group last call on BFD for Vxlan and is
> about ready
> >> > to request publication as an RFC.  A last minute comment
> suggested that we
> >> > should consider inviting comment from your working group for
> expertise.
> >> >
> >> > We will be leaving the last call open until December 21 to leave
> time for
> >> > final comments.
> >> >
> >> > -- Jeff (for BFD)
> >> >
> >> > ___
> >> > BESS mailing list
> >> > BESS@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/bess
> >>
> >> ___
> >> BESS mailing list
> >> BESS@ietf.org
> >> 

Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited

[Reshad Rahman (rrahman)]

+1 to Anoop's comments. I've made similar comment to Greg privately, and 
Anoop's proposed text clears things up.

Regards,
Reshad (no hat).

On 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" 
 wrote:

Hi Greg,

Yes this captures what I was trying to get added.

Perhaps the last sentence can be changed to:

"This document is written assuming the use of VXLAN for virtualized
hosts and refers to VMs and VTEPs in hypervisors.  However, the
concepts are equally applicable to non-virtualized hosts attached to
VTEPs in switches."

Thanks,
Anoop

On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky  wrote:
>
> Hi Anoop,
> thank you for your comments and the suggested text. To clarify the extent 
of the update, would the following accurately reflect the change in 
Introduction you're proposing:
> OLD TEXT:
>VXLAN is typically deployed in data centers interconnecting
>virtualized hosts of a tenant.  VXLAN addresses requirements of the
>Layer 2 and Layer 3 data center network infrastructure in the
>presence of VMs in a multi-tenant environment, discussed in section 3
>[RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network.
> NEW TEXT:
>   One use of VXLAN is in data centers interconnecting
>   VMs of a tenant.  VXLAN addresses requirements of the
>Layer 2 and Layer 3 data center network infrastructure in the
>presence of VMs in a multi-tenant environment, discussed in section 3
>of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network.
>Another use is as an encapsulation for EVPN [RFC 8365].
>
>   In the remainder of this document the terms VM and End Station
>   are used interchangeably.
>
> If my understanding of the proposed update is correct, I'd be glad to use 
it (adding RFC 8365 as Informational reference).  Should note that in the draft 
we never used "End Station". Perhaps the last sentence is not required.
>
> What do you think?
>
> Regards,
> Greg
>
> On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani  
wrote:
>>
>> I would change the introduction to the following to mention the use of
>> VXLAN by BGP EVPN.
>>
>> Thanks,
>> Anoop
>>
>> ==
>>
>>"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides
>>an encapsulation scheme that allows building an overlay network by
>>decoupling the address space of the attached virtual hosts from that
>>of the network.
>>
>>   One use of VXLAN is in data centers interconnecting
>>   VMs of a tenant.  VXLAN addresses requirements of the
>>Layer 2 and Layer 3 data center network infrastructure in the
>>presence of VMs in a multi-tenant environment, discussed in section 3
>>of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 
network.
>>Another use is as an encapsulation for EVPN [RFC 8365].
>>
>>   In the remainder of this document the terms VM and End Station
>>   are used interchangeably.
>>
>>In the absence of a router in the overlay, a VM can communicate with
>>another VM only if they are on the same VXLAN segment.  VMs are
>>unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VXLAN
>>Tunnel End Point (VTEP) (hypervisor/TOR).  VTEPs (hypervisor/TOR) are
>>responsible for encapsulating and decapsulating frames exchanged
>>among VMs.
>>
>> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas  wrote:
>> >
>> > BESS Working Group members,
>> >
>> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04
>> >
>> > BFD has finished working group last call on BFD for Vxlan and is about 
ready
>> > to request publication as an RFC.  A last minute comment suggested 
that we
>> > should consider inviting comment from your working group for expertise.
>> >
>> > We will be leaving the last call open until December 21 to leave time 
for
>> > final comments.
>> >
>> > -- Jeff (for BFD)
>> >
>> > ___
>> > 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

Re: [bess] Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Neeraj,

Thank you very much for reviewing.

Besides John’s reply to your second comment, about the first comment, based on 
the feedback from the reviewers, we changed that sentence to:

   The effect of forwarding loops in a Layer-2 network is particularly
   severe because of the broadcast nature of Ethernet traffic and the
   lack of a TTL.

Thank you.
Jorge

From: BESS  on behalf of John E Drake 

Date: Tuesday, December 18, 2018 at 7:22 PM
To: Neeraj Malhotra 
Cc: "bess@ietf.org" 
Subject: Re: [bess] Last Call: 
 (Framework for EVPN 
Designated Forwarder Election Extensibility) to Proposed Standard

Comment inline
Sent from my iPhone

On Dec 18, 2018, at 12:33 PM, Neeraj Malhotra 
mailto:neeraj.i...@gmail.com>> wrote:

Hi,

Very solid and understandable. Couple of minor comments [NM]:

Section 2.1: Layer-2 devices are particularly susceptible to forwarding loops 
because of the broadcast nature of the Ethernet traffic.

[NM]: better to refer to "Layer-2 services" instead of "Layer-2 devices" as the 
CE or PE devices themselves may be layer-3 capable.

Section 4.2: Note that while the DF election algorithm in [RFC7432] uses PE 
address and vlan as inputs, this document uses Ethernet Tag, PE address and ESI 
as inputs.

[NM]: I think the text in this context uses "vlan" and "Ethernet Tag" 
interchangeably. Since the above is trying to emphasize the use of "ESI" in 
this document as the key differentiation, clearer to have other two variables 
(vlan and PE address) read the same, or else it makes you wonder if there is a 
difference between vlan and ethernet tag in this context.
JD:  Actually vlan and Ethernet Tag are very different.  Please see the 
terminology section.  This is a significant difference from RFC 7432.


Thanks,

Neeraj

On Tue, Dec 4, 2018 at 4:59 PM The IESG 
mailto:iesg-secret...@ietf.org>> wrote:

The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Framework for EVPN Designated Forwarder
Election Extensibility'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-12-18. Exceptionally, 
comments may be
sent to i...@ietf.org instead. In either case, please 
retain the beginning of
the Subject line to allow automated sorting.

Abstract


   The Designated Forwarder (DF) in EVPN networks is the Provider Edge
   (PE) router responsible for sending broadcast, unknown unicast and
   multicast (BUM) traffic to a multi-homed Customer Equipment (CE)
   device, on a given VLAN on a particular Ethernet Segment (ES). The DF
   is selected out of a list of candidate PEs that advertise the same
   Ethernet Segment Identifier (ESI) to the EVPN network. By default,
   EVPN uses a DF Election algorithm referred to as "Service Carving"
   and it is based on a modulus function (V mod N) that takes the number
   of PEs in the ES (N) and the VLAN value (V) as input. This default DF
   Election algorithm has some inefficiencies that this document
   addresses by defining a new DF Election algorithm and a capability to
   influence the DF Election result for a VLAN, depending on the state
   of the associated Attachment Circuit (AC). In addition, this document
   creates a registry with IANA, for future DF Election Algorithms and
   Capabilities. It also presents a formal definition and clarification
   of the DF Election Finite State Machine.





The file can be obtained via
https://datatracker.ietf..org/doc/draft-ietf-bess-evpn-df-election-framework/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[bess] REMINDER: Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

[Bocci, Matthew (Nokia - GB)]

Folks

I’ve only seen responses from the draft authors so far. Generally, we would 
like to see evidence that a few more people have read the draft and agree it is 
a good starting point.

I am therefore extending this WG adoption poll.

If you have not already reviewed the draft, please can you do so and indicate 
to the list if you support adoption.

This poll will now close on Monday 7th January 2019.

Season’s greetings.

Matthew

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, 3 December 2018 at 14:52
To: "bess@ietf.org" 
Cc: "draft-liu-bess-mvpn-y...@ietf.org" 
Subject: [bess] Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

This email begins a two-week poll for adoption of 
draft-liu-bess-mvpn-yang-07.txt

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently there is one IPR declaration against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Monday 17th December 2018.

Regards,
Matthew


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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-df-election-framework-06

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Francesca,

Thank you very much for your review.
Please see in-line how we are resolving your comments in the next revision (07, 
to be published asap).

Thanks.
Jorge

-Original Message-
From: BESS  on behalf of Francesca Palombini 

Date: Friday, December 14, 2018 at 5:13 PM
To: "gen-...@ietf.org" 
Cc: "draft-ietf-bess-evpn-df-election-framework@ietf.org" 
, "i...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] Genart last call review of 
draft-ietf-bess-evpn-df-election-framework-06

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-evpn-df-election-framework-06
Reviewer: Francesca Palombini
Review Date: 2018-12-14
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: N/A

Minor issues:

I agree with the reviewers comments saying that this document should update
RFC7432 and RFC8124. In particular, quoting RFC2232
(https://tools.ietf.org/html/rfc2223#section-12):

   [...] A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

  To be used as a reference from a new item that cannot be used
  alone (i.e., one that supplements a previous document), to refer
  to the previous document.  The newer publication is a part that
  will supplement or be added on to the existing document; e.g., an
  addendum, or separate, extra information that is to be added to
  the original document.

(Yes, RFC2232 is obsolete, but I could not find the same text in the more
recent RFC7322)

[JORGE] I think this document "can stand on its own" and it is "useful 
independently" of RFC7432, although the latter document is a normative 
reference of course. Please see the resolution to Adrian's comment: 
https://www.ietf.org/mail-archive/web/bess/current/msg03760.html 
Martin, please let us know if you are not okay with our resolution.


Nits/editorial comments:

  "but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se."

* what does their refer to?
[JORGE] changed to the following for clarity:
"These mechanisms do involve changes to the Default DF Election algorithm, but 
they do not require any changes to the EVPN Route exchange and have minimal 
changes in the EVPN routes."

* Section 2.2.2: expand MAC-VRF on first usage for readability (or add a
reference to its definition)
[JORGE] added to the terminology section.

* Figure 3: add a definition for ANY STATE (the figure is clear, but for
consistency I would add that in the text as well)
[JORGE] Added:
"5.  ANY_STATE: Refers to any of the above states."

* Figure 3: add "or" between VLAN_CHANGE, RCVD_ES, LOST_ES (again, not
necessary, suggested for readability of the figure)
[JORGE] done, thx

* Section 3.1: the term "re-entering" needs clarifying: I would consider a 
loop
as re-entering the state, but from bullet 8. it seems like you don't.
[JORGE] good point. Changed 8 to:
"8.  DF_CALC on VLAN_CHANGE, RCVD_ES or LOST_ES: do *as in transition 
7.**"

* suggestion for figure 4 (otherwise it looks like there are 2 fields 
Bitmap of
1B each):

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06 | Sub-Type(0x06)| RSV |  DF Alg |Bitmap ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~   |Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[JORGE] done, thanks.


* Section 3.2: why was Bit 0 left unassigned in Bitmap?
[JORGE] there are implementations of 
https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-02 using that bit.

* IANA considerations: I think you want to specify that the policy for Alg 
31
is Experimental use (right now the text describing the policy only says "RFC
required", with no distinction for different values).
[JORGE] ok, done.

Re: [bess] Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Anoop,

Thank you for your review. We took all your comments.
Please see in-line how we are resolving them in rev 07.

Thanks.
Jorge

-Original Message-
From: BESS  on behalf of "Satya Mohanty (satyamoh)" 

Date: Friday, December 7, 2018 at 6:09 PM
To: Anoop Ghanwani , "bess@ietf.org" 
Subject: Re: [bess] Last Call: 
 (Framework for EVPN 
Designated Forwarder Election Extensibility) to Proposed Standard

Hi Anoop,

Thank you very much for your editorial comments and review.
We will take care of it.

Best,
--Satya


On 12/7/18, 1:01 AM, "BESS on behalf of Anoop Ghanwani" 
 wrote:

I have reviewed the doc and I have mostly editorial comments.

Thanks,
Anoop

==

Throughout

VLAN Bundle, VLAN bundle, VLAN-Bundle, VLAN-bundle -- make consistent
VLAN Aware Bundle, VLAN-aware bundle, VLAN-Aware Bundle -- make 
consistent
bridge table, Bridge Table -- make consistent (also add definition to
terminology section)
DF election, DF Election -- make consistent
Default DF Election, default DF Election -- make consistent
non-DF -> NDF
[JORGE] done, thx

Section 1

double Q-in-Q tags -> Q-in-Q tags

double is redundant
[JORGE] done, thx

Section 2.1

Fig 1 is a bit confusing.  If the idea of the rectangle is to show a
core, then why have connections between PE1 and PE2, PE3, but not
between PE1 and PE4?
[JORGE] good point, fixed it, thx

Change
>>>
Layer-2 devices are particularly susceptible to forwarding loops
because of the broadcast nature of the Ethernet traffic.
>>>
to
The effect of forwarding loops in a Layer-2 network is particularly
severe because of the broadcast nature of Ethernet traffic and the
lack of a TTL.
[JORGE] done, thanks.

Section 2.2.1

a v4 or v6 peering -> an IPv4 or IPv6 peering
[JORGE] done, thanks.

>>>
>From a forwarding perspective, this is
a churn, as it results in re-programming the PE ports as either
blocking or non-blocking at potentially all PEs when the DF changes.
>>>

Why would the reprogramming change at all PEs?  It should change for
at most 2 PEs for each (ES,EVI) being reprogrammed.  Maybe authors
were trying to convey something else?
[JORGE] changed to: 
***From a forwarding perspective, this is
   a churn, as it results in re-programming the PE ports as either
   blocking or non-blocking at the PEs where the DF state changes.***


Section 2.3

>>>
DF Election procedure Generally
>>>
Missing a period.
[JORGE] done, thanks.


Section 3

specification in EVPN -> EVPN specification
[JORGE] done, thanks.


Section 3.1

DF WAIT, DF_WAIT -- make consistent
[JORGE] done, thanks.

DF Wait timer -- where is this defined?
[JORGE] This is defined in [RFC7432]. I added a reference.

Ethernet Segment Route -> Ethernet Segment route
stop DF timer ->  stop DF wait timer (?)
start DF timer -> start DF wait timer (?)
[JORGE] done, thanks.

Section 4

rather than the state of the server states -> rather than the state of
the server (?)
[JORGE] done, thanks.

Section 4.2

Si is the IP address of server i -> Si is the IP address of PE i
[JORGE] done, thanks.

operator chooses so -> operator so chooses
[JORGE] done, thanks.

Note 0 <= i,j <= Number of PEs -- should this be "< Number of PEs"?
Weight(V, Es, Sk) -> Weight(v, Es, Sk)
Pseudo-random -> pseudo-random
efficient deterministic -> efficient and deterministic
V4 -> IPv4
V6 -> IPv6
[JORGE] all of them changed. Thanks.

___
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