[bess] Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08

[Tony Przygienda via Datatracker]

Reviewer: Tony Przygienda
Review result: Has Issues

As first, technically sound except point 18. Rest of the commentes provided are
all for easier readability/clarity for a reader that may not be super
instrinsically familiar with the world of overlay multicast tunnels underlying
VPN technologies first. I am quite versant in it but even then, the complexity
of the field made me stumble on some assertions given without explanation.
Then, good amount of omitted words etc necessary to read as coherent English
sentences. Ultimately, some of the transitions in terms of causality chains do
not connect and can leave the reader stranded which I'm pointing out in
specific comments.

Numbered:

1.  document only distincts between p2mp and mp2mp rather than using the PMSI
terminology with inclusisve/selective [RFC6513]. the S/I is not relevant but it
would help readability if that would be explained. Especially since the S/I
starts to be introduced in 2.2.2.1 suddenly.

2. Terminology
-- provide references for BD/BUM/PMSI/IMET/PTA in terms of RFCs defining them
properly. Currently the section is just acronym expansion really. -- provide
definition of "aggregate tunnel" in the terminology section rather than later
in the document for consistency -- add definitons for "context space",
"upstream assigned label" and "ESI Label" here as well rather than later in the
document. This may lead to more conscise and readable introduction section ---
add definition for DCB -- add def for SRGB with according SRGB

--- I suggest to add upstream assigned (and downstream) labels to definitions
as well since it's so central to the document. Acronym expansion + RFC ref is
fine AFAIS but at least the reader can peddle back and know in one shot where
all the stuff comes from or read things upfront to have an inkling. The
drip-drip technique uesed in the document is ok'ish since it makes an illusion
of gradual introduction into the solution space on first read but makes it hard
to find things later, have in one easy shot a quick recall "what was that all
about". IME good glossary goes a very long way when attempting a 2nd read or
trying to do a fast page-in later.

-- given 2.2.2.1 I suggest to add PMSI + S/I + PTA defintions + IMET + RBR. And
maybe minimum definition (or where to find the terminology precisely) for the
whole (C-*,C-*) machinery involved in context lookups you pull out in 2.2.2.3

3. "but each PE would
   know not to allocate labels from that block for other purposes" is difficult
   to read. Rewrite from negative.

4. "1000 is for VPN 0, 1001 for VPN 1 ...". Write it clearer, maybe "label 1000
maps to VPN 0, 1001 to VPN1 and so forth"

5. "
network.  (Though if tunnel
   segmentation [RFC6514] is used, each segmentation region could have
   its own DCB.  This will be explained in more detail later.)". This separate
   sentence in () is funny, make is a composite sentence or part of previous
   sentence in ()

6. "
However, that is not necessarily as the labels used by PEs
   for the purposes defined in this document will only rise to the top
   of the label stack when traffic arrives the PEs.
"
does not parse as English. this is not necessarily _true_ ? arrives _from_ the
PEs (which it always does or you want to emphasize that traffic can "arrive
from P" ?) ?

7. "
That way
   they do not have to aside the same DCB used for the purposes in this
   document.
"
Again, not English. "they do not have to _set_ aside" ?

8. "if it is difficult". If it is _too_ difficult?
9. Here you will loose many readers

"We also augment the signaling so that it is
   possible to indicate that a particular label is from an identified
   context label space that is different than the ingress PE's own
   context label space.
"
If you need to differentiate between a "ingress PE context label space" and
another type of context label space you need to introduce this terminology,
maybe

"GCLS" for global context label space and "PCLS" or some such thing. Otherwise
the reading of the "context label space" depends too much on the context (pun
intented ;-)

And then segmentation points seem to have yet another "context label space"
which may need

10. "
Notice that, the VPN/BD/ES-identifying labels from the DCB or from
   those few context label spaces are very similar to VNIs in VXLAN.
   Allocating a label from the DCB or from those a few context label
   spaces and communicating them to all PEs should not be different from
   allocating VNIs, and should be feasible in today's networks since
   controllers are used more and more widely.
"
I would loose the whole thing. It's an analogy across yet another technology
and imperfect one on top of that given we have SRC/DST in VXLAN on top and
"bias" and all kind of ugly hacks (eeeh,

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Tony Przygienda]

Ketan, yepp, 5.1.2 is roughly the CUG via ACL, add to it per service
protection (as in some external A can talk to service X but external B
cannot which now starts to push you into fragment the SRv6 "prefix" into
"per service space" if you want to aggregate), multiply that by the
downstream-upstream if you want to cross providers AFAIS (as in BGP
flowspec up/down shorewalling) and you have a pretty nice combinatorial
space. And BTW, source address is easily spoofed given the lack of BCP
implementations in the real world and with source routing technology one
can land those packets in unexpected places via unexpected routes. All that
looks to me like nothing comparable to a leaked internal loopback today
which was my whole point as in fallacy by  faulty analogy.

Unless I lost the thread completely which, given the amount of machinery
fielded by now ;-) could be excusable ...

-- tony


On Thu, Feb 17, 2022 at 11:37 AM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> My apologies, but I am not able to understand your emails entirely. I
> wonder if this text below helps explain:
> https://datatracker.ietf.org/doc/html/rfc8754#section-5.1
>
> Thanks,
> Ketan
>
>
> On Thu, Feb 17, 2022 at 3:40 PM Tony Przygienda 
> wrote:
>
>>
>>
>>
>>>
>>>> But I'm prepared to learn why this wouldn't work or would be somehow
>>>> worse.
>>>>
>>>
>>> KT> It isn't necessary nor required because SRv6 locators are just IPv6
>>> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
>>> provider that uses global IPv6 addresses in their infrastructure (e.g. for
>>> their BGP and other routing sessions, on their router links and loopback,
>>> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
>>> These are not advertised (nor leaked) out into the Internet since doing so
>>> can result in attacks on their internal network and infrastructure. They
>>> are protected via BGP configuration to stop leaks and then again by ACLs at
>>> Internet Border Routers to prevent attacks via the data path. This still
>>> remains the case to be done for SRv6 locators - they are similarly the
>>> service provider's "internal" infrastructure.
>>>
>>>
>> I'm confounded by the recent line of reasoning  of SRv6 proponents.  An
>> IPv6 address is NOT a service access point, it's a routable address,
>> history shows us that we can protect against services on the device being
>> attacked through that (though it took some work like proper ICMP handling).
>> SRv6 endpoints here are really service endpoints, unless we have a CUG
>> security architecture in place, how do we protect services here without
>> having CUG style filters on the whole edge?  with SRv6 services giving
>> people a service access point and a tunneling technology where someone via
>> v6 routing can built a tunnel to hit the service is a different beast
>> altogether than protecting reachability (routable addresses) and I fear
>> pretty soon we're looking @ routers going very, very deep into the "IPv6"
>> packet to make sure there aren't some magic options on the packet
>> source-routing it in funky ways towards service endpoints that will accept
>> the packet.
>>
>> --- tony
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Tony Przygienda]

>
>> But I'm prepared to learn why this wouldn't work or would be somehow
>> worse.
>>
>
> KT> It isn't necessary nor required because SRv6 locators are just IPv6
> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
> provider that uses global IPv6 addresses in their infrastructure (e.g. for
> their BGP and other routing sessions, on their router links and loopback,
> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
> These are not advertised (nor leaked) out into the Internet since doing so
> can result in attacks on their internal network and infrastructure. They
> are protected via BGP configuration to stop leaks and then again by ACLs at
> Internet Border Routers to prevent attacks via the data path. This still
> remains the case to be done for SRv6 locators - they are similarly the
> service provider's "internal" infrastructure.
>
>
I'm confounded by the recent line of reasoning  of SRv6 proponents.  An
IPv6 address is NOT a service access point, it's a routable address,
history shows us that we can protect against services on the device being
attacked through that (though it took some work like proper ICMP handling).
SRv6 endpoints here are really service endpoints, unless we have a CUG
security architecture in place, how do we protect services here without
having CUG style filters on the whole edge?  with SRv6 services giving
people a service access point and a tunneling technology where someone via
v6 routing can built a tunnel to hit the service is a different beast
altogether than protecting reachability (routable addresses) and I fear
pretty soon we're looking @ routers going very, very deep into the "IPv6"
packet to make sure there aren't some magic options on the packet
source-routing it in funky ways towards service endpoints that will accept
the packet.

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

Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[Tony Przygienda]

support adoption

On Tue, Apr 13, 2021 at 3:38 PM Ron Bonica  wrote:

>
>
> I support adoption.
>
>
>
>  Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* BESS  *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* Tuesday, April 13, 2021 5:37 AM
> *To:* draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org;
> bess@ietf.org
> *Subject:* [bess] WG Adoption and IPR Poll for
> draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1].
>
>
>
> 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 will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures 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 April 27th 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/
> 
>
>
>
>
> ___
> 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] Please send request to take slot in IETF 110

[Tony Przygienda]

any chance I get 10 (better 15) mins to present

https://tools.ietf.org/html/draft-head-rift-auto-evpn-00

?

thanks

-- tony

On Tue, Feb 16, 2021 at 4:58 PM Mankamana Mishra (mankamis)  wrote:

> All,
>
> Agenda for IETF 110 is out. Please send request to take slot to present.
> We are meeting on March 10th
>
>
>
> *13:00-15:00*
>
> *Wednesday Session I*
>
>
>
>
>
>
>
> Mankamana
> ___
> 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] slot request auto evpn

[Tony Przygienda]

any chance I get 10 (better 15) mins to present

https://tools.ietf.org/html/draft-head-rift-auto-evpn-00

?

thanks

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

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[Tony Przygienda]

we're weighing in 161 pages in the last IESG reviews now which is however
not very meaningful ;-) since it's probably 25 pages just IANA request and
it's not just the spec, it's the whole outline of design/narrative/walk
through (folks preferred it that way). With FSMs/algorithms and water-tight
interoperable protocol like it can't be done in 10 easy pages breeze
through (well, one can do that but then customers spend 5 years figuring
out how to interop anything and finding cornercases, not the way RIFT WG is
run ;-)

I'll ping you 1:1 otherwise ;-)

thanks

--- tony

On Mon, Mar 9, 2020 at 9:15 PM Gyan Mishra  wrote:

> Hi Tony
>
> I am actually a member of RIFT, as the WG charter description
> was intriguing so I joined - to learn more about the RIFT technology.
>
> I downloaded the draft but never made it through as its a lengthy 100+
> page draft.  Now I really have to read it.
>
> Yes that would be great.  Please unicast me on hayabusa...@gmail.com.
>
> Kind regards
>
> Gyan
>
> On Mon, Mar 9, 2020 at 11:31 AM Tony Przygienda 
> wrote:
>
>> Gyan, the technology that you look for exists and is about to go
>> standards RFC (i.e. _scalable_ L3 multihoming to the host including
>> bandwidth load-balancing and many other things that need consideration in
>> such case, e.g. host asic table scalability). Please look @
>> https://datatracker.ietf.org/doc/draft-ietf-rift-rift/  If you need more
>> info/code, more than happy to talk out of band
>>
>> thanks
>>
>> -- tony
>>
>> On Thu, Mar 5, 2020 at 2:04 PM Gyan Mishra  wrote:
>>
>>> Hi Sandy
>>>
>>> Thank you for the feedback on your use cases.
>>>
>>> For now will remain L2 MLAG to the host.
>>>
>>> BESS WG,
>>>
>>> If anyone hears of any new developments on vxlan fabric extension to
>>> hypervisor and any vendors supporting even 3rd party open source
>>> implementations of fabric extensions please reach out to me.
>>>
>>> As an aside when reading RFC 8365 NVO3 section 7  it kind of gets
>>> excited by the subject heading “single homed NVE residing in Hypervisor” or
>>> section 8 MH NVE in TOR server - thinking that maybe fabric extension to
>>> hypervisor does actually exist but of course the let down that no vendor
>>> supports it.
>>>
>>> It does seem there would be a lot of customers wanting this fabric
>>> extension to hypervisor capabilities for MH load balancing- and very
>>> surprising that it does not exist.
>>>
>>> https://tools.ietf.org/html/rfc8365#section-7
>>>
>>>
>>>
>>> Kind regards
>>>
>>> Gyan Mishra
>>> Verizon
>>> Cell 301 502-1347
>>>
>>> On Wed, Mar 4, 2020 at 4:57 PM Sandy Breeze >> > wrote:
>>>
>>>> Hi Gyan,
>>>>
>>>>
>>>>
>>>> Here, we use a mix of NXOS & Arista EOS for leaf and spine, ASR9k DCI
>>>> doing L2 + L3 VTEP and stitching to MPLS EVPN / traditional VPNv4/6.  We
>>>> also confess to pockets of proprietary NXOS vPC, and, pockets of Arista
>>>> ESI-MH.  Incidentally, the older Broadcom NXOS boxes do have ESI-MH
>>>> capabilities and that worked alright.  Customers, like us, have been long
>>>> promised the vendor silicon will catch up, though we’ve yet to see it
>>>> happen.
>>>>
>>>>
>>>>
>>>> We’re entirely a home grown automation / orchestration stack, with many
>>>> years behind it.  Have a look at some talks we’ve given publicly for the
>>>> background in our ‘GOLF’ project.
>>>> https://www.youtube.com/watch?v=jXOrdHfBqb0=
>>>>
>>>>
>>>>
>>>> > Has this ever been done before and with which hypervisors ?
>>>>
>>>> We had the same requirements as you 2-3 years ago.  Have we solved it?
>>>> TL;DR: not really!  We did make an interesting proof of concept though…
>>>>
>>>> Being largely a VMWare NSX house, we found VMWare closed to offering
>>>> any type of EVPN orchestrated VTEP extension into the physical fabric.
>>>> Quite simply, its model of extending to physical VTEP is OVSDB.  That’s not
>>>> exactly compatible with an EVPN ToR, for various reasons.  So, we had the
>>>> idea that we’d build something which spoke both OVSDB (to NSX) and EVPN (to
>>>> the physical ToR).  The high level idea being, we’d use this to create
>>>> routes in EVPN if they were seen from OVSDB, and visa-versa

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[Tony Przygienda]

Gyan, the technology that you look for exists and is about to go standards
RFC (i.e. _scalable_ L3 multihoming to the host including bandwidth
load-balancing and many other things that need consideration in such case,
e.g. host asic table scalability). Please look @
https://datatracker.ietf.org/doc/draft-ietf-rift-rift/  If you need more
info/code, more than happy to talk out of band

thanks

-- tony

On Thu, Mar 5, 2020 at 2:04 PM Gyan Mishra  wrote:

> Hi Sandy
>
> Thank you for the feedback on your use cases.
>
> For now will remain L2 MLAG to the host.
>
> BESS WG,
>
> If anyone hears of any new developments on vxlan fabric extension to
> hypervisor and any vendors supporting even 3rd party open source
> implementations of fabric extensions please reach out to me.
>
> As an aside when reading RFC 8365 NVO3 section 7  it kind of gets excited
> by the subject heading “single homed NVE residing in Hypervisor” or section
> 8 MH NVE in TOR server - thinking that maybe fabric extension to hypervisor
> does actually exist but of course the let down that no vendor supports it..
>
> It does seem there would be a lot of customers wanting this fabric
> extension to hypervisor capabilities for MH load balancing- and very
> surprising that it does not exist.
>
> https://tools.ietf.org/html/rfc8365#section-7
>
>
>
> Kind regards
>
> Gyan Mishra
> Verizon
> Cell 301 502-1347
>
> On Wed, Mar 4, 2020 at 4:57 PM Sandy Breeze  > wrote:
>
>> Hi Gyan,
>>
>>
>>
>> Here, we use a mix of NXOS & Arista EOS for leaf and spine, ASR9k DCI
>> doing L2 + L3 VTEP and stitching to MPLS EVPN / traditional VPNv4/6.  We
>> also confess to pockets of proprietary NXOS vPC, and, pockets of Arista
>> ESI-MH.  Incidentally, the older Broadcom NXOS boxes do have ESI-MH
>> capabilities and that worked alright.  Customers, like us, have been long
>> promised the vendor silicon will catch up, though we’ve yet to see it
>> happen.
>>
>>
>>
>> We’re entirely a home grown automation / orchestration stack, with many
>> years behind it.  Have a look at some talks we’ve given publicly for the
>> background in our ‘GOLF’ project.
>> https://www.youtube.com/watch?v=jXOrdHfBqb0=
>>
>>
>>
>> > Has this ever been done before and with which hypervisors ?
>>
>> We had the same requirements as you 2-3 years ago.  Have we solved it?
>> TL;DR: not really!  We did make an interesting proof of concept though…
>>
>> Being largely a VMWare NSX house, we found VMWare closed to offering any
>> type of EVPN orchestrated VTEP extension into the physical fabric.  Quite
>> simply, its model of extending to physical VTEP is OVSDB.  That’s not
>> exactly compatible with an EVPN ToR, for various reasons.  So, we had the
>> idea that we’d build something which spoke both OVSDB (to NSX) and EVPN (to
>> the physical ToR).  The high level idea being, we’d use this to create
>> routes in EVPN if they were seen from OVSDB, and visa-versa, only we’d
>> maintain the original next-hop.  Kinda like an iBGP RR, only between 2
>> different control-planes.  Internally, we called it VxGlue.
>>
>>
>>
>> At a high level, it worked well in achieving nice loadbalancing of
>> traffic into the hypervisor.  It would no doubt scale fairly well too.  Is
>> it the right thing to do in a production network?  We decided not.  For
>> one, its very hard to keep up with pace of development of underlying VMWare
>> API’s.  As I say, this was a few years ago and things have moved on.  Maybe
>> we’ll revisit.
>>
>>
>>
>> Sandy
>>
>>
>>
>>
>>
>> On 04/03/2020, 21:03, "BESS on behalf of Gyan Mishra" <
>> bess-boun...@ietf.org on behalf of hayabusa...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> Thank you all for the feedback!!
>>
>>
>>
>> Our requirements we ar looking for a way to increase stability without
>> sacrificing bandwidth availability and convergence with Data Center host
>> connectivity to an existing vxlan fabric.  Our server traffic volume is
>> higher bandwidth East to West then North to South.
>>
>>
>>
>> We have a Cisco Nexus based vxlan evpn fabric with multi site feature
>> connecting all of our PODs intra DC and use BGP EVPN over an MPLS core for
>> DCI inter connect inter Data Center connectivity.
>>
>>
>>
>> We have orchestration via Cisco NSO and DCNM for network
>> programmability.  Typical Cisco shop..
>>
>>
>>
>> Our Data Center host attachment model as been with MLAG using Cisco’s
>> vPC.  That has been problematic having that L2 extension so we would like
>> to find a better way to maybe leverage our existing vxlan fabric and extend
>> to server hypervisor if at all possible.
>>
>>
>>
>> So with a hypervisor connected to two leaf switches in a vxlan fabric  it
>> sounds like it maybe possible with Cisco’s IETF standards based
>> implementation of vxlan overlay following NVO3 RFC 8365 and BGP EVPN RFC
>> 7432 that we could extend the fabric to server hypervisor.
>>
>>
>>
>> The question related to L3 ECMP versus L2 MLAG become moot as with
>> existing BGP EVPN load balancing procedures 

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[Tony Przygienda]

not aware of any undisclosed IPR (in E/// where I was working on what are
now pieces of the draft) ...

thanks

--- tony

On Mon, Mar 26, 2018 at 7:21 AM,  wrote:

> Hello working group,
>
>
>
> This email starts a two-week Working Group Last Call on
> draft-ietf-bess-evpn-df-election-framework-00 [1]
>
>
>
> This poll runs until *the 9th of April*.
>
>
>
> 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.
>
>
>
> Currently no IPR has been disclosed 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.
>
>
>
> We are also polling for any existing implementation.
>
>
>
> Thank you
>
>
>
> Matthew, Stéphane
>
> bess chairs
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-
> election-framework/
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> ___
> 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] New bess Co-Chair

[Tony Przygienda]

Ack, welcome, great to have more and more operators getting involved in the
sausage definition. This leads often to early discussions and better
appreciation of the challenges of ultimately pouring the resulting tapestry
of RFCs into bits and silicon ;-)

--- tony

On Fri, Dec 1, 2017 at 8:16 AM, Alvaro Retana 
wrote:

> Dear bess WG:
>
> I am sad to report that Thomas Morin has decided not to continue as bess
> Co-Chair due to the demands of his job.  Thomas: thank you for all the
> effort you have put into the WG, we all look forward to your continued
> contributions to the IETF!
>
> In consultation with Martin and the other ADs, we have asked Stephane
> Litkowski to take on the role of bess Co-Chair.  As most of you know,
> Stephane works at Orange Business Services, has been involved in the IETF
> for several years and had made significant contributions in a number of WGs
> in and out of the Routing Area.  Welcome Stephane!
>
> Stephane can be reached at stephane.litkow...@orange.com.
>
> This change is effective immediately.
>
> Thanks!
>
> Alvaro.
>
> ___
> 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] Call for adoption: draft-rabadan-bess-evpn-pref-df

[Tony Przygienda]

support as co-author. Not aware of IPR  ...

On Tue, Jun 6, 2017 at 6:44 AM,  wrote:

> Hello working group,
>
> This email starts a two-week call for adoption on
> draft-rabadan-bess-evpn-pref-df-02 [1] as a Working Group Document.
>
> Please state on the list if you support the adoption or not (in both
> cases, please also state the reasons).
>
> This poll runs until *the 20th of June*.
>
> 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 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.
>
> If you are not listed as an Author or Contributor, then please explicitly
> respond only if you are aware of any IPR that has not yet been disclosed in
> conformance with IETF rules.
>
> Thank you,
>
> Martin & Thomas
> bess chairs
>
> [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-pref-df/
>
> 
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>



-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane

[Tony Przygienda]

+1 adoption

On Mon, Mar 6, 2017 at 3:55 AM, Martin Vigoureux  wrote:

> Hello working group,
>
> This email starts a two-week call for adoption on
> draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group
> Document.
>
> Please state on the list if you support the adoption or not (in both
> cases, please also state the reasons).
>
> This poll runs until *the 19th of March*.
>
> 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 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.
>
> IPR has been disclosed against this Document [2].
>
> If you are not listed as an Author or Contributor, then please explicitly
> respond only if you are aware of any IPR that has not yet been disclosed in
> conformance with IETF rules.
>
> Thank you
>
> Martin & Thomas
> bess chairs
>
> [1] https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-c
> ontrol-plane/
> [2] https://datatracker.ietf.org/ipr/search/?submit=draft=dra
> ft-mackie-bess-nsh-bgp-control-plane
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>



-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

[Tony Przygienda]

> 1. When a new PE comes in the MH segment.
> [Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the
> receiving PEs also need to wait for 3 secs. But, ideally, a PE that is
> going from DF to non-DF or non-DF to non-DF should become the non-DF right
> away. Only the PE that is going DF really needs to wait for 3 secs. This is
> not explicitly spelled out in the draft but we are thinking along these
> lines.


Actually, the only reason to give up DF is if a new ES route is received
and then 3 secs is necessary for e'one. If a ES is lost, no wait time is
necessary on re-election (i.e. DFs can assume DF immediately or give up DF
immediately). Small window of ES route loss being realized by all peers is
of course here (but we assume that is happening very fast in today's
deployments). FSM in the draft shows that. Are any improvements needed
there ? All those questions should be answered by reference FSM in the
draft already so it's worth improving it (I see this question 3rd time or
so already ?)

thanks

-- tony


-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess