Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[Muthu Arul Mozhi Perumal]

My understanding:

For the single-active case in the diagram below, when PE4 receives the A-D
per ES route withdraw it won't know whether PE2 or PE3 will become the new
primary/DF for the , so it will start flooding the traffic
destined to MAC1. Then either PE2 or PE3 will become the new primary/DF for
the  and advertise the MAC/IP route for MAC1. PE4 will then start
sending the traffic destined to MAC1 to the new primary.

For the all-active case, when PE4 receives the A-D per ES route withdraw it
will update the nexthop list for MAC1 by removing PE1 from that list. PE4
will then load balance the traffic destined to MAC1 by send it to PE2 and
PE3 using alias label.

Regards,
Muthu

On Wed, Mar 6, 2019 at 7:51 PM Luc Andre Burdet (lburdet) 
wrote:

> Hi Chalu,
>
>
>
> Please read 7432 s.8.4: in single-active it is not an aliasing
> label/procedure but a backup-path procedure.
>
> It will answer your questions (both, actually).
>
>
>
> There is no flooding once the MAC is learnt & distributed: cf. that’s the
> point.
>
>
>
>
>
> [image:
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]
>
> *Luc André Burdet*
>
> lbur...@cisco.com
>
> Tel: *+1 613 254 4814*
>
> Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
>
> Cisco.com 
>
>
>
>
>
> *From: *BESS  on behalf of chalapathi andhe <
> chalu.i...@gmail.com>
> *Date: *Wednesday, March 6, 2019 at 04:15
> *To: *"bess@ietf.org" 
> *Cc: *Sean Wu , Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>, "chalapathi.an...@ericsson.com" <
> chalapathi.an...@ericsson.com>
> *Subject: *Re: [bess] FW: Regarding the Alias label usage in EVPN
> Multihoming
>
>
>
>
>
>
>
> Hi All,
>
>
>
> Can you please help us on the following issue.
>
> In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1]
> in Single active mode, and PE4 is a remote PE.
>
> Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1
> with the PE1 as primary path with MAC Label,
>
> and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link
> goes down, then PE1 withdraw the EAD/ES route
>
> which will be processed by PE4.
>
> Now what should the forwarding state at PE4 ?, PE4 should update the
> forwarding state of MAC1 with the PE2, PE3 Alias label
>
> and any traffic destined to MAC1 should be flooded to PE2, PE3 with the
> Alias labels ?
>
> Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should
> it be some other method ?
>
>
>
> In similar if the ES is operating in all active mode, what should be the
> forwarding state at PE4 ?
>
> PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias
> label
>
> and any traffic destined to MAC1 should be sent to either PE2 or PE3 with
> the Alias labels [ not flood to both] ?
>
> Or packet should be flooded to PE2, PE3 with the Flood labels  or Alias
> Label ?
>
> Or should it be some other method ?
>
>
>
>
>
> [image: cid:1695247dcc04ce8e91]
>
>
>
>
>
> Thanks,
>
> Chalapathi.
>
> ___
> 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] Slot requests for BESS WG session - IETF 104 - Prague

[zhang.zheng]

Hi Mankamana, Chairs,






I'd like to request 10 minutes for "draft-zwm-bess-es-failover-00";


presenter: Sandy Zhang


Thank you very much!






Best regards,


Sandy







原始邮件



发件人：MankamanaMishra(mankamis) 
收件人：bess@ietf.org ;
日 期 ：2019年02月26日 00:54
主 题 ：[bess] Slot requests for BESS WG session - IETF 104 - Prague


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

  

All,


 


It is time we start building the BESS WG agenda for IETF 104 Prague.


 


Please send us your request for a presentation slot , indicating draft name, 
speaker, and desired duration (covering presentation and discussion). If it is 
not the first presentation of the draft,  please give a reason why it is 
required to have a new presentation slot.


 


Preliminary agenda can be found at :


https://datatracker.ietf.org/meeting/104/agenda.html


 


 


Thank you


 


Mankamana , Stephane & Matthew___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-bgp-vpls-control-flags-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Updated processing of Control Flags for BGP VPLS
Authors : Ravi Singh
  Kireeti Kompella
  Senad Palislamovic
Filename: draft-ietf-bess-bgp-vpls-control-flags-07.txt
Pages   : 8
Date: 2019-03-06

Abstract:
   This document updates the meaning of the Control Flags field in the
   Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in
   RFC4761. This document updates RFC4761.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-bgp-vpls-control-flags-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-vpls-control-flags-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-bgp-vpls-control-flags-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-09.txt
Pages   : 57
Date: 2019-03-06

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-09
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Andrew G. Malis]

Adrian,

(resending to everyone, not just Adrian)

>>> References:
>>>
>>> I think that the mpls-sfc and mpls-sfc-encaps should also be
>>> normative as you are defining a controlplane to use them.
>>
>>I don't mind doing that.
>
> [SLI] These two are more debatable. Let's keep them as info, and
> we will see if IESG raises any concern.

Well, actually, since those two docs are on the Standards Track and are
well ahead in the pipe, let's make them Normative.


Actually, mpls-sfc-encaps is Informational, not standards track, so you may
wish to keep the reference informative else it'll be a downref. That's OK,
as long as that's included in the IESG writeup.

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

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Adrian Farrel]

Thanks again Stephane,

I think we have closure on most (but not all) of your points. I'll post another 
revision now because it makes the incremental changes easier to process. But we 
can have another go round if any of the unresolved issues merit it.

One thing to push back on from before was the use of "portal" or "gateway". We 
were using "portal" and you asked us to change to "gateway". I initially 
thought that would be OK, but on reflection we think that "gateway" has 
specific connotations in networking where it means an interworking function 
between two different protocols and this is most definitely not what is 
intended. So, because "portal" is a synonym, we prefer to go back to using that.

   Thus the SFF can be seen as a portal in the underlay network through
   which a particular SFI is reached.

Cheers,
Adrian

> New comment:
>
> " When the SFF receives the packet and the NSH back from the SFI it
>   MUST select the next SFI"
>
> [SLI] Even if I agree that this is the intended behavior, it is not the
> purpose of this document to set the dataplane behavior of NSH. I
> think keeping the "MUST" as lower case is fine.

Ah yes.
I got carried away.

>>> The Figure 1 is not really used in this section as part of the existing
>>> text. I would be better to have a companion text that explains the
>>> figure.
>>
>> Wow! Yes. That's embarrassing.
>
> [SLI] The provided text is good. Just few comments:
>
> - the figure wraps on two pages, I missed the SFa in the figure as it is
>   located on the other page. It would be great if you could make it fit
>   on one page.

Hmmm, yes.
I will make the figure small enough to fit on one page, but I won't handle 
pagination at this stage: the RFC Editor will resolve that in the final 
formatting.

> - don't you need tunnels between SFF2 and SFF3 and between SFF1 
>   and SFF4 (full mesh). I agree that tunnel may be established on demand
>   if an SFC is using two SFFs, but here we don't have this information.

You *could* certainly have a those tunnels. But in practice there is unlikely 
to be a full mesh. This is a bit like a content distribution problem: a 
multi-layer network engineering solution is needed to place the SFs and decide 
which SFFs need to be connected with tunnels. Furthermore, if an SFC will never 
need to take SFs in a particular order, then tunnels wouldn't be needed.

> As the figure is already complex, adding tunnels may overload it. Maybe
> we could add a text telling that to simplify the figure only some tunnels
> between SFFs are represented.

Right, no need to complicate the figure.
I'll add...
  Note that, for convenience and clarity,  
shows only a few tunnels between
 SFFs.  There could be a full mesh of such tunnels, or more likely, a 
selection of tunnels connecting
 key SFFs to enable the construction of SFPs and to balance load and 
traffic in the network.

> - the example of SFC looks strange to me as SFd may be used twice
>   in the chain why not using " SFa, an SF of type SFTx, and SFe" ?

Bad text, well caught.
Text should read...

  Suppose an SFC needs to include SFa,
  an SF of type SFTx, and SFc.

> - There is a sentence telling that the figure illustrates loadbalancing,
>   however I think that the sentence " A number of SFPs can be
>   constructed using any instance of SFb or using SFd." is not enough
>   to describe the loadbalancing. Who is doing the loadbalancing ?

OK. Now reads...

  This figure demonstrates how load balancing can be achieved by 
creating several SFPs that satisfy
 the same SFC.  Suppose an SFC needs to include SFa, an SF of type 
SFTx, and SFc.  A number of SFPs
 can be constructed using any instance of SFb or using SFd.  Load 
balancing may be applied at two
 places:
 
   The Classifier may distribute different flows onto different SFPs 
to share the load in the
  network and across SFIs.
   SFF-2 may distribute different flows (on the same SFP) to 
different instances of SFb to share
  the processing load.
 

>>> “The Service Function Type identifies a service function”. I don’t
>>> think we can really say that, it identifies the type of service the SF
>>> is providing but not the SF itself.
>>
>> Yes
>
> [SLI] The new text sounds strange.  Even if it is correct, it sounds as a 
> repetition:
> " The Service Function Type identifies a service function type".
> Could we use something like : "The Service Function Type identifies the
> functions/features of service function can offer".

OK

>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI] I'm talking about the nexthop field of the MP_REACH_NLRI attribute, 
> you must set a nexthop field even if it is not used for forwarding and you
> need to set how it is encoded.

Ah, that!
Yes, it's just a loopback address of the advertising SFF.
Added a paragraph for that.

>>> I don’t see the “error 

Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[Luc Andre Burdet (lburdet)]

Hi Chalu,

Please read 7432 s.8.4: in single-active it is not an aliasing label/procedure 
but a backup-path procedure.
It will answer your questions (both, actually).

There is no flooding once the MAC is learnt & distributed: cf. that’s the point.


[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com







From: BESS  on behalf of chalapathi andhe 

Date: Wednesday, March 6, 2019 at 04:15
To: "bess@ietf.org" 
Cc: Sean Wu , Jaikumar Somasundaram 
, "chalapathi.an...@ericsson.com" 

Subject: Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming



Hi All,

Can you please help us on the following issue.
In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1] in 
Single active mode, and PE4 is a remote PE.
Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1 with the 
PE1 as primary path with MAC Label,
and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link goes 
down, then PE1 withdraw the EAD/ES route
which will be processed by PE4.
Now what should the forwarding state at PE4 ?, PE4 should update the forwarding 
state of MAC1 with the PE2, PE3 Alias label
and any traffic destined to MAC1 should be flooded to PE2, PE3 with the Alias 
labels ?
Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should it be 
some other method ?

In similar if the ES is operating in all active mode, what should be the 
forwarding state at PE4 ?
PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias label
and any traffic destined to MAC1 should be sent to either PE2 or PE3 with the 
Alias labels [ not flood to both] ?
Or packet should be flooded to PE2, PE3 with the Flood labels  or Alias Label ?
Or should it be some other method ?


[cid:1695247dcc04ce8e91]


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

[bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : EVPN Interworking with IPVPN
Authors : Jorge Rabadan
  Ali Sajassi
  Eric C. Rosen
  John Drake
  Wen Lin
  Jim Uttaro
  Adam Simpson
Filename: draft-ietf-bess-evpn-ipvpn-interworking-00.txt
Pages   : 23
Date: 2019-03-06

Abstract:
   EVPN is used as a unified control plane for tenant network intra and
   inter-subnet forwarding. When a tenant network spans not only EVPN
   domains but also domains where IPVPN provides inter-subnet
   forwarding, there is a need to specify the interworking aspects
   between both EVPN and IPVPN domains, so that the end to end tenant
   connectivity can be accomplished. This document specifies how EVPN
   should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families
   for inter-subnet forwarding.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-00
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[chalapathi andhe]

>
> Hi All,
>
>
>
> Can you please help us on the following issue.
>
> In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1]
> in Single active mode, and PE4 is a remote PE.
>
> Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1
> with the PE1 as primary path with MAC Label,
>
> and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link
> goes down, then PE1 withdraw the EAD/ES route
>
> which will be processed by PE4.
>
> Now what should the forwarding state at PE4 ?, PE4 should update the
> forwarding state of MAC1 with the PE2, PE3 Alias label
>
> and any traffic destined to MAC1 should be flooded to PE2, PE3 with the
> Alias labels ?
>
> Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should
> it be some other method ?
>
>
>
> In similar if the ES is operating in all active mode, what should be the
> forwarding state at PE4 ?
>
> PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias
> label
>
> and any traffic destined to MAC1 should be sent to either PE2 or PE3 with
> the Alias labels [ not flood to both] ?
>
> Or packet should be flooded to PE2, PE3 with the Flood labels  or Alias
> Label ?
>
> Or should it be some other method ?
>
>
>
>
>
>
>
>
>
> Thanks,
>
> Chalapathi.
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess