Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

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

Hi,

I think you should check out 
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09

This draft updates RFC7432 in certain aspects of the DF Election, and it is 
already at the RFC editor.

Check out the use of Ethernet Tag in the document.

   o Ethernet Tag - used to represent a Broadcast Domain that is
 configured on a given ES for the purpose of DF election. Note that
 any of the following may be used to represent a Broadcast Domain:
 VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
 Identifiers), normalized VID, I-SIDs (Service Instance
 Identifiers), etc., as long as the representation of the broadcast
 domains is configured consistently across the multi-homed PEs
 attached to that ES. The Ethernet Tag value MUST be different from
 zero.

Thanks.
Jorge

From: BESS  on behalf of Jaikumar Somasundaram 

Date: Friday, April 5, 2019 at 6:15 AM
To: "bess@ietf.org" 
Cc: P Muthu Arul Mozhi 
Subject: [bess] DF election rule in EVPN MH, for untagged interface - reg

Hi All,

RFC7432, section 8.5, talks about DF election algorithm (service carving 
algorithm)

only for  for VLAN-based service or  for VLAN-(aware)
bundle service.

But there wont be any vlan id for untagged interface and so I wonder
how the service carving algorithm can be applied to elect the DF.
Also, should I use the lower VLAN ID even in the case of VLAN-bundle
service, for electing the DF?

Could some one help me to understand this please?

=
8.5.  Designated Forwarder 
Election

…

   The default procedure for DF election at the granularity of  for VLAN-based service or  for VLAN-(aware)

   bundle service is referred to as "service carving".
…

  Assuming a redundancy group of N PE nodes, for VLAN-based service,

  the PE with ordinal i is the DF for an  when (V mod N)

  = i.  In the case of VLAN-(aware) bundle service, then the

  numerically lowest VLAN value in that bundle on that ES MUST be

  used in the modulo function.
…
===

Thanks & Regards
Jaikumar S

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

[bess] DF election rule in EVPN MH, for untagged interface - reg

[Jaikumar Somasundaram]

Hi All,

RFC7432, section 8.5, talks about DF election algorithm (service carving 
algorithm)

only for  for VLAN-based service or  for VLAN-(aware)
bundle service.

But there wont be any vlan id for untagged interface and so I wonder
how the service carving algorithm can be applied to elect the DF.
Also, should I use the lower VLAN ID even in the case of VLAN-bundle
service, for electing the DF?

Could some one help me to understand this please?

=
8.5.  Designated Forwarder 
Election



   The default procedure for DF election at the granularity of  for VLAN-based service or  for VLAN-(aware)

   bundle service is referred to as "service carving".


  Assuming a redundancy group of N PE nodes, for VLAN-based service,

  the PE with ordinal i is the DF for an  when (V mod N)

  = i.  In the case of VLAN-(aware) bundle service, then the

  numerically lowest VLAN value in that bundle on that ES MUST be

  used in the modulo function.

===

Thanks & Regards
Jaikumar S

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

[bess] Mirja Kühlewind's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Mirja Kühlewind via Datatracker]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-bess-bgp-vpls-control-flags-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/



--
COMMENT:
--

Given this document updates the normative behaviour of RFC 4761, I would have
expected to see some discussion about interoperability. Is the behaviour as
specified in RFC 4761 not widely deployed/implemented or would it be possible
to add some sentences about interoperability which already deployed devices?

One minor editorial request:
- Please expand PE on first occurrence.


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

[bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[stephane.litkowski]

Hi WG,

draft-ietf-bess-nsh-bgp-controlplane has passed WGLC and its finishing the 
shepherd's review phasis (I-D update required). It is in a good shape to 
progress further. However we are not aware of any implementation. As per our 
Implementation Requirement Policy, we need to poll the WG to know if WG agrees 
to progress the document without implementation.

This email starts a 2 weeks poll closing on 04/18/2019.

Please raise your support or any concern regarding the progress of this 
document without implementation.
If you are aware of any implementation, please also state it.


https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

Brgds,

Stephane & Matthew

_

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