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

[Jeff Tantsura]

yes/support

Cheers,
Jeff
On Apr 5, 2019, 10:53 AM -0700, Sami Boutros 
, wrote:
> Support, Please progress the document.
> Thanks,
> Sami
> 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
>
> ___
> 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] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[Sami Boutros]

Support, Please progress the document.



Thanks,



Sami



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

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

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

[Greg Mirsky]

Dear WG Chairs, et al.,
I support going forward with the publication
of draft-ietf-bess-nsh-bgp-control-plane despite the absence of a readily
available implementation. As Andy had noted, three other documents, that
this document refers to, had reached the state of the assured technical
stability thus minimizing the risk for the implementor. I strongly believe
that the publication of this document is in the best interest of everyone
working on aspects of SFC as it provides SFC with the comprehensive dynamic
distributed control plane solution.

Regards,
Greg.

On Thu, Apr 4, 2019 at 4:58 AM  wrote:

> 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
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Andrew G. Malis]

I agree with Joel. I think a reason that we don't yet have implementations
is that this draft has three normative references that are also still
drafts (although
two of them recently joined the RFC Editor's queue and the third has passed
WG LC), so as they get implemented and we get more SFC implementations in
general, I would expect to see activity with this draft as well. It would
be a disservice to wait.

Cheers,
Andy


On Fri, Apr 5, 2019 at 12:53 PM Joel M. Halpern  wrote:

> I think is a useful complement to the work in RFC 8300.  It appears
> ready for publication.  Given the evolution in SFC usage, I think
> getting this out there now serves the community better than waiting for
> the implementations.  Please do progress this.
>
> Thank you,
> Joel
>
> On 4/4/19 1:58 PM, stephane.litkow...@orange.com wrote:
> > 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
> >
>
> ___
> 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] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[Joel M. Halpern]

I think is a useful complement to the work in RFC 8300.  It appears 
ready for publication.  Given the evolution in SFC usage, I think 
getting this out there now serves the community better than waiting for 
the implementations.  Please do progress this.


Thank you,
Joel

On 4/4/19 1:58 PM, stephane.litkow...@orange.com wrote:

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



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

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

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

The Ethernet Tag that you use for DF Election does not even need to match what 
you have in the data path.
Note that the definition says even “configured IDs”.

As long as you use the same ID for the BD on all the PEs attached to the ES, 
you are fine.

Thx
Jorge

From: Muthu Arul Mozhi Perumal 
Date: Friday, April 5, 2019 at 5:10 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: Jaikumar Somasundaram , "bess@ietf.org" 
, P Muthu Arul Mozhi 
Subject: Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

Thanks, Jorge. It is clear that the Ethernet Tag needs to be different from 0 
for the purpose of DF election..

One of the options a provider has for supporting untagged frames in EVPN VPLS 
multihoming in VID translation...a rule to match untagged frames and impose a 
VID at the ingress and another rule to match that VID and dispose it at the 
egress.

Are there any other options that can interop well?

Regards,
Muthu

On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
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 mailto:bess-boun...@ietf.org>> on behalf of 
Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Friday, April 5, 2019 at 6:15 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: P Muthu Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Muthu Arul Mozhi Perumal]

Thanks, Jorge. It is clear that the Ethernet Tag needs to be different from
0 for the purpose of DF election..

One of the options a provider has for supporting untagged frames in EVPN
VPLS multihoming in VID translation...a rule to match untagged frames and
impose a VID at the ingress and another rule to match that VID and dispose
it at the egress.

Are there any other options that can interop well?

Regards,
Muthu

On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> 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 <
> jaikumar.somasunda...@ericsson.com>
> *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 
>VLAN> 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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jaikumar Somasundaram]

Thanks a lot Jorge.

Thanks & Regards
Jaikumar S

From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Friday, April 5, 2019 11:11 AM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: P Muthu Arul Mozhi 
Subject: Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

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 mailto:bess-boun...@ietf.org>> on behalf of 
Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Friday, April 5, 2019 at 6:15 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: P Muthu Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
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