Re: [bess] Routing Directorate Last Call Review for draft-ietf-bess-evpn-irb-mcast-07.txt

[Acee Lindem (acee)]

Hi Jeffrey,

Thanks for addressing my comments. See some comments inline.

From: Jeffrey Zhang 
Date: Monday, November 28, 2022 at 9:09 AM
To: Acee Lindem , "draft-ietf-bess-evpn-irb-mc...@ietf.org" 
, Routing ADs 
Cc: Routing Directorate , "bess@ietf.org" 
Subject: RE: Routing Directorate Last Call Review for 
draft-ietf-bess-evpn-irb-mcast-07.txt

Hi Acee,

Thanks a lot for your thorough review and comments. I have posted -08 revision 
to address most of your comments: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-irb-mcast-08.txt.

Please see zzh> below.



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Tuesday, November 15, 2022 1:49 PM
To: draft-ietf-bess-evpn-irb-mc...@ietf.org; Routing ADs 
Cc: Routing Directorate ; bess@ietf.org
Subject: Routing Directorate Last Call Review for 
draft-ietf-bess-evpn-irb-mcast-07.txt

[External Email. Be cautious of content]

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-irb-mcast-07.txt
Reviewer: Acee Lindem
Review Date: Nov 15th, 2022
IETF LC End Date: Nov 7, 2022
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should be 
resolved before publication.

Comments:

The draft is readable per se but the subject matter, Optimized Inter-Subnet 
Multicast,
is quite complex. The draft covers the mechanisms and procedures for multicast
advertisement and forwarding between tenant-BDs. Additionally, a single line in 
the
abstract includes procedures to accommodate multicast traffic external to the 
tenant
domain results in very dense specification of various interworking with other 
multicast
domains. These interworking scenarios build on the OISM gateway functionality 
specified
early in the document. The cascaded complexity probably explains the number of 
directorate
members who declined the review request. Given the complexity, this is a 
document that
could really benefit from implementation experience.

Major Issues: None

Minor Issues:

   1. The concept of multicast packets and, in some cases, advertisements being 
sent
  "Up" or "Down" the IRB interface seemed confusing to me. I'd of thought 
the IRB
  interfaces would be described in terms of transmission or reception by 
the IRB
  L3 Routing instance. In any case, the usage must be described in the 
terminology
 section is not intuitive even though one can reverse engineer what is 
meant.

Zzh> An IRB interface connects a bridge domain (L2) to an IP routing instance 
(L3). Therefore, we use the up/down to indicate if traffic is up towards the L3 
or down towards L2. I’ve added the following paragraph in section “1.1.2.  
Inter-BD (Inter-Subnet) IP Traffic” where IRB interface was firs mentioned in 
the document:

   In this document, when traffic is 
routed out of an IRB interface,
   we say it is sent down the IRB 
interface to the BD that the IRB is
   for. In the other direction, traffic 
is sent up the IRB interface
   from the BD to the L3 routing 
instance.

That’s better. I was wondering why the IRB interface wasn’t conceptually an L3 
routing instance interface and
“sent down” would be “transmitted” and “sent up” would be “received”. This 
would be a cleaner abstraction to
me. However, I must admit I only read Appendix A and not RFC 9135.


   2. The Section 6 interworking scenarios could benefit from some ASCII art for
   visual reference of the various gateway and domain scenarios.

Zzh> I have added the following figure:



 src1   rcvr1
 |  |
 R1   RPR2

   PIM/MVPN
domain
+---+  +---+
   -|GW1|--|GW2|
+---+  +---+
 | \ \/ / |
 |  \ \  / /  |
   BD1 BD2 SBDSBD BD2 BD1

  EVPN Doma

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-ac-aware-bundling

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of "Stephane Litkowski (slitkows)" 

Date: Monday, October 10, 2022 at 4:40 AM
To: "bess-cha...@ietf.org" , "bess@ietf.org" 

Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-ac-aware-bundling

Hello,

This email begins a two-weeks WG adoption poll for 
draft-sajassi-bess-evpn-ac-aware-bundling-06 [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 October 24th 2022.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ac-aware-bundling/

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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Acee Lindem (acee)]

I’ve reread the draft and support publication.
Thanks,
Acee

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

Date: Monday, January 31, 2022 at 9:00 AM
To: "draft-ietf-bess-evpn-fast-df-recov...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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.
There is currently no IPR disclosed.

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 as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

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

Date: Tuesday, September 7, 2021 at 8:42 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-ebgp-...@ietf.org" 

Subject: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-ebgp-dmz-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 September 21st 2021.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/


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

Re: [bess] VXLAN BGP EVPN Question

[Acee Lindem (acee)]

There are a number of drafts that were waiting years on the IDR tunnel Encap 
draft – they will all be published together in this cluster:

https://www.rfc-editor.org/cluster_info.php?cid=C349

Thanks,
Acee

From: BESS  on behalf of Gyan Mishra 

Date: Saturday, April 24, 2021 at 1:14 PM
To: John E Drake 
Cc: Jeff Tantsura , "Ali Sajassi (sajassi)" 
, "Rabadan, Jorge (Nokia - US)" , 
BESS 
Subject: Re: [bess] VXLAN BGP EVPN Question


That’s fabulous news that everyone has implemented!!

Unfortunate on the red tape with the turn around to RFC.

Kind Regards

Gyan

On Sat, Apr 24, 2021 at 8:29 AM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Yes, and everyone has implemented it.  Unfortunately, it had an inadvertent 
normative reference to the tunnel encapsulation attribute and hence has been in 
the RFC Editor queue for over three years.

Yours Irrespectively,

John



Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Friday, April 23, 2021 6:21 PM
To: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>; BESS 
mailto:bess@ietf.org>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; John E Drake 
mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) mailto:jorge.raba...@nokia.com>>
Subject: Fwd: [bess] VXLAN BGP EVPN Question

[External Email. Be cautious of content]


Authors

Do we know if this draft will progress to RFC?

https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10


This is a very useful draft for intra DC multi pod NVO3 solutions with multiple 
vendors.


Thanks

Gyan


-- Forwarded message -
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Date: Fri, Apr 24, 2020 at 3:07 AM
Subject: Re: [bess] VXLAN BGP EVPN Question
To: Gyan Mishra mailto:hayabusa...@gmail.com>>, Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
CC: BESS mailto:bess@ietf.org>>

Hi Gyan,

If I may, note that:
https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10#section-4.6

Also provides vxlan segmentation, and while the description is based on DCI, 
you can perfectly use it for inter-pod connectivity.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Friday, April 24, 2020 at 5:21 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: BESS mailto:bess@ietf.org>>
Subject: Re: [bess] VXLAN BGP EVPN Question


Hi Jeff

Yes - Cisco has a draft for multi site for use cases capability of inter pod or 
inter site segmented path between desperate POD fabrics intra DC or as DCI 
option inter DC without MPLS.  The segmentation localizes BUM traffic and has 
border gateway DF election for BUM traffic that is segmented stitched between 
PODs as I mentioned similar to inter-as L3 vpn opt b.  There is a extra load as 
you said on the BGW border gateway performing the network vtep dencap from leaf 
and then again encap towards the egress border gateway.  Due to that extra load 
on the border gateway it’s not recommended to have spine function on BGW thus 
an extra layer for multi site to be scalable.  Definitely requires proprietary 
asic and not merchant silicon or white box solution.  The BUM traffic is much 
reduced as you stated from multi fabric connected super spine or single fabric 
spine that contains all leafs.  That decoupling sounds like incongruent control 
and data plane with Mac only Type 2 routes which would result in more BUM 
traffic  but it sounds like that maybe trade off of conversation learning only 
active flows versus entire data center wide Mac VRF being learned everywhere.  
I wonder if their is an option to have that real decoupling of EVPN control 
plane and vxlan data plane overlay that does not impact convergence but adds 
stability and only active flow Type 2 Mac learner across the fabric.

https://datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/

Kind regards

Gyan

On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Gyan,

"Multi site” is not really an IETF terminology, this is a solution implement by 
NX-OS, there’s a draft though. Its main functionality is to localize VxLAN 
tunnels and provide segmented path vs end2end full mesh of VxLAN tunnels 
(participating in the same EVI). We are talking HER here.
The feature is heavily HW dependent as it requires BUM re-encapsulation at the 
boundaries (leaf1->BGW1-BGW2->leaf2..n). So good luck seeing it soon on 

Re: [bess] [Idr] IDR WG last call for draft-ietf-idr-bgp-ext-com-registry-01 (3/11 to 3/25/2021)

[Acee Lindem (acee)]

I just read the document and it seems reasonable. I support publication.
Thanks,
Acee

From: Idr  on behalf of Susan Hares 
Date: Thursday, March 11, 2021 at 7:12 AM
To: IDR List , "bess@ietf.org" 
Subject: [Idr] IDR WG last call for draft-ietf-idr-bgp-ext-com-registry-01 
(3/11 to 3/25/2021)

This begins a 2 week WG last call for
draft-ietf-idr-bgp-ext-com-registry-01 from 3/11 to 3/25.

You can find the draft at:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ext-com-registry/

This draft suggest a cleanup on several BGP Extended Community registries in
order to replace the "Experimental Use" registration procedure in
some entries, since their use is clearly not experimental and thus
misleading.

In your review comments, please include whether you feel this
draft is ready for publication.

Since Adrian’s registry draft (draft-ietf-idr-bgp-ls-registry) was
improved when sent to a wider audience, we the bess WG
to also provide comments.  To aid in quick review,
I’ve included a short portion from the Introduction
of this draft.


Cheers, Sue

===
[RFC7153] reorganizes the IANA registries for the type values and
sub-type values of the BGP Extended Communities attribute.  As a
result the IANA maintained registry entitled "BGP Transitive Extended
Community Types" includes a range of Type Values (0x80-0x8F) with
Experimental Use registration procedure.  Out of this experimental
range the types 0x80, 0x81, 0x82 have been assigned via [RFC5575] and
[RFC7674].  The primary use for those types and sub-type registries
is non experimental.

Section 2 of this document requests the registry cleanup to reflect
the actual use of those code-points (removing "Experimental Use" from
the sub-type registry names) and changes the registration procedure
of the types 0x80, 0x81, 0x82 to first come first serve.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Type 1 RD for Pure IPv6 network -- EVPN

[Acee Lindem (acee)]

Hi Gyan,
Agree with Jakob. There is no reason for the BGP Identifier to be a unique IPv4 
address. Consider an IPv6 only AS. However, there is nothing precluding you 
from using an IPv4 address if you are uncomfortable.

Thanks,
Acee

From: BESS  on behalf of "Jakob Heitz (jheitz)" 

Date: Thursday, February 4, 2021 at 12:52 AM
To: Gyan Mishra 
Cc: TULASI RAM REDDY , Muthu Arul Mozhi Perumal 
, "bess@ietf.org" , IDR List 

Subject: Re: [bess] [Idr] Type 1 RD for Pure IPv6 network -- EVPN

RFC 6286 already updates RFC 4271.
Basically, RID is not unique. (ASN,RID) is unique. The only limitation on RID 
is that RID != 0.

Regards,
Jakob.

From: Gyan Mishra 
Sent: Wednesday, February 3, 2021 9:42 PM
To: Jakob Heitz (jheitz) 
Cc: Muthu Arul Mozhi Perumal ; TULASI RAM REDDY 
; bess@ietf.org; i...@ietf.org
Subject: Re: [Idr] [bess] Type 1 RD for Pure IPv6 network -- EVPN



On Wed, Feb 3, 2021 at 11:22 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:

   Syntactic correctness means that the BGP Identifier field represents
   a valid unicast IP host address.


 Gyan> I do see that verbiage in section 6.2



   If the BGP Identifier field of the OPEN message is syntactically

   incorrect, then the Error Subcode MUST be set to Bad BGP Identifier.

   Syntactic correctness means that the BGP Identifier field represents

   a valid unicast IP host address.



BGP with IGP call back NH tracker checks the NH but how does BGP code validate 
the RIB that the router-id is a connected loopback but

and also advertised by IGP.  I have not tried it but if you set a bogus 
router-id would all the BGP peers go down.

I will try that in the lab.

IOS-XR does not have this check. Nothing breaks by violating this rule. IOS-XR 
implements RFC 6286.
I think you'll be hard pressed to find a router that checks this.
 Gyan> Agreed.  That is exactly what I thought.  I was going to try on IOS XR 
but you saved me some time and results as I expected.  I will try test RFC 6286 
on XR.  Have you tried doing IPv6 only peers on XR and with BGP identifier set 
unique to 4 octet IP address and see if that works.  I am guessing it would 
work as XR does not have the check.

I  am not crazy about the RFC 6286 AS wide BGP identifier with 4 octet 
unsigned non zero integer.  Most operators are more comfortable having unique 4 
octet IP address as BGP identifier and I think would much rather do that as 
long as the check does not exist as even with enabling RFC 6286 and having AS 
wide unique identifier seems odd and scary to me as normally the BGP identifier 
must always be unique within the domain or breaks BGP.

dual stack edge over v6 core RFC 5565 is becoming more common for operators 
every day with SRv6 push and thus IPv6 only routers and running into this issue 
where now you have to enable RFC 6286.

I am thinking it maybe well worthwhile to write a draft that updates RFC 4271 
check as vendors don’t follow it anyway and as we all know not checking is not 
going to break anything and making so that for IPv6 only routers such as in a 
SRv6 core that the BGP identifier can remain a 4 octet IP and then operators 
now could keep the same unique BGP identifier IP you had on the router before 
you ripped it out of the core when transitioned to SRv6.
Regards,
Jakob.

--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Acee Lindem (acee)]

Hi Ali,

This should be updated automatically if the chairs update the “Replaced by” 
meta data for 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/

BTW, I support publication.

Thanks,
Acee

From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Tuesday, February 2, 2021 at 1:17 PM
To: "Ali Sajassi (sajassi)" , 
"slitkows.i...@gmail.com" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01


I looked into the IPR, and it has been disclosed and it shows up for the 
individual version of the draft but for some reason not for the WG version of 
it!

From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Tuesday, February 2, 2021 at 9:39 AM
To: "slitkows.i...@gmail.com" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01

Support the WGLC. I think there is an IPR associated with this draft. I will 
look into and if it is the case, will disclose it ASAP.

Cheers,
Ali

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, January 18, 2021 at 12:58 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01


This email starts a two-week working group last call for 
draft-ietf-bess-evpn-irb-extended-mobility-01 [1]







Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.







This poll runs until February 1st.







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.



There is currently no IPR disclosed.


In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].





Thank you,



Matthew & Stephane

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Acee Lindem (acee)]

Hi Stephane, et al,
I did another quick read of the draft and I support publication. I think it 
would be good to state in the introduction which sections of the draft our 
normative and which are informative.
Thanks,
Acee

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, January 18, 2021 at 3:58 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01


This email starts a two-week working group last call for 
draft-ietf-bess-evpn-irb-extended-mobility-01 [1]







Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.







This poll runs until February 1st.







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.



There is currently no IPR disclosed.


In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].





Thank you,



Matthew & Stephane

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] REMINDER: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[Acee Lindem (acee)]

Speaking as Co-author,
I support WG adoption.
Thanks,
Acee

From: "Bocci, Matthew (Nokia - GB)" 
Date: Tuesday, January 5, 2021 at 11:39 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: REMINDER: WG adoption and IPR poll for 
draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , Acee Lindem 
, , John E Drake 
Resent-Date: Tuesday, January 5, 2021 at 11:39 AM

Hi WG

Thanks to those who have already read and commented on the draft.

I would like to see a few more responses before moving this forward, so I will 
extend the WG adoption poll for another two weeks to close on Tuesday 19th Jan.

Also, I am missing IPR responses from some of the authors. Please can you 
respond to the IPR question if you have not already done so.

Hanks

Matthew

From: Bocci, Matthew (Nokia - GB) 
Date: Wednesday, 9 December 2020 at 09:22
To: bess@ietf.org 
Cc: draft-mohanty-bess-weighted-...@ietf.org 

Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-weighted-hrw-01 [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 23rd December 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/



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

Re: [bess] REMINDER: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[Acee Lindem (acee)]

Speaking as Co-author,

I am aware of IPR on the document.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-mohanty-bess-weighted-hrw

I am not aware of any undisclosed IPR.

Thanks,
Acee



From: "Bocci, Matthew (Nokia - GB)" 
Date: Tuesday, January 5, 2021 at 11:39 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: REMINDER: WG adoption and IPR poll for 
draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , Acee Lindem 
, , John E Drake 
Resent-Date: Tuesday, January 5, 2021 at 11:39 AM

Hi WG

Thanks to those who have already read and commented on the draft.

I would like to see a few more responses before moving this forward, so I will 
extend the WG adoption poll for another two weeks to close on Tuesday 19th Jan.

Also, I am missing IPR responses from some of the authors. Please can you 
respond to the IPR question if you have not already done so.

Hanks

Matthew

From: Bocci, Matthew (Nokia - GB) 
Date: Wednesday, 9 December 2020 at 09:22
To: bess@ietf.org 
Cc: draft-mohanty-bess-weighted-...@ietf.org 

Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-weighted-hrw-01 [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 23rd December 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/



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

Re: [bess] WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[Acee Lindem (acee)]

Support as co-author and not aware of any IPR.
Thanks,
Acee

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, December 9, 2020 at 4:23 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , Acee Lindem 
, , John E Drake 
Resent-Date: Wednesday, December 9, 2020 at 4:22 AM

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-weighted-hrw-01 [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 23rd December 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/



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

Re: [bess] [Idr] IETF 109 draft idr agenda

[Acee Lindem (acee)]

Hi Linda, et al, +BESS,
Isn’t this draft under the auspices of the BESS charter?
Thanks,
Acee

From: Idr  on behalf of Linda Dunbar 

Date: Tuesday, November 10, 2020 at 6:02 PM
To: Jie Dong , IDR List 
Cc: "idr-cha...@ietf.org" 
Subject: Re: [Idr] IETF 109 draft idr agenda

Jimmy and IDR chairs,

Can you add the following to the agenda?

https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/

The document describes encoding of BGP UPDATE messages for the SDWAN edge node 
discovery.

Thank you very much.  I am very sorry that I missed sending the email (I 
thought I did).

Linda Dunbar
From: Idr  On Behalf Of Dongjie (Jimmy)
Sent: Monday, November 9, 2020 9:26 PM
To: i...@ietf.org
Cc: idr-cha...@ietf.org
Subject: [Idr] IETF 109 draft idr agenda

Hi all,

A draft agenda of IDR session on IETF 109 has been posted at: 
https://datatracker.ietf.org/meeting/109/materials/agenda-109-idr

Please take a look and let us know if any change is needed.

Presenters, please remember to send your slides to me and CC the chairs 24 
hours before the meeting session of your presentation, for the first session it 
is Sunday 14:30 ICT (UTC +7) . Thanks.

And FYI here is the checklist for presenting at IDR:

https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%20at%20an%20IDR%20meeting

Best regards,
Jie
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)

[Acee Lindem (acee)]

Hi Erik, 

On 8/17/20, 7:32 AM, "Acee Lindem (acee)"  wrote:

Hi Erik,

On 8/16/20, 7:50 PM, "BESS on behalf of Erik Kline via Datatracker" 
 wrote:

Erik Kline has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: 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-rfc5549revision/



--
COMMENT:
--

[[ comments ]]

[ section 3 ]

* Perhaps "8-octet RD is set to zero" -> "8-octet RD set to zero"

[ section 4 ]

* Perhaps "for which there is already solution" ->
  "for which there is already a solution"

* "from the onset" -> "from the outset", I think

I believe either is correct and I think "onset" is more common.

I guess "onset" usually implies the start of something unpleasant, which would 
hopefully not be the case for supporting next-hops of both AFs __, so I would 
agree with your suggested change. Or it could simply be changed to "from the 
beginning" to avoid any confusion.

https://www.differencebetween.com/difference-between-onset-and-vs-outset/


Thanks,
Acee

Thanks,
Acee

[ section 6.2 ]

* "IPV4" -> "IPv4"

[ section 6.3 ]

* "IPV4" -> "IPv4"



___
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] Erik Kline's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)

[Acee Lindem (acee)]

Hi Erik,

On 8/16/20, 7:50 PM, "BESS on behalf of Erik Kline via Datatracker" 
 wrote:

Erik Kline has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: 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-rfc5549revision/



--
COMMENT:
--

[[ comments ]]

[ section 3 ]

* Perhaps "8-octet RD is set to zero" -> "8-octet RD set to zero"

[ section 4 ]

* Perhaps "for which there is already solution" ->
  "for which there is already a solution"

* "from the onset" -> "from the outset", I think

I believe either is correct and I think "onset" is more common.

Thanks,
Acee

[ section 6.2 ]

* "IPV4" -> "IPv4"

[ section 6.3 ]

* "IPV4" -> "IPv4"



___
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] problem to subscribe to bess mail list

[Acee Lindem (acee)]

With the BESS mailing list administer login, it is possible to add someone to 
the list using  “Membership Management->Mass Subscriptions”. However, it seems 
that https://www.ietf.org/mailman/listinfo/bess should work.

Thanks,
Acee


From: BESS  on behalf of "Mankamana Mishra (mankamis)" 

Date: Monday, July 6, 2020 at 12:43 PM
To: Jiang He 
Cc: "bess@ietf.org" 
Subject: Re: [bess] problem to subscribe to bess mail list

I do not think there is manual way to add some one to list. Added list too in 
thread, in case some one knows about it. Subscription usually works fine 
through web.

From: Jiang He 
Date: Monday, July 6, 2020 at 2:24 AM
To: "Mankamana Mishra (mankamis)" 
Subject: problem to subscribe to bess mail list

Hello mankamana,
I tried to subscribe to bess@ietf.org mail list through 
https://www.ietf.org/mailman/listinfo/bess several times. But no confirmation 
mail was received ( I have successfully received other @ietf.org mails before.) 
Same problem happened when I tried to subscribe to mpls mail list.

Could you please add me to bess mail list?

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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02

[Acee Lindem (acee)]

I support publication of the draft as a standards track RFC.
Thanks,
Acee

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

Date: Monday, June 15, 2020 at 6:56 AM
To: "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-oam-req-frmwk-02

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-oam-req-frmwk-02

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 29th June 2020.

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.
There is currently no IPR disclosed.
Thank you,
Matthew & Stephane

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

Re: [bess] Request for IANA early allocation for draft-ietf-bess-srv6-services code points

[Acee Lindem (acee)]

As a designated expert for this registry, I approve these allocations.
Thanks,
Acee

From: BESS  on behalf of Gaurav Dawra 

Date: Tuesday, March 3, 2020 at 10:54 AM
To: "bess-cha...@ietf.org" , "bess@ietf.org" 

Subject: [bess] Request for IANA early allocation for 
draft-ietf-bess-srv6-services code points

Hello,

We would like to request IANA to perform early allocations for 
https://tools.ietf.org/html/draft-ietf-bess-srv6-services-02#section-9.1 as 
follows:



   Value   TypeReference

   -

   4Deprecated  

   5 (suggested)SRv6 L3 Service TLV 

   6 (suggested)SRv6 L2 Service TLV 



Thanks,

Gaurav (on behalf of co-authors)


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

Re: [bess] Shepherd review comment draft-ietf-bess-mvpn-msdp-sa-interoperation-04

[Acee Lindem (acee)]

Hi Mankamana,

From: BESS  on behalf of "Mankamana Mishra (mankamis)" 

Date: Saturday, April 11, 2020 at 4:41 PM
To: "draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" 

Cc: "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Subject: [bess] Shepherd review comment 
draft-ietf-bess-mvpn-msdp-sa-interoperation-04

Authors,
As part of BESS Shepherd review process, went over document. Its in good shape 
to move forward. But I have some comments .


· Abstract : I think new directive is not to have any RFC reference in 
Abstract, so you can remove reference of RFC 6514 from abstract

As long as the referring text isn’t in the form of an IETF reference, i.e.,  
[RFC], it is fine. In fact, this type of statement is required in a 
document that updates an RFC.

Thanks,
Acee


· Terminology : Since it uses many terms from RFC 7761 (PIM), 6513 and 
5614 . it may be good to state that familiarity with terms used in these RFC 
would be useful.

· Introduction :

o   In introduction I see it talks about PE1 , PE2. But there Is no picture / 
topology in document . it may be useful to have one sample topology created .

o   Introduction does mention one statement about Extranet, but rest of the 
document does not have any mention of it. Do you want to add small paragraph 
which talks about what is expected in case of extranet ?

· Section 3:  Statement from this section “In that case, if the 
selected best MVPN SA route does not have the "MVPN SA RP-address EC" but 
another route for the same (C-S, C-G) does, then the best route with the EC 
SHOULD be chosen.” Does it not make sense to make it as MUST ?


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

Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

[Acee Lindem (acee)]

Support – though I’ve always thought MC-LAG was a hack, it is part of the 
landscape.
Thanks,
Acee

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

Date: Tuesday, January 21, 2020 at 9:51 AM
To: "bess@ietf.org" 
Cc: "draft-brissette-bess-evpn-mh...@ietf.org" 
, "bess-cha...@ietf.org" 

Subject: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-mh-pa-04 [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 won't progress 
without answers from all 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 Tuesday 4th February 2020.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-mh-pa/





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

Re: [bess] WGLC , IPR and implementation poll for draft-ietf-bess-evpn-unequal-lb-03

[Acee Lindem (acee)]

Hi Stephane, BESS WG,
I support publication as a proposed standard. The mechanisms require capability 
advertisement and these must be standardized.
Thanks,
Acee

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Friday, January 17, 2020 at 3:56 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC , IPR and implementation poll for 
draft-ietf-bess-evpn-unequal-lb-03

Hi WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-unequal-lb-03 [2]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Fri 31th January 2019.


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.

There is currently no IPR disclosed.

We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations.

 Thank you,

Stephane

[1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
[2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and Implementation Poll for draft-ietf-bess-rfc5549revision-00

[Acee Lindem (acee)]

I support publication. I have reviewed the document and have the following 
suggestions.


  1.  It would read better if the document simply used “Next Hop Address 
Family” or “Next Hop address AF” as opposed to “set of network-layer protocols 
to which the address in the Next Hop field may belong”.
  2.  Replace all instances of  “in order to” with simply “to”.
  3.  Replace “whose 8-octet RD is set to zero” with “with an 8-octet RD set to 
zero”.
  4.  Replace “establish whether its” with “determine whether its”.

Thanks,
Acee

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

Date: Monday, January 6, 2020 at 12:54 PM
To: "bess@ietf.org" 
Subject: [bess] WG Last Call and Implementation Poll for 
draft-ietf-bess-rfc5549revision-00

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-rfc5549revision-00.

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 20th January 2019.

We have only just completed an IPR poll on the draft prior to adoption in 
December 2019, so I will not run another one now.

There is currently no IPR disclosed.

We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations of the modified protocol described in 
this draft.

 Thank you,

Matthew

[1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, January 6, 2020 at 9:15 AM
To: "bess@ietf.org" 
Cc: "draft-zzhang-bess-bgp-multic...@ietf.org" 
, "bess-cha...@ietf.org" 

Subject: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

Hello,

This email begins a two-weeks WG adoption poll for and 
draft-zzhang-bess-bgp-multicast-03 [1] ..
For information, it’s companion document 
(draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG adoption 
in a separate email.

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 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 *** 20th January 2020 ***

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast

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

Re: [bess] WG adoption poll and IPR poll for draft-zzhang-bess-bgp-multicast-controller

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, January 6, 2020 at 9:13 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-zzhang-bess-bgp-multicast-controller

Hello,

This email begins a two-weeks WG adoption poll for and 
draft-zzhang-bess-bgp-multicast-controller-02 [1] ..
For information, it’s companion document (draft-zzhang-bess-bgp-multicast-03) 
is also polled for WG adoption in a separate email.

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 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 *** 20th January 2020 ***

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast-controller/

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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Hi Robert,
Even in the fastidious IDR WG, an implementation report is NOT a requirement 
for WG adoption. Here is the policy for BESS:

https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

So, there will be a poll at WG last call but not necessarily a formal report 
Wiki.

Hope this helps,
Acee

From: Robert Raszuk 
Date: Tuesday, December 3, 2019 at 11:39 AM
To: Acee Lindem 
Cc: "slitkows.i...@gmail.com" , "Bocci, Matthew (Nokia 
- GB)" , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

There is no single vendor mentioned. There is no name of the reporter 
mentioned. This is not an implementation report.

This draft sole reasoning is based on the implementations. I am looking for 
formal implementation report - just like we always do in idr:

https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Example:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

Thx,
R.


On Tue, Dec 3, 2019 at 5:24 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, December 3, 2019 at 8:25 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi,

I am not that naive to think that you can do something else here ;)

But can you at least send a pointer to formal implementation report before 
proceeding ?

Here are the slides presented at the Tuesday afternoon BESS WG sessions. The 
results of the implementation survey are included.

https://datatracker.ietf.org/meeting/106/materials/slides-106-bess-sessa-draft-litkowski-bess-vpnv4-ipv6-nh-handling-00-00

Thanks,
Acee

Thx a lot,
R.

On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,
My point is that your proposal to save the 8 bytes of RD can be independent of 
correcting RFC 5449. It is pretty much a no-brainer that revising the 
specification to match the de facto standard of all extant implementations is 
preferable to a non-trivial upgrade and migration.

Anyway, I don’t wish to engage in a protracted debate and I don’t believe the 
WG wishes to delay publication of this draft. Your lone objection can be noted 
in the shepherds report.

Thanks,
Acee


From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Monday, December 2, 2019 at 6:37 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Tuesday, December 3, 2019 at 8:25 AM
To: Acee Lindem 
Cc: "slitkows.i...@gmail.com" , "Bocci, Matthew (Nokia 
- GB)" , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi,

I am not that naive to think that you can do something else here ;)

But can you at least send a pointer to formal implementation report before 
proceeding ?

Here are the slides presented at the Tuesday afternoon BESS WG sessions. The 
results of the implementation survey are included.

https://datatracker.ietf.org/meeting/106/materials/slides-106-bess-sessa-draft-litkowski-bess-vpnv4-ipv6-nh-handling-00-00

Thanks,
Acee

Thx a lot,
R.

On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,
My point is that your proposal to save the 8 bytes of RD can be independent of 
correcting RFC 5449. It is pretty much a no-brainer that revising the 
specification to match the de facto standard of all extant implementations is 
preferable to a non-trivial upgrade and migration.

Anyway, I don’t wish to engage in a protracted debate and I don’t believe the 
WG wishes to delay publication of this draft. Your lone objection can be noted 
in the shepherds report.

Thanks,
Acee


From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Monday, December 2, 2019 at 6:37 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, "Bocci, Matthew 
(Nokia - GB)" mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendor

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Hi Robert,
My point is that your proposal to save the 8 bytes of RD can be independent of 
correcting RFC 5449. It is pretty much a no-brainer that revising the 
specification to match the de facto standard of all extant implementations is 
preferable to a non-trivial upgrade and migration.

Anyway, I don’t wish to engage in a protracted debate and I don’t believe the 
WG wishes to delay publication of this draft. Your lone objection can be noted 
in the shepherds report.

Thanks,
Acee


From: Robert Raszuk 
Date: Monday, December 2, 2019 at 6:37 PM
To: Acee Lindem 
Cc: "slitkows.i...@gmail.com" , "Bocci, Matthew (Nokia 
- GB)" , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as next 
hop.

If we are prepend it with zero pls do not forget to also submit the errata to 
RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable IP 
address. Not part of the
Next Hop field but the entire *field*.


   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set

   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP

   address of the ASBR.



And the above is just the tip of the iceberg :)



Bottom line is that instead of publishing the spec which in backwards 
compatible fashion allows

gradually to fix the implementation errors of the past it is just blessing 
them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely unnecessary. Not 
a good thing

in my measures.



Best,

R.



PS. And what happens if those 8 octets is not zeros but zero and ones ? Should 
it be accepted and

ignored or is this an invalid attribute ?





On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>
Cc: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. Sure they want to be backwards 
compatible too, but with that let's also give them a chance to do the right 
thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional 
capability indicating if receiver can process next hop without any additional 
nonsense zero padding. All it takes is one paragraph/section and one IANA 
codepoint.

Stating that this should be new separate document again updating 5549 and now 
5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM 
mailto:slitkows.i...@gmail.com>> wrote:
Hi Robert,

Please see some replies inline.

Brgds,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew..bo...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

I do not support this draft in the current form.

This document instead of improving the original specification makes it actually 
worse.
[SLI]

Point 1 -

Or

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

Robert,

What you’re suggesting doesn’t really solve the problem that all the currently 
deployed routers that do not follow RFC 5549. No known implementations follow 
RFC 5549. Were you on the meetecho when this was presented in the BESS meeting 
at IETF 106? There was clear consensus in the meeting.

Anyway,  you can put your ideas in a new draft and let them stand on their own 
merit. That way, if there were consensus, we could save those 8 bytes of RD. 
However, we shouldn’t mix this with the draft revising RFC 5549 to reflect the 
current implementations and deployments.

Thanks,
Acee

From: BESS  on behalf of Robert Raszuk 

Date: Thursday, November 28, 2019 at 11:58 AM
To: "slitkows.i...@gmail.com" 
Cc: "Bocci, Matthew (Nokia - GB)" , 
"bess-cha...@ietf.org" , "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Stephane,

Adding ability to recognize the length of the next hop to any code is purely 
incremental thing. When vendors were asked I do not even recall if there was a 
question if given implementation can infer next hop format from length or not - 
and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and stating 
that if so you do revise 5549 to reflect that is not what we should be doing.

The main reason is that as SAFIs are being defined every now and then and there 
is still no clear document if next hop should match NLRI type or not. Moreover 
4364 is still being developed in few vendors. Sure they want to be backwards 
compatible too, but with that let's also give them a chance to do the right 
thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional 
capability indicating if receiver can process next hop without any additional 
nonsense zero padding. All it takes is one paragraph/section and one IANA 
codepoint.

Stating that this should be new separate document again updating 5549 and now 
5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM 
mailto:slitkows.i...@gmail.com>> wrote:
Hi Robert,

Please see some replies inline.

Brgds,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew..bo...@nokia.com>>
Cc: bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

I do not support this draft in the current form.

This document instead of improving the original specification makes it actually 
worse.
[SLI]

Point 1 -

Original RFC sec. 6.2:

   o  Network Address of Next Hop = IPv6 address of Next Hop

Proposed text:

   o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
RD is set to zero


As it has been explained when you negotiate in capability AFI2 as next hop it 
is just 16 octets - not 24.
[SLI] AFI2 means that the nexthop is encoded with a format compliant with an 
AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is still 
AFI2.

Next hop never has an RD.
[SLI] We have already discussed about that. RD doesn’t make any sense for a 
nexthop address. No one disagrees on that point. However our legacy 2547bis 
introduced a nexthop encoded as a VPN-IP address, and all VPN unicast SAFIs are 
following this. As RD does not make sense, zeroes are just added to fit the 
size of the address format. In reality, it is just an IP address with 0es 
padded before. Of course,  it would have been cleaner to use only a regular IP 
address instead of a VPN-IP address but again that’s our legacy.

The fact that some implementations are matching length of NLRI with length of 
next hop no where should be made equal that next hop has 8 octet dummy Route 
Distinguisher.
[SLI] Again this is coming from legacy.


If revision is to be made would be to explicitly negotiate capability to infer 
next hop encoding from the length.
[SLI] Are you talking about a new capability or the existing ENH cap ? ENH 
tells you what is the NH AFI, so the only length check required is for the case 
of one or two IPv6 addresses. A new cap means a new solution, and that’s not 
the goal here.


Point 2 -

Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding is 
lightly stating suboptimal.

Conclusion:

As we have discussed on and off line if revision is to be made let's make it 
both backwards compatible, Let's make it applicable to both IPv4 and IPv6 next 
hop addresses and let's allow explicit capability where implementations could 
indicate that it can recognize next hop value from its length. After all we are 
talking about just 4 discrete possible values here.
[SLI] The goal is not to create something new here, but just to reflect how 
RFC5549 has been implemented for the SAFI 128/129 cases. The goal is also to 
minimize running code changes too (and even avoid !).. We 

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Acee Lindem (acee)]

I support WG adoption. This is update is desperately needed to reflect current 
implementations and deployments.
Thanks,
Acee

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

Date: Wednesday, November 27, 2019 at 7:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [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 won't progress 
without answers from all 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 Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG adoption poll for draft-sajassi-bess-evpn-mvpn-seamless-interop

[Acee Lindem (acee)]

Support

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, October 28, 2019 at 6:10 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop

Hello,

This email begins a two-weeks WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop [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 won't progress 
without answers from all 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 11th November 2019.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-mvpn-seamless-interop/

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

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

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

Date: Friday, September 27, 2019 at 6:01 AM
To: "draft-dawra-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [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 won't progress 
without answers from all 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 Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


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

Re: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn profiles

[Acee Lindem (acee)]

Hi Gyan,
See one inline.

From: BESS  on behalf of Gyan Mishra 

Date: Saturday, September 28, 2019 at 2:06 PM
To: Gyan Mishra , "bess@ietf.org" 
Subject: Re: [bess] RFC or Draft that lists all standards track rfc’s of all 
mvpn profiles


I did some research and theseare the main RFCs for MVPN and how based they map 
to CISCO profiles and you do the same for Juniper and Huawei.

The 1st two are for mLDP w/ BGP-AD pim (in band) or bgp (out of band)c-signaling

UI-PMSI (uni directional inclusive provider multicast service instance) Cisco 
Default MDT for PIM SM or SSM

MI-PMSI (multi directional provider multicast service instance)  CISCO Default 
MDT for PIM SM or SSM

S-PMSI (Selective Provider multicast service instance) CISCO Data MDT for PIM 
SM or SSM

PIM dense mode MVPN  not supported - I don’t think anyone uses dense these days

That is mostly true. However, it is used for PIM auto-rp advertisements (groups 
224.0.1.39 and 224.0.1.40).

Thanks,
Acee


https://tools.ietf.org/html/rfc6513 MVPN

https://tools.ietf.org/html/rfc6514 MVPN


https://tools.ietf.org/html/rfc6037. Rosen PIM GRE

https://tools.ietf.org/html/rfc4875 P2MP TE
Sent from my iPhone

On Sep 28, 2019, at 11:58 AM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
BESS WG / All

I am trying to find a list of all MVPN profiles that are supported by Cisco and 
Juniper and Huawei SP router vendors.

Below link shows what CISCO supports most of which I believe are a CISCO 
proprietary and non standard so won’t work between vendors.


https://www.cisco.com/c/en/us/support/docs/ip/multicast/200512-Configure-mVPN-Profiles-within-Cisco-IOS.html

Thank you

Gyan Mishra
Verizon Communications
Cell 301 502-1347
Sent from my iPhone
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[Acee Lindem (acee)]

Support working group publication of this document. There are implementations.
Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Monday, June 17, 2019 at 4:56 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].



This poll runs until *the 28th 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 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.



We have several IPRs already disclosed.



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 as per [2].



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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

Re: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Tuesday, May 7, 2019 at 3:37 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

Hi,


This email begins a two-week poll for adoption of 
draft-jain-bess-evpn-lsp-ping-08[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 won't progress 
without answers from all 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 21th May 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

_



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

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[Acee Lindem (acee)]

I support WG adoption. The draft precisely defines the host mobility for EVPN 
IRB and the attendant route types.
Thanks,
Acee


From: BESS  on behalf of Stephane Litkowski 

Date: Wednesday, March 20, 2019 at 8:53 AM
To: Stephane Litkowski , "bess@ietf.org" 
, "draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi WG,

Apart from the authors, we haven’t received a lot of feedback for this draft 
(positive or negative).
I would like to expand the poll to an additional week (ends at 26th March) to 
see if we can get more support on the list.

Brgds,

From: stephane..litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 05, 2019 09:43
To: bess@ietf.org; draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-04
[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 won't progress 
without answers from all 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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



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.

_



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

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[Acee Lindem (acee)]

Hi Stephane, 
No objection - I think the question on whether BOS should be encoded in those 
bits confirms that this should be specified. 
Thanks,
Acee

On 10/22/18, 9:47 AM, "BESS on behalf of stephane.litkow...@orange.com" 
 wrote:

Hi,

Does anyone disagree with the additional Jakob's statement proposal ?
" The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."

As an example, in MVPN for PMSI tunnel attribute, we have the following 
statement which does not tell anything about the lower order bits:
" If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value.  Absence of an MPLS Label is indicated by setting the MPLS
   Label field to zero."


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, October 16, 2018 19:30
To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.


Yes, just the encoding of label value needs to be clear. 

Cheers,
Ali



On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" 
 wrote:

How about:
The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.

Regards,
Jakob.


-Original Message-
From: Zhuangshunwan  
Sent: Monday, October 15, 2018 6:02 PM
To: Jakob Heitz (jheitz) ; BESS 
Subject: RE: Encoding a 20 bit label in a 24 bit field.

It is good to make this explicit. This ambiguity has led to some 
unnecessary interworking problems.

Should we also need to explicitly define the "bottom of stack" bit in 
the low-order bit of the 3-octet label field?

Thanks,
Shunwan

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jakob Heitz 
(jheitz)
Sent: Tuesday, October 16, 2018 4:21 AM
To: BESS 
Subject: [bess] Encoding a 20 bit label in a 24 bit field.

We have proposed the following erratum for RFC 7432.

Opinions?

Regards,
Jakob.


-Original Message-
From: RFC Errata System 
Sent: Friday, October 12, 2018 12:37 PM
To: Ali Sajassi (sajassi) ; raggarw...@yahoo.com; 
nabil.n.bi...@verizon.com; aisaa...@bloomberg.net; utt...@att.com; 
jdr...@juniper.net; wim.henderi...@alcatel-lucent.com; db3...@att.com; 
aretana.i...@gmail.com; martin.vigour...@nokia.com; Giles Heron (giheron) 
; nabil.n.bi...@verizon.com
Cc: Krishnamoorthy Arumugham (karumugh) ; 
l2...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC7432 (5523)

The following errata report has been submitted for RFC7432, "BGP 
MPLS-Based Ethernet VPN".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5523

--
Type: Technical
Reported by: Krishnamoorthy Arumugham 

Section: 7

Original Text
-
Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5


Corrected Text
--
Section 7.1:
Add below text to the section 7.1 regarding the encoding of MPLS label:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding of both the 
MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of ESI Label 
fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the ESI Label field."


Notes
-
MPLS label is a 20-bit value and is stored in a 3 bytes field in a 
packet. The 20-bit MPLS label value is generally stored in higher order 20 bits 
of the 3 byte label field. The exact encoding to be followed for storing MPLS 
label values are not explicitly mentioned in the RFC 7432 under section 7.1, 
7.2 and 7.5 for different types of EVPN routes. This lead to ambiguity in 
different implementations. Hence a clarification is required.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss 

Re: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Tuesday, September 4, 2018 at 3:29 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-malhotra-bess-evpn-unequal-lb-04 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 18th September.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-unequal-lb/






_



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

Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[Acee Lindem (acee)]

Hi Stephane, Authors,

I support advancement. This is a useful optimization that has been implemented .

Two comments:


  1.  Call the new BGP Community “Router MAC” rather than “Router’s MAC”.
  2.   Consistently use “TSes” to refer to multiple Tenant Systems and “TS’s” 
to refer to an address or other entity processed by a Tenant System.

I have some other editorial comments that I will pass to the authors.

Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Wednesday, August 8, 2018 at 10:03 AM
To: "bess@ietf.org" 
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_



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

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-per-mcast-flow-df-election

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Wednesday, August 8, 2018 at 9:38 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-per-mcast-flow-df-election

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-per-mcast-flow-df-election-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Wed 22th Aug.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-per-mcast-flow-df-election/




_



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

Re: [bess] WG Adoption and IPR Poll for draft-sajassi-bess-evpn-virtual-eth-segment-03

[Acee Lindem (acee)]

I also support WG adoption.
Thanks,
Acee

From: BESS  on behalf of "Patrice Brissette (pbrisset)" 

Date: Saturday, June 2, 2018 at 5:27 PM
To: "Bocci, Matthew (Nokia - GB)" 
Cc: "draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org" 
, "bess@ietf.org" 

Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

Hi,

I support the adoption. I’m aware of IPR.

Regards,
Patrice Brissette
From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Friday, June 1, 2018 at 5:48 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: 
"draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org"
 
mailto:draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

We’ve only had a couple of responses from people who are not co-authors of the 
draft. It would be good to see some wider interest, so please review the draft 
and indicate to the list if you support adoption or not, especially if you are 
not a co-author. I will extend the poll for adoption for another week, 
accordingly.

Thanks to those who have already commented.

Regards

Matthew and Stephane

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Thursday, 17 May 2018 at 11:24
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: 
"draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org"
 
mailto:draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org>>
Subject: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

This email begins a two-week poll for adoption of 
draft-sajassi-bess-evpn-virtual-eth-segment-03.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 Thursday 31st May 2018.

Regards,
Matthew and Stéphane

___
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] WG adoption and IPR poll for draft-sajassi-bess-evpn-fast-df-recovery-02

[Acee Lindem (acee)]

This draft solves a real problem with DF election and I support WG adoption.
Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Monday, May 14, 2018 at 5:48 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-fast-df-recovery-02

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-fast-df-recovery-02 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

If you are 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.

The poll for working group adoption closes on Monday 28th May.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-fast-df-recovery/



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-vpws-fxc-03.txt

[Acee Lindem (acee)]

I support WG adoption of this draft.
Thanks,
Acee

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

Date: Monday, April 9, 2018 at 9:23 AM
To: "draft-sajassi-bess-evpn-vpws-...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-vpws-fxc-03.txt.

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Matthew and Stéphane

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

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Acee Lindem (acee)]

Hi John,

So I must surmise that all the MAC routes are associated with the more granular 
virtual ESs? If so, what is the purpose of the aggregate DC ES?

Thanks,
Acee

From: BESS  on behalf of John E Drake 

Date: Friday, April 6, 2018 at 9:46 AM
To: Wen Lin , Sandy Breeze , "Ali 
Sajassi (sajassi)" , "UTTARO, JAMES" , 
"Rabadan, Jorge (Nokia - US)" , Eric C Rosen 
, "Satya Mohanty (satyamoh)" 
Cc: "bess@ietf.org" 
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi,

We use the virtual ES concept to get additional granularity within a DC.  I.e., 
there is one ES for the entire DC and multiple virtual ESes, e.g., one per 
rack, that are anchored to it.  This allows us to perform mass-withdraw for 
individual rack(s) or mass-withdraw for the entire DC.

Yours Irrespectively,

John

From: Wen Lin
Sent: Friday, April 6, 2018 9:26 AM
To: Sandy Breeze ; Ali Sajassi (sajassi) 
; UTTARO, JAMES ; John E Drake 
; Rabadan, Jorge (Nokia - US/Mountain View) 
; Eric Rosen ; Satya Mohanty 
(satyamoh) 
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Sandy,

Yes, you can have all remote VTEPs share the same virtual ES.  The other 
alternative is that each remote VTEP is assigned with its own virtual ES, so 
that we can achieve load balance and quick mass withdrawal when a remote VTEP 
is no longer reachable.

Thanks,
Wen

From: Sandy Breeze >
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin >, "Ali Sajassi 
(sajassi)" >, "UTTARO, JAMES" 
>, John E Drake 
>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" >, 
Eric Rosen >, "Satya Mohanty 
(satyamoh)" >
Cc: "bess@ietf.org" >
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Wen,

Yes, we absolutely need to support more than one remote VTEP in the access 
side.  As for how to deal with one or more than one remote VTEP, I don’t agree 
it’s quite the same as one CE vs more than one CE.  For a single VNI in a BD, 
we should treat this as a single virtual ES in a BD, regardless of how many 
remote VTEPs there are participating in it.  This is treated differently to 
multiple CE on a BD, because multiple CE might imply multiple ES’s.

Cheers
Sandy

On 03/04/2018, 19:01, "Wen Lin" > 
wrote:

The question is, in general,  whether we need to support more than one remote 
VTEP in this type of use case when VXLAN is used on the access side?   I think 
the answer is yes.

So the question about how to deal with “one remote VTEP verses more than one 
remote VTEP” is logically the same as “one CE verses more than one CE”.

Thanks,
Wen


From: BESS > on behalf of 
"Ali Sajassi (sajassi)" >
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" >, John E Drake 
>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" >, 
Eric Rosen >, Sandy Breeze 
>, "Satya Mohanty 
(satyamoh)" >
Cc: "Ali Sajassi (sajassi)" >, 
"bess@ietf.org" >
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

Draft-mohanty-bess-evpn-bum-opt is for a very specific use case and that use 
case is described in section 4.4 of draft-ietf-bess-dci-evpn-overlay. The 
solution for optimization for this use case could have been covered either in 
igmp-mld-proxy draft itself or it could be covered in a separate draft. I 
suggested it to be covered in a separate draft because I wasn’t keen in adding 
a new section to igmp-mld-proxy given that it is getting ready for WG LC. 
However, if people think it should be covered in igmp-mld-proxy draft then we 
can take that under consideration.

The interconnect of L2 to IRB/L3 core 

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Acee Lindem (acee)]

I support publication.
Thanks,

Acee

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

Date: Wednesday, March 28, 2018 at 8:50 AM
To: "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.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.
We are also polling for any existing implementations.
The working group last call closes on Wednesday 11th April.

Regards,
Matthew and Stéphane
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Acee Lindem (acee)]

I support publication.
Thanks,
Acee

From: BESS  on behalf of Stephane Litkowski 

Date: Monday, March 26, 2018 at 10:21 AM
To: "bess@ietf.org" 
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


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

Re: [bess] Pattern statements [was Re: [netmod] Query about augmenting module from submodule in YANG 1.0]

[Acee Lindem (acee)]

Hi Rob,
I’m fine with simplifying (even if the resultant pattern is much less 
impressive ;^). I’ve copied the BESS WG to see if there are any objections.
Thanks,
Acee

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
<rwil...@cisco.com<mailto:rwil...@cisco.com>>
Date: Monday, August 21, 2017 at 11:14 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Ivory, William" 
<william.iv...@intl.att.com<mailto:william.iv...@intl.att.com>>, 
"'net...@ietf.org<mailto:'net...@ietf.org>'" 
<net...@ietf.org<mailto:net...@ietf.org>>, Andy Bierman 
<a...@yumaworks.com<mailto:a...@yumaworks.com>>
Subject: Pattern statements [was Re: [netmod] Query about augmenting module 
from submodule in YANG 1.0]


Hi Acee,

That makes sense.

The other thing that I think that we have got wrong is modelling regex pattern 
statements.  I think that it would be much better if these were written to be 
less exhaustive and much simpler.

E.g. the "route distinguisher" pattern in draft-ietf-rtgwg-routing-types-09 is 
defined as this:

 pattern
   '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
 + '6[0-4][0-9]{3}|'
 + '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
 + '42949672[0-8][0-9]|'
 + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
 + '42949[0-5][0-9]{4}|'
 + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
 + '42[0-8][0-9]{7}|4[01][0-9]{8}|'
 + '[0-3]?[0-9]{0,8}[0-9]))|'
 + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
 + '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
 + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
 + '655[0-2][0-9]|'
 + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
 + '[0-5]?[0-9]{0,3}[0-9]))|'
 + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
 + '4294967[01][0-9]{2}|'
 + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
 + '4294[0-8][0-9]{5}|'
 + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
 + '[0-3]?[0-9]{0,8}[0-9]):'
 + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
 + '6[0-4][0-9]{3}|'
 + '[0-5]?[0-9]{0,3}[0-9]))|'
 + '(6(:[a-fA-F0-9]{2}){6})|'
 + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
 + '[0-9a-fA-F]{1,12})';
   }


But I think that it would be much easier to read, and quite possibly more 
performant to execute, if the pattern regex was written something like the 
following:

 pattern:
'(0:[0-9]{1,5}:[0-9]{1,10})|
 (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
 (2:[0-9]{1,10}:0:[0-9]{1,5})|
 (6(:[a-fA-F0-9]{2}){6})';

Of course, this would allow more invalid values, but most servers would be 
expected to reject those when it converts them into an internal binary format 
any way.

What do you, and others, think?

Thanks,
Rob


On 21/08/2017 15:01, Acee Lindem (acee) wrote:

Hi William, Rob, Andy,

Given their limited usefulness and the detriments, perhaps we should
discourage the creation of new submodules in RFC6087Bis.

Thanks,
Acee

On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
<netmod-boun...@ietf.org on behalf of 
william.iv...@intl.att.com><mailto:netmod-bounces@ietf.orgonbehalfofwilliam.iv...@intl.att.com>
 wrote:



Hi Rob,

That would make it very hard to update existing 1.x YANG models to use
new features in YANG 2.x if they used submodules.  Maybe that's something
that no one would ever consider doing anyway, or maybe YANG 1.1 already
has similar differences to 1.0?  I had (perhaps naively) assumed that you
could migrate a namespace / model from YANG 1.0 to 2.0?

Regards,

William

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: 21 August 2017 11:24
To: net...@ietf.org<mailto:net...@ietf.org>
Subject: Re: [netmod] Query about augmenting module from submodule in
YANG 1.0



On 09/08/2017 16:13, Juergen Schoenwaelder wrote:


On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:


I remember that in early stages of YANG there was some irrational
fear of introducing too many namespaces, and submodules may be a
consequence of it. As you write, submodules provide no benefits
whatsoever in terms of modularity, but the overhead in terms of
metadata, IANA registration etc. is pretty much the same as for
modules.


In case YANG 2.0 is ever done, I suggest someone files a proposal to
remove submodules if the cost/benefit ratio is at odds. There is
nothing wrong with removing stuff that has been found problematic.


I agree.

I've added
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dw
g_yang-2Dnext_issues_26=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=p8kyeK3u4ZYiaQ
2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7ow
I=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8=

Rob

Re: [bess] WG Last Call for draft-ietf-bess-fat-pw-bgp

[Acee Lindem (acee)]

Support

On 6/12/17, 12:27 PM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-fat-pw-bgp-02 [1] which is considered mature and ready
>for a final working group review.
>
>¤ Please read this document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*26th of June*.
>Note that this is *not only* a call for comments on the document; it is
>also a call for support (or not) to publish this document as a Proposed
>Standard RFC.
>
>¤ *Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-fat-pw-bgp, 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 a document Author or Contributor of
>draft-ietf-bess-fat-pw-bgp-02 please respond to this email and indicate
>whether or not you are aware of any relevant IPR.
>
>Note that, as of today, no IPR has been disclosed against this document
>or its earlier versions.
>
>¤ We are also polling for knowledge of implementations of part or all of
>what this document specifies. This information is expected as per [2].
>Please inform the mailing list, or the chairs, or only one of the chairs.
>
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/
>[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>___
>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] WG Last Call for draft-ietf-bess-evpn-usage

[Acee Lindem (acee)]

I support publication.
Thanks,
Acee

On 6/6/17, 10:11 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-evpn-usage-04 [1] which is considered mature and ready
>for a final working group review.
>
>Please read this document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*20th of June*.
>Note that this is *not only* a call for comments on the document; it is
>also a call for support (or not) to publish this document as an
>Informational RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-evpn-usage, 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 a document Author or Contributor of
>draft-ietf-bess-evpn-usage-04 please respond to this email and indicate
>whether or not you are aware of any relevant IPR.
>
>Note that, as of today, no IPR has been disclosed against this document
>or its earlier versions.
>
>As opposed to the policy [2], we are not polling for knowledge of
>implementations as it does not seem to make sense in that case. If you
>feel otherwise, please let us know.
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/
>[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>___
>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

[Acee Lindem (acee)]

I support WG adoption as the described mechanisms fully satisfy Service
Provider (SP) EVPN DF election control requirements.
Thanks,
Acee 

On 6/6/17, 9:44 AM, "BESS on behalf of thomas.mo...@orange.com"
 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

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

Re: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis

[Acee Lindem (acee)]

Hi Loa, et al, 

I support publication of this draft as a standards track document. It is
well-written and handles previously unspecified details of single and
multiple label BGP advertisement.

Thanks,
Acee 

On 4/4/17, 8:33 AM, "BESS on behalf of Loa Andersson"
 wrote:

>Working Groups,
>
>This is to initiate a two week working group last call in four working
>groups on draft-ietf-mpls-rfc3107bis-01.
>
>According to agreement when we decided to host this document in the
>MPLS working group, this last call is also copied to the IDR and BESS
>working groups.
>
>Please send your comments to the mpls wg mailing list (m...@ietf.org),
>if you are not subscribed to the mpls wg list, send to "your own"
>working group mailing list, and we'll make sure they are posted to the
>MPLS wg list.
>
>There are no IPR disclosures against this document.
>
>All the authors and contributors have stated on the working group
>mailing list that they are not aware of any other IPRs that relates
>to this document.
>
>This working group last call ends April 20, 2017.
>
>
>/Loa
>MPLS wg co-chairs
>-- 
>
>
>Loa Anderssonemail: l...@mail01.huawei.com
>Senior MPLS Expert  l...@pi.nu
>Huawei Technologies (consultant) phone: +46 739 81 21 64
>
>___
>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] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

[Acee Lindem (acee)]

Support. While I won’t comment on specifics, the IPR appears to only apply
to one aspect of the proposed SFC mechanisms.
Thanks,
Acee 

On 4/13/17, 2:04 PM, "BESS on behalf of Martin Vigoureux"
 wrote:

>WG
>
>Given the IPR disclosed [1] against
>draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for
>comment specifically to let people express a revised opinion on how
>draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS.
>
>This call for comment is open until the 5th of May
>
>Thanks
>M
>
>[1] https://datatracker.ietf.org/ipr/2980/
>
>___
>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] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT)

[Acee Lindem (acee)]

Hi Spencer, 

On 4/7/17, 5:46 PM, "BESS on behalf of Spencer Dawkins"
 wrote:

>Spencer Dawkins has entered the following ballot position for
>draft-ietf-bess-evpn-vpws-11: 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-evpn-vpws/
>
>
>
>--
>COMMENT:
>--
>
>I did have some non-Discuss questions that you might wish to think about
>before the document is approved ...
>
>In the Abstract
>
>   This document describes how EVPN can be used to support Virtual
>   Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
>   following characteristics for VPWS: single-active as well as all-
>   active multi-homing with flow-based load-balancing, eliminates the
>   need for traditional way of Pseudowire (PW) signaling, and provides
>   fast protection convergence upon node or link failure.
>
>everything is exceptionally clear, except that I don't know what the
>"traditional way" of signaling means.
>
>The same phrase appears in Section 1  Introduction
>
>   This document describes how EVPN can be used to support Virtual
>   Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN
>   mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P
>   services. These benefits include single-active redundancy as well as
>   all-active redundancy with flow-based load-balancing. Furthermore,
>   the use of EVPN for VPWS eliminates the need for traditional way of
>   PW signaling for P2P Ethernet services, as described in section 4.
>
>with the addition of "as described in section 4", but I didn't see an
>explicit statement in Section 4 that explained what was replacing the
>"traditional way". Even a clear reference to an RFC where the
>"traditional way" was defined would be helpful.
>
>It would probably be helpful to expand acronums like "P2P" on first use.
>I immediately thought "peer to peer?" but I bet you didn't mean that.
>Yes, there's a terminology section, but it's three and a half pages into
>the document.
>
>In this text, 
>
>   For EVPL service,
>   the Ethernet frames transported over an MPLS/IP network SHOULD
>remain
>   ^^
>   tagged with the originating VLAN-ID (VID) and any VID translation
>   MUST be performed at the disposition PE.
>
>why is this a SHOULD? I guess my first question should be "does this
>still work if you don't?"
>
>In this text,
>
>   In multihoming scenarios, both B and P flags MUST NOT be both set.


> 
>
>the double both(s) made this difficult to parse. Is it saying
>
>   In multihoming scenarios, the B and P flags MUST be cleared.
>
>or something else? But I'm guessing, and the rest of that paragraph made
>me doubt my guesses.

I think it is clear that it means they are mutually exclusive.

Thanks,
Acee (Routing Directorate Reviewer of this draft)
>
>
>___
>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] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

[Acee Lindem (acee)]

Hi Jorge, 

On 3/13/17, 9:04 AM, "BESS on behalf of Rabadan, Jorge (Nokia - US)"
<bess-boun...@ietf.org on behalf of jorge.raba...@nokia.com> wrote:

>Sami, 
>
>About this one:
>
>³  1. Why is receiving an extended community with both the P and B flags
>set treated as a withdrawal, while it is ignored for the case when both
>the P and B flags are clear?
>
>I agree both should be treated as a withdrawal, I will change the text.²
>
>
>[JORGE] Sami, please correct this:
>
>³If the PE receives a route with both B and P
>   clear, it MUST treat the route as a withdrawal from the sender PE.²
>
>As you have in the following paragraph, flags P=B=0 is perfectly valid:
>
>³In multihoming single-active scenario for a given VPWS service
>   instance, the DF election should result in the Primary-elected PE for
>   the VPWS service instance advertising the P Flag set and the B Flag
>   clear, the Backup elected PE should advertise the P Flag clear and
>   the B Flag set, and the rest of the PEs in the same ES should
>signal
>   both P and B Flags clear.²

Yes - but during DF election, you¹d want the former Primary or Backup
advertisement to relinquish their respective roles. Now, there a multiple
ways this could be accomplished and the -11 version on using the last
advertised Primary or Backup should also result in the correct behavior.
However, withdrawal would assure DF convergence as well as provide
consistent behavior for both P and B Flags set and P and B Flags clear.

Thanks,
Acee 




>
>
>Let me know if I¹m missing something please. Don¹t want to hold the
>progress, but this is important.
>Thank you.
>Jorge
>
>
>
>On 3/12/17, 8:24 PM, "Sami Boutros" <sbout...@vmware.com> wrote:
>
>Hi Acee,
>
>Please find attached document with all comments addresses, if all
>good will 
>Submit before the cut-off tomorrow.
>
>Please see comments inline.
>On 3/12/17, 11:36 AM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>
>
>>Hi Sami, 
>>
>>I think this version reads much better. I still have a couple
>comments and
>>questions. 
>>
>>  1. Why is receiving an extended community with both the P and B
>flags
>>set treated as a withdrawal, while it is ignored for the case when
>both
>>the P and B flags are clear?
>
>I agree both should be treated as a withdrawal, I will change the
>text.
>
>>  2. A related question is if a route with both the P and B flags
>clear is
>>ignored, won¹t this break DF election described on the bottom of
>page 8?
>>It says ³the rest of the PEs in the same ES should single both the P
>and B
>>Flags clear.²
>
>The DF election is between the PE(s) attached to the ES and has
>nothing to do 
>With the remote PE receiving the routes from the PE(s) attached to
>the ES.
>The remote PE expect to receive one route with P Flag set and another
>route 
>With with B flag set from another PE, all other routes received from
>other PE(s) 
>Attached to the same ES are not needed, and hence can be treated as
>withdrawal
>Of previous routes from those Pe(s).
>
>> 
>>  3. Also, during DF election, is it implementation specific which
>backup
>>is chosen if multiple PEs advertise the B Flag set in their
>respective
>>extended communities?
>
>The DF election MUST always result in one Backup and One primary,
>however 
>During transit more than one route with P or B Flags can be received.
>
>>Why isn¹t it the last one similar to the primary PE
>>selection?
>
>Ok, to be consistent, will change the text to have the remote PE
>select the 
>last advertising backup PE.
>
>> 
>>  4. Both VID and VLAN ID are used in the document. I didn¹t
>research this
>>but from the context it appears these are synonymous. If VID is
>used, I¹d
>>also add it to the ³Terminology² in 1.1.
>
>Ok.
>>
>>  A few more Nits:
>>*** draft-ietf-bess-evpn-vpws-11.txt.orig 2017-03-12
>13:56:46.0
>>-0400
>>--- draft-ietf-bess-evpn-vpws-11.txt  2017-03-12 14:34:06.0
>-0400
>>***
>>*** 153,163 
>> instance. As with the Ethernet Tag in standard EVPN, the VPWS
>service
>> instance identifier has uniqueness within an EVPN instance.
>>  
>>!For EVPN routes, the Ethernet Tag ID are set to zero for
>Port-based,
>>!VLAN-based, and VLAN-bundle inter

Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

[Acee Lindem (acee)]

Hi Sami, 
This version satisfies all my comments.
Thanks,
Acee


On 3/12/17, 2:36 PM, "BESS on behalf of Acee Lindem (acee)"
<bess-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>Hi Sami, 
>
>I think this version reads much better. I still have a couple comments and
>questions. 
>
>  1. Why is receiving an extended community with both the P and B flags
>set treated as a withdrawal, while it is ignored for the case when both
>the P and B flags are clear?
>  2. A related question is if a route with both the P and B flags clear is
>ignored, won’t this break DF election described on the bottom of page 8?
>It says “the rest of the PEs in the same ES should single both the P and B
>Flags clear.” 
>  3. Also, during DF election, is it implementation specific which backup
>is chosen if multiple PEs advertise the B Flag set in their respective
>extended communities? Why isn’t it the last one similar to the primary PE
>selection? 
>  4. Both VID and VLAN ID are used in the document. I didn’t research this
>but from the context it appears these are synonymous. If VID is used, I’d
>also add it to the “Terminology” in 1.1.
>
>  A few more Nits:
>*** draft-ietf-bess-evpn-vpws-11.txt.orig  2017-03-12 13:56:46.0
>-0400
>--- draft-ietf-bess-evpn-vpws-11.txt   2017-03-12 14:34:06.0 -0400
>***
>*** 153,163 
> instance. As with the Ethernet Tag in standard EVPN, the VPWS service
> instance identifier has uniqueness within an EVPN instance.
>  
>!For EVPN routes, the Ethernet Tag ID are set to zero for Port-based,
>!VLAN-based, and VLAN-bundle interface mode and it is set to non-zero
>!Ethernet tag ID for VLAN-aware bundle mode. Conversely, for EVPN-
> VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a
>!non-zero value for all four  service interface types.
>  
> In terms of route advertisement and MPLS label lookup behavior, EVPN-
> VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when
>--- 153,163 
> instance. As with the Ethernet Tag in standard EVPN, the VPWS service
> instance identifier has uniqueness within an EVPN instance.
>  
>!For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based,
>!VLAN-based, and VLAN-bundle interface mode and set to non-zero
>!Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN-
> VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a
>!non-zero value for all four service interface types.
>  
> In terms of route advertisement and MPLS label lookup behavior, EVPN-
> VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when
>***
>*** 181,188 
> Ethernet frames are transported as is and the tags are not altered.
>  
> The MPLS label value in the Ethernet A-D route can be set to the
>!VXLAN Network Identifier (VNI) for VxLAN encap, and this VNI may have
>!a global scope or local scope per PE and may also be made equal to
> the VPWS service instance identifier set in the Ethernet A-D route.
>  
> The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI
>--- 181,188 
> Ethernet frames are transported as is and the tags are not altered.
>  
> The MPLS label value in the Ethernet A-D route can be set to the
>!VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may have
>!a global scope or local scope per PE and may also be equal to
> the VPWS service instance identifier set in the Ethernet A-D route.
>  
> The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI
>***
>*** 312,321 
>  
>  2.3 VLAN-Aware Bundle Service Interface
>  
>!Contrary to EVPN, in EVPN-VPWS this service interface maps to VLAN-
> based service interface (defined in section 2.1) and thus this
> service interface is not used in EVPN-VPWS.  In other words, if one
>!tries to define data-plane and control plane behavior for this
> service interface, one would realize that it is the same as that of
> VLAN-based service.
>  
>--- 312,321 
>  
>  2.3 VLAN-Aware Bundle Service Interface
>  
>!Contrary to EVPN, in EVPN-VPWS this service interface maps to a VLAN-
> based service interface (defined in section 2.1) and thus this
> service interface is not used in EVPN-VPWS.  In other words, if one
>!tries to define data plane and control plane behavior for this
> service interface, one would realize that it is the same as that of
> VLAN-based service.
>  
>***
>*** 326,332 
> signal VPWS services. The Ethernet Segment Identifier field is set to
> the custom

Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

[Acee Lindem (acee)]

 be set to
 the VPWS service instance identifier value. The VPWS service instance
!identifier value MAY be set to a 24-bit value and when a 24-bit value
is
 used, it MUST be right aligned. For both EPL and EVPL services using
 a given VPWS service instance, the pair of PEs instantiating that
 VPWS service instance will each advertise a per-EVI Ethernet A-D
***
*** 354,361 
  
  3.1 EVPN Layer 2 attributes extended community
  
!This draft proposes a new extended community [RFC4360], to be
!included with the per-EVI Ethernet A-D route. This attribute is
 mandatory if multihoming is enabled.
  
  ++
--- 354,361 
  
  3.1 EVPN Layer 2 attributes extended community
  
!This document defines an extended community [RFC4360], to be
!included with per-EVI Ethernet A-D routes. This attribute is
 mandatory if multihoming is enabled.
  
  ++
***
*** 423,429 
  
 In a multihoming all-active scenario, there is no DF election, and
 all the PEs in the ES that are active and ready to forward traffic
!to/from the CE will set the P Flag. A remote PE will do per-flow load
 balancing to the PEs that set the P Flag for the same Ethernet Tag
 and ESI. The B Flag in control flags SHOULD NOT be set in the
 multihoming all-active scenario and MUST be ignored by receiving
--- 423,429 
  
 In a multihoming all-active scenario, there is no DF election, and
 all the PEs in the ES that are active and ready to forward traffic
!to/from the CE will set the P Flag. A remote PE will do per-flow load-
 balancing to the PEs that set the P Flag for the same Ethernet Tag
 and ESI. The B Flag in control flags SHOULD NOT be set in the
 multihoming all-active scenario and MUST be ignored by receiving
***
*** 493,499 
  
 All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI
 Ethernet A-D routes, one route per VPWS service instance.  For inter-
!AS option B, the ASBRs re-advertise these routes with NEXT_HOP
 attribute set to their IP addresses as per [RFC4271]. The link
 between the CE and the PE is either a C-tagged or S-tagged interface,
 as described in [802.1Q], that can carry a single VLAN tag or two
--- 493,499 
  
 All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI
 Ethernet A-D routes, one route per VPWS service instance.  For inter-
!AS option B, the ASBRs re-advertise these routes with the NEXT_HOP
 attribute set to their IP addresses as per [RFC4271]. The link
 between the CE and the PE is either a C-tagged or S-tagged interface,
 as described in [802.1Q], that can carry a single VLAN tag or two
***
*** 570,576 
 Finally, EVPN may employ data plane egress link protection mechanisms
 not available in VPWS. This can be done by the primary PE (on local
 AC down) using the label advertised in the per-EVI Ethernet A-D route
!by the backup PE to encapsulate the traffic and direct it to backup
 PE.
  
  6 Failure Scenarios
--- 570,576 
 Finally, EVPN may employ data plane egress link protection mechanisms
 not available in VPWS. This can be done by the primary PE (on local
 AC down) using the label advertised in the per-EVI Ethernet A-D route
!by the backup PE to encapsulate the traffic and direct it to the
backup
 PE.
  
  6 Failure Scenarios
***
*** 592,600 
 For a faster convergence in multi-homed scenarios with either Single-
 Active Redundancy or All-active redundancy, a mass withdraw technique
 is used. A PE previously advertising a per-ES Ethernet A-D route, can
!withdraw this route signaling to the remote PEs to switch all the
 VPWS service instances associated with this multi-homed ES to the
!backup PE
  
  7 Acknowledgements
  
--- 592,600 
 For a faster convergence in multi-homed scenarios with either Single-
 Active Redundancy or All-active redundancy, a mass withdraw technique
 is used. A PE previously advertising a per-ES Ethernet A-D route, can
!withdraw this route by signaling to the remote PEs to switch all the
 VPWS service instances associated with this multi-homed ES to the
!backup PE.
  
  7 Acknowledgements


  

Thanks,
Acee




On 3/9/17, 9:50 PM, "Sami Boutros" <sbout...@vmware.com> wrote:

>Hi Acee,
>
>Please find attached the -11 version, I addressed most of your edits
>below.
>
>Thanks,
>
>Sami
>
>
>
>On 3/3/17, 8:30 AM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>
>>Hello,
>>
>>
>>
>>I have been selected as the Routing Directorate reviewer for this draft.
>>
>>The Routing Directorate seeks to review all routing or routing-related
>>
>>drafts as the

Re: [bess] BGP common parameter Yang module

[Acee Lindem (acee)]

Hi Dhanendra,

From: "Dhanendra Jain (dhjain)" <dhj...@cisco.com<mailto:dhj...@cisco.com>>
Date: Tuesday, February 14, 2017 at 4:12 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Xufeng Liu 
<xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>>, "Patrice 
Brissette (pbrisset)" <pbris...@cisco.com<mailto:pbris...@cisco.com>>, Jeff 
Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>, 'Giles 
Heron' <giles.he...@gmail.com<mailto:giles.he...@gmail.com>>
Cc: 
"draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>"
 
<draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
Himanshu Shah <hs...@ciena.com<mailto:hs...@ciena.com>>
Subject: Re: [bess] BGP common parameter Yang module

Hi Acee,

From: "Acee Lindem (acee)" <a...@cisco.com<mailto:a...@cisco.com>>
Date: Tuesday, February 14, 2017 at 12:51 PM
To: Cisco Employee <dhj...@cisco.com<mailto:dhj...@cisco.com>>, Xufeng Liu 
<xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>>, "Patrice 
Brissette (pbrisset)" <pbris...@cisco.com<mailto:pbris...@cisco.com>>, 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>, 'Giles 
Heron' <giles.he...@gmail.com<mailto:giles.he...@gmail.com>>
Cc: 
"draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>"
 
<draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"'Shah, Himanshu'" <hs...@ciena.com<mailto:hs...@ciena.com>>
Subject: Re: [bess] BGP common parameter Yang module

See inline.

From: "Dhanendra Jain (dhjain)" <dhj...@cisco.com<mailto:dhj...@cisco.com>>
Date: Tuesday, February 14, 2017 at 3:45 PM
To: Xufeng Liu <xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Patrice Brissette 
(pbrisset)" <pbris...@cisco.com<mailto:pbris...@cisco.com>>, Jeff Tantsura 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>, 'Giles Heron' 
<giles.he...@gmail.com<mailto:giles.he...@gmail.com>>
Cc: 
"draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>"
 
<draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
Himanshu Shah <hs...@ciena.com<mailto:hs...@ciena.com>>
Subject: Re: [bess] BGP common parameter Yang module

Hi Xefeng,

From: Xufeng Liu <xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>>
Date: Tuesday, February 14, 2017 at 11:44 AM
To: Cisco Employee <dhj...@cisco.com<mailto:dhj...@cisco.com>>, "Acee Lindem 
(acee)" <a...@cisco.com<mailto:a...@cisco.com>>, "Patrice Brissette (pbrisset)" 
<pbris...@cisco.com<mailto:pbris...@cisco.com>>, 'Jeff Tantsura' 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>, 'Giles Heron' 
<giles.he...@gmail.com<mailto:giles.he...@gmail.com>>
Cc: 
"draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>"
 
<draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"'Shah, Himanshu'" <hs...@ciena.com<mailto:hs...@ciena.com>>
Subject: RE: [bess] BGP common parameter Yang module

Hi Dhanendra,

More below.
Thanks,

- Xufeng

From: Dhanendra Jain (dhjain) [mailto:dhj...@cisco.com]
Sent: Tuesday, February 14, 2017 2:27 PM
To: Xufeng Liu <xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>>; 
Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Patrice Brissette 
(pbrisset) <pbris...@cisco.com<mailto:pbris...@cisco.com>>; 'Jeff Tantsura' 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Giles Heron' 
<giles.he...@gmail.com<mailto:giles.he...@gmail.com>>
Cc: 
draft-ietf-rtgwg-routing-ty...@ietf.org<mailto:draft-ietf-rtgwg-routing-ty...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; 'Shah, Himanshu' 
<hs...@ciena.com<mailto:hs...@ciena.com>>
Subject: Re: [bess] BGP common parameter Yang module

Hi Xufeng,

inline..

From

Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04

[Acee Lindem (acee)]

Support.
Thanks,
Acee 

On 2/13/17, 5:07 PM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-evpn-prefix-advertisement-04 [1] which is considered
>mature and ready for a final working group review.
>Note that this call is longer than usual because we are pushing two
>correlated documents together.
>
>Please read this document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*5th of March*.
>Note that this is *not only* a call for comments on the document; it is
>also a call for support (or not) to publish this document as a Proposed
>Standard RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-evpn-prefix-advertisement, 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 a document author or contributor of
>draft-ietf-bess-evpn-prefix-advertisement-04 please respond to this
>email and indicate whether or not you are aware of any relevant IPR.
>
>Note that, as of today, no IPR has been disclosed against this document
>or its earlier versions.
>
>We are also polling for knowledge of implementations of part or all of
>what this document specifies. This information is expected as per [2].
>Please inform the mailing list, or the chairs, or only one of the chairs.
>
>Thank you,
>M
>
>[1] 
>https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement
>/
>[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>___
>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] BGP common parameter Yang module

[Acee Lindem (acee)]

Hi Giles,
I will add the route-target-type type (enum of import, export, both) but for a 
general grouping, it appears there are some discrepancies between the 3 models. 
Assuming the types: route-discriminator, route-target, and route-target-type, 
can you provide a consensus grouping that all the models would use?
Thanks,
Acee

From: Giles Heron <giles.he...@gmail.com<mailto:giles.he...@gmail.com>>
Date: Friday, February 10, 2017 at 11:18 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "Patrice Brissette (pbrisset)" 
<pbris...@cisco.com<mailto:pbris...@cisco.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
Himanshu Shah <hs...@ciena.com<mailto:hs...@ciena.com>>, "Dhanendra Jain 
(dhjain)" <dhj...@cisco.com<mailto:dhj...@cisco.com>>
Subject: Re: [bess] BGP common parameter Yang module

Hi Acee,

In general seems that for any BGP VPN (L2 or L3) you have an RD plus a list of 
RTs (which can be import, export or both) - so I'd prefer that to be defined in 
a shared grouping (more or less as per the structure Patrice gave below) than 
to force each model to redefine it.

Giles

On 10 Feb 2017, at 14:51, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Patrice - we are working fervently on a common IETF routing types model. We 
have both route-target and router-distinguisher types defined there. The work 
is being done in the Routing WG. Our intension is to accelerate standardization 
so it doesn't hold up standardization of the importing modules. Please comment 
as to whether you think this meets BESS requirements.

https://www.ietf.org/id/draft-ietf-rtgwg-routing-types-00.txt

Thanks,
Acee
P.S. We plan an update next week but the RD and RT definitions have not changed.



From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Patrice Brissette (pbrisset)" <pbris...@cisco.com<mailto:pbris...@cisco.com>>
Date: Friday, February 10, 2017 at 9:26 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Cc: "Dhanendra Jain (dhjain)" <dhj...@cisco.com<mailto:dhj...@cisco.com>>, 
Himanshu Shah <hs...@ciena.com<mailto:hs...@ciena.com>>
Subject: [bess] BGP common parameter Yang module

Folks,

As part of EVPN, L2VPn and L3VPN Yang model, there is a "module" common to all 
3 Yang models.

  | +--rw bgp-parameters
  | |  +--rw common
  | | +--rw rd-rt* [route-distinguisher]
  | |+--rw route-distinguisherstring
  | |+--rw vpn-target* [rt-value]
  | |   +--rw rt-valuestring
  | |   +--rw rt-type bgp-rt-type


It will be interesting to create a common BGP parameter Yang module as shown 
above. I think it just makes sense.
However, there is a minor challenge; that module require a home (a draft).
I'm looking for feedback about the best place/draft for such a module.

Thanks for your help.
Regards,
Patrice Brissette
___
BESS mailing list
BESS@ietf.org<mailto: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] BGP common parameter Yang module

[Acee Lindem (acee)]

Hi Patrice - we are working fervently on a common IETF routing types model. We 
have both route-target and router-distinguisher types defined there. The work 
is being done in the Routing WG. Our intension is to accelerate standardization 
so it doesn't hold up standardization of the importing modules. Please comment 
as to whether you think this meets BESS requirements.

https://www.ietf.org/id/draft-ietf-rtgwg-routing-types-00.txt

Thanks,
Acee
P.S. We plan an update next week but the RD and RT definitions have not changed.



From: BESS > on behalf of 
"Patrice Brissette (pbrisset)" >
Date: Friday, February 10, 2017 at 9:26 AM
To: "bess@ietf.org" >
Cc: "Dhanendra Jain (dhjain)" >, 
Himanshu Shah >
Subject: [bess] BGP common parameter Yang module

Folks,

As part of EVPN, L2VPn and L3VPN Yang model, there is a "module" common to all 
3 Yang models.

  | +--rw bgp-parameters
  | |  +--rw common
  | | +--rw rd-rt* [route-distinguisher]
  | |+--rw route-distinguisherstring
  | |+--rw vpn-target* [rt-value]
  | |   +--rw rt-valuestring
  | |   +--rw rt-type bgp-rt-type


It will be interesting to create a common BGP parameter Yang module as shown 
above. I think it just makes sense.
However, there is a minor challenge; that module require a home (a draft).
I'm looking for feedback about the best place/draft for such a module.

Thanks for your help.
Regards,
Patrice Brissette
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Fwd: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis

[Acee Lindem (acee)]

In case it is not obvious, I support MPLS WG adoption of the subject draft in 
its current form ;^). I already supported it on the MPLS list.
Thanks,
Acee

From: Idr > on behalf of Loa 
Andersson >
Date: Wednesday, August 31, 2016 at 12:28 AM
To: IDR List >, 
"bess@ietf.org" >
Subject: [Idr] Fwd: [mpls] Working Group adoption poll on 
draft-rosen-mpls-rfc3107bis

Working Groups,

Please note that the working group adoption poll for 
draft-rosen-mpls-rfc3107bis has been started in the mpls wg. Please send your 
comments to the mpls wg mailing list (m...@ietf.org).

/Loa
mpls wg co-chair

Sent from my iPhone

Begin forwarded message:

From: Loa Andersson >
Date: 30 augusti 2016 08:10:13 GMT+8
To: "m...@ietf.org" >
Cc: 
"draft-rosen-mpls-rfc3107bis@ietf.org"
 
>,
 "mpls-cha...@ietf.org" 
>
Subject: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis

Working Group,

This is to start a two week poll on adopting draft-rosen-mpls-rfc3107bis
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (m...@ietf.org). Please give a 
technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There are no IPR disclosures against this document.

All the authors has stated on the on the mpls wg mailing list that they
are not aware of any IPRs that relate to this document.

The working group adoption poll ends September 14, 2016.

/Loa

MPLS wg co-chair.
--


Loa Anderssonemail: 
l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

Re: [bess] [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

[Acee Lindem (acee)]

Hi Robert,

From: <rras...@gmail.com<mailto:rras...@gmail.com>> on behalf of Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Wednesday, August 31, 2016 at 10:40 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, IDR List 
<i...@ietf.org<mailto:i...@ietf.org>>, "m...@ietf.org<mailto:m...@ietf.org>" 
<m...@ietf.org<mailto:m...@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on 
draft-rosen-mpls-rfc3107bis

Hi Acee,

There is no issue for compatibility as new proposal has its new BGP capability 
hence there is no issue with deploying it gradually.

The current capability is specific to support of multiple labels - not your 
parochial view on the interaction between SAFIs. Are you suggesting a second 
capability? All the more reason for a separate draft.


Yes it requires new RIB work for those implementations which today use single 
RIB for both SAFI 1 and SAFI 4. FIB and LFIB are already separate. Each SAFI in 
BGP also normally has it's own separate tables. So if anything it requires a 
bit of cleanup work.

So you are saying SAFI 4 would only apply to ILM and not NHLFE when the same 
prefix is advertised in both SAFI 1 and SAFI 4? Maybe I am missing something 
but I don’t see that this is useful deployment. In any event, the non-backward 
compatible behavior you are proposing would be better served in a separate 
draft than to burden RFC 3107 BIS.


Main motivation here would be to help new vendors to make the unified choice in 
how they will implement 3107bis so long term we get some consistent way SAFI 4 
is delivered. And if now at the "bis" rfc is not a good time then what you are 
really advocating is to stay for years to come with such undefined randomness 
across implementations.

I agree with the current draft that it should be local policy. I don’t think 
you can assume that everyone agrees that this should be specified and that your 
view on how it should work is consensus. Hence, put it in a separate draft.


Other then consistency I also see folks trying to use labeled BGP as controller 
to network device protocol to install labels. For that use case alone complete 
separation from SAFI 1 is very helpful.

You have both ILM and NHLFE to consider here. I look forward to reviewing your 
draft on this topic. If there is consensus, merger with the draft under WG 
adoption can be considered.

Thanks,
Acee




Thx,
R.



On Wed, Aug 31, 2016 at 4:15 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Robert,

Currently, everything in draft-rosen-mpls-rfc3107bis is pretty much backward 
compatible with our more than a decade old RFC 3107 implementations and 
deployments. What you are proposing is not and has implications in both the 
control and forwarding planes. If you really believe that this is “the biggest 
issue", I’d suggest you articulate it in a separate draft with concrete use 
cases for having separate IP and MPLS topologies for the same set of prefixes. 
Then the WGs can evaluate the requirement and proposed solution independent of 
RFC 3107 BIS.

Thanks,
Acee

From: mpls <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>> on behalf of 
Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Wednesday, August 31, 2016 at 5:24 AM
To: Eric C Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>
Cc: IDR List <i...@ietf.org<mailto:i...@ietf.org>>, 
"m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on 
draft-rosen-mpls-rfc3107bis

Hi Eric,

While adoption call is sort of encouragement for further input before I respond 
to Loa's mail I would like to get one additional answer from 3107bis authors 
and WGs members.

Those who spend years in mpls deployment know quite well that the biggest issue 
with today's 3107 deployment is lack of the clear definition of its interaction 
with SAFI-1. While one would hope that 3107bis with new capability will clean 
this mess section 5 of your document rather sweeps it all under the carpet 
stating that it is just local policy. IMO it is not a matter of local policy 
nor it is implementation detail.

Local policy can be to choose which RIB (or sequence of RIBs) should be used 
for resolution of specific SAFIs and not how to mix SAFI-1 with SAFI-4. It's 
not a local matter at all to have deployment resulting in inconsistent IBGP 
best paths across given domain.

To me cleanest is to separate those two SAFIs completely from each other 

Re: [bess] [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

[Acee Lindem (acee)]

Hi Robert,

Currently, everything in draft-rosen-mpls-rfc3107bis is pretty much backward 
compatible with our more than a decade old RFC 3107 implementations and 
deployments. What you are proposing is not and has implications in both the 
control and forwarding planes. If you really believe that this is “the biggest 
issue", I’d suggest you articulate it in a separate draft with concrete use 
cases for having separate IP and MPLS topologies for the same set of prefixes. 
Then the WGs can evaluate the requirement and proposed solution independent of 
RFC 3107 BIS.

Thanks,
Acee

From: mpls > on behalf of 
Robert Raszuk >
Date: Wednesday, August 31, 2016 at 5:24 AM
To: Eric C Rosen >
Cc: IDR List >, 
"m...@ietf.org" >, 
"bess@ietf.org" >
Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on 
draft-rosen-mpls-rfc3107bis

Hi Eric,

While adoption call is sort of encouragement for further input before I respond 
to Loa's mail I would like to get one additional answer from 3107bis authors 
and WGs members.

Those who spend years in mpls deployment know quite well that the biggest issue 
with today's 3107 deployment is lack of the clear definition of its interaction 
with SAFI-1. While one would hope that 3107bis with new capability will clean 
this mess section 5 of your document rather sweeps it all under the carpet 
stating that it is just local policy. IMO it is not a matter of local policy 
nor it is implementation detail.

Local policy can be to choose which RIB (or sequence of RIBs) should be used 
for resolution of specific SAFIs and not how to mix SAFI-1 with SAFI-4. It's 
not a local matter at all to have deployment resulting in inconsistent IBGP 
best paths across given domain.

To me cleanest is to separate those two SAFIs completely from each other by the 
spec both in BGP (done) as well as local RIB and FIB/LFIB.

Likewise I do not quite agree that SAFI-4 should be "convertible" to SAFI-1. 
And we all realize that opposite direction is rather hard.

Another perhaps minor clarification would be to get an explicit confirmation 
that SAFI-4 can be recursive over SAFI-4 or for that matter SAFI-1 (MPLS in GRE 
or SR in IP).

Thx,
R.

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

Re: [bess] [mpls] Question raised in the MPLS-RT review of draft-rosen-mpls-rfc3107bis

[Acee Lindem (acee)]

Hi Loa, et al, 

Since I commented on the MPLS-RT review with respect to the IDR-specific
content, there may be some confusion as to where I stand on the ownership
of this draft. I’ve reviewed this document and agree with the approach
described below. I’m convinced we will get the right level cross-WG review
along as we recognize that it does span multiple WGs. I would expect that
we’ll have implementations conforming to the draft in the near future.

Thanks,
Acee

On 8/17/16, 1:36 PM, "mpls on behalf of Loa Andersson"
 wrote:

>Eric, et.al., (copied also idr-chairs and idr-list + bess-chairs and
>bess-list)
>
>For those of you that are not subscribed to the mpls-list.
>
>- the mpls wg has started the initial steps for working group adoption,
>   there are three steps
>   -- mpls-rt review (what you see below is the follow-up discussion on
>  that review)
>   -- IPR poll, will be sent out soon
>   -- working group adoption poll (wgap), that poll will be copied to
>  the idr and bess. Hopefully we can that shortly.
>
>I'm sending this to mpls, idr and bess working group, since it has
>to do where things should be documented.
>
>
>On 2016-08-17 17:59, Eric C Rosen wrote:
>> Hi Mach,
>>
>> Thanks for your review.
>>
>> On 8/3/2016 4:51 AM, Mach Chen wrote:
>>> I have only one comment regarding to Section 5. IMHO, although it's
>>> informational, the description about the relationship between SAFI-1
>>> and SAFI-4 routes should not belong to this document, it's a more
>>> common description that is not specific to this label binding process.
>>> I'd suggest to remove this section if there is no any other reasons.
>>
>> Differing interpretations about the relationship between SAFI-1 and
>> SAFI-4 are a very common source of interoperability problems among
>> implementations of different vendors.  Thus I think it is very useful to
>> document this issue and to call attention to some of the differing
>> interpretations.  I think this document is an appropriate place for this
>> information; even though this information is not about label binding, it
>> is about the semantics of SAFI-4.
>
>I agree that this needs to be documented! I can accept that it is done
>in draft-rosen-mpls-rfc3107bis, but I would like to have all three wg's
>agree to this. I see a few alternatives
>
>- we could document this is in draft-rosen-mpls-rfc3107bis; or
>- we could write a separate document
>- we could find another document where this has a better fit than in
>   draft-rosen-mpls-rfc3107bis
>- any other suggestion
>
>Let us know if you have an opinion.
>
>Please send your responses to the mpls wg mailing list (m...@ietf.org).
>
>/Loa
>mpls wg-co-chair
>
>>
>> Eric
>
>-- 
>
>
>Loa Anderssonemail: l...@mail01.huawei.com
>Senior MPLS Expert  l...@pi.nu
>Huawei Technologies (consultant) phone: +46 739 81 21 64
>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

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

Re: [bess] [Idr] draft-rosen-mpls-rfc3107bis

[Acee Lindem (acee)]

Hi Robert,

I think this would defeat the purpose of clarifying RFC 3101 multi-label 
behavior in a BIS draft. Let’s see if we can reach consensus first.

Thanks,
Acee

From: Idr > on behalf of 
Robert Raszuk >
Date: Friday, April 1, 2016 at 4:23 PM
To: Eric C Rosen >
Cc: Bruno Decraene 
>, 
"m...@ietf.org" >, 
BESS >, IDR List 
>
Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis

Hi Eric,

I have read your proposed draft as well as watched this thread with a bit of an 
interest.

To me the best compromise - which is to agree with Bruno's points as well as 
address your intentions is simply to request new SAFI for 3107bis.

From the draft you are really not updating 3107 base spec but obsoleting it 
which to me looks like a bad idea.

You are even requesting to remove IANA reference to original spec. How would 
IANA know when is it safe to do that .. meaning when all implementations will 
not suddenly support and all deployments will enable 3107bis ?

New SAFI requires a new capability which you are asking for anyway.

As far as implementations please keep in mind very important point that some 
implementations treat SAFI 1 & 4 in single table and some in separate tables. 
That when mixed with 3107bis may just explode if not in new set of bugs then 
with operational nightmare. While we are at this it would be much cleaner to 
mandate in the new spec to have 3107bis always to use separate tables as 
compared with from SAFI 1.

Thx,
Robert.

PS.

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very well 
stated that this is only one deployment option for interdomain encapsulation. I 
would very much like to see a section indicating that IPv6 or/and IPv4 be used 
as an alternative encap for those applications which require it and when needed 
provide local bindings between intradomain MPLS and interdomain IP.


On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen 
> wrote:
On 3/25/2016 7:25 AM, 
bruno.decra...@orange.com wrote:
I'm quite sure you have deployed  implementations, from several
prominent vendors, that will not properly handle this case.
I'm waiting for this/these implementation(s) to make a public statement in this 
thread / IETF WGs. Then we can discuss whether the issue comes from RFCF3107 or 
from the implementation.
If none make a public statement, we should assume that all implementations are 
capable of receiving multiple labels, as per RFC 3107.
I strongly disagree with this.  We should not ignore the facts just because you 
don't like the way the facts were gathered.

A better approach would be to have operators state whether they have any 
deployments in which the "multiple labels" feature is used in a multi-vendor 
environment.  It is very useful when working on a "bis" draft to determine 
which features have been proven to work in a multi-vendor environment and which 
have not.

Any non-compliant implementation may create interoperability issues and 
unpredictable results.
 From an IETF standpoint, the question is whether a RFC 3107 implementation 
would create interoperability issues, up to shutting down the BGP session.

There are deployed 3107 implementations which always assume that the NLRI 
contains a single label.  If you tried to interwork these with 3107 
implementations that send multiple labels , you will experience the kind of 
disruption.  3107bis tries to allow the use of multiple labels while preventing 
this sort of disruption from occurring.

If you mean that some non-compliant implementation do not work, well let's fix 
them.

The situation is that there is a commonly deployed "bug" in old 
implementations, but it is not seen because the bug is in a feature that no one 
has been using.  If new implementations use that feature, the bug will be seen, 
and network disruption will occur. One could say "fix all the old 
implementations", but it seems wiser to have new implementations avoid tickling 
the bug.   The Capability is not proposed  for the purpose of helping the 
vendors, it's there to help the operators.

I'm not sure why you think there would be BGP session drops due to 3107bis; if 
a 3107 implementation sends multiple labels to a 3107bis implementation, I 
think the 3107bis implementation would do "treat-as-withdraw" rather than "drop 
the session".

Perhaps a reasonable approach for 3107bis would be the following:

- A 3107bis implementation will not send multiple labels to a peer unless the 
Capability has been received from that peer.  (This prevents 3107bis 
implementations from tickling the 'bug' in 3107 implementations.)

- A 3107bis