Re: [bess] [pim] Adoption call: draft-zhao-pim-evpn-multicast-yang in pim

[zhang.zheng]

Support the adoption. 
Best regards,
Sandy











Original


From: MichaelMcBride 
To: p...@ietf.org ;bess@ietf.org ;
Date: 2024年01月05日 06:40
Subject: [pim] Adoption call: draft-zhao-pim-evpn-multicast-yang in pim


___
pim mailing list
p...@ietf.org
https://www.ietf.org/mailman/listinfo/pim

 

Happy New Year,
 
Today begins a two week adoption call for 
https://datatracker.ietf.org/doc/draft-zhao-pim-evpn-multicast-yang/ in the pim 
wg. This document describes a yang data model for evpn multicast services hence 
adding bess to the call for adoption. Our poll in Prague was 8 in favor and 1 
against.
 
Please review and comment.
 
Thanks,
mike
 
 


From: BESS  On Behalf Of Michael McBride
 Sent: Monday, November 6, 2023 11:28 PM
 To: bess@ietf.org
 Subject: [bess] draft-zhao-pim-evpn-multicast-yang in pim



 
Hello bess,
 
We will have draft-zhao-pim-evpn-multicast-yang presented in pim tomorrow. 
Hongji has presented this draft a few times in pim because he hasn’t been able 
to get time in bess and we have progressed several of his other yang drafts in 
pim. It was suggested that we consider adopting in pim since bess is extremely 
busy. So just a heads up that we will take an adoption poll tomorrow per his 
request. We have discussed with bess chairs. Please review the draft.
 
Thanks, 
mike___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Appointment of additional WG Chair

[zhang.zheng]

Congratulations Jeffrey!






Best regards,


Sandy







Original



From: AndrewAlston-IETF 
To: bess@ietf.org ;
Cc: bess-cha...@ietf.org ;
Date: 2023年08月04日 10:45
Subject: [bess] Appointment of additional WG Chair


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

 

Hi WG,


 


Following consultation with Matt and Stephane I have opted to appoint a third 
chair to BESS to provide additional coverage considering the document working 
load through the working group.


 


As such, I would like to welcome Jeffery Zhang as the third chair to BESS and 
to thank him for his willingness to take up the position.  I believe Jeffrey 
will be a solid addition to the team.


 


Thanks


 


Andrew Alston


Routing Area Director


 



 
Internal All Employees___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[zhang.zheng]

Support the adoption.


Thanks,


Sandy





原始邮件



发件人：Bocci,Matthew(Nokia-GB)
收件人：draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org;bess@ietf.org;
日 期 ：2021年04月13日 17:37
主 题 ：[bess] WG Adoption and IPR Poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03




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

 

Hello,


 


This email begins a two-weeks WG adoption poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1].


 


Please review the draft and post any comments to the BESS working group list.


 


We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


 


If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.


 


Currently, there are no IPR disclosures against this document.


 


If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.


 


This poll for adoption closes on April 27th 2021.


 


Regards,


Matthew and Stephane


 


 


[1] 
https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[zhang.zheng]

Hi Tony, 


Thank you very much for your explaining! 


I got it. The auto evpn function includes it but the aim is not it.


Much appreciate if you may respond my further comments in my previous email. 


Best regards,


Sandy





原始邮件



发件人：AntoniPrzygienda
收件人：张征7940;Jordan Head;Wen Lin;
抄送人：bess@ietf.org;r...@ietf.org;
日 期 ：2021年03月12日 16:07
主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00




___
RIFT mailing list
r...@ietf.org
https://www.ietf.org/mailman/listinfo/rift

 

Sandy, if you want to see it that way, yepp, you can think of one of the things 
AUTO EVPN does as “BGP peer auto-configuration”. This is however just a small 
part of the overall and really just kind of “necessary byproduct”, especially 
since the sessions to RR can go multi-hop so even with bgp single-hop discovery 
BGP couldn’t figure it out itself. (Yes, there was work done previously for RR 
autodiscovery in IGP AFAIR, I don’t think I ever saw it deployed).


 


--- tony


 


 



From: "zhang.zh...@zte.com.cn" 
 Date: Friday, 12 March 2021 at 05:01
 To: Antoni Przygienda , Jordan Head , Wen 
Lin 
 Cc: "r...@ietf.org" , "bess@ietf.org" 
 Subject: Re:[Rift] comments on draft-head-rift-auto-evpn-00



 



[External Email. Be cautious of content]


 

Hi Tony, 

Thank you for your response! It's interesting. 

So in some sense, the BGP auto discovery can be achieved by RIFT own way, in 
this situration, right? 

Please find more comments below with Sandy>.

Best regards,

Sandy


原始邮件



发件人：AntoniPrzygienda



收件人：张征7940;Jordan Head;Wen Lin;



抄送人：r...@ietf.org;bess@ietf.org;



日 期 ：2021年03月10日 23:45



主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00




Hey Sandy, yes, all sessions come up automatically


 


Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)


Sandy> Most of the info is topology info, but some may not, such as AS number. 
But I agree with you, it can be a small option to be added in the existed TIE 
or a new TIE.



 
 


There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today


Sandy> I have a question, If ToF is RR, does it need to establish BGP peering 
with leaf nodes?


 


KV  will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.


Sandy> OK. I understand.


 


In short:


 


RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference


 


X::[pref]


 


Every leaf tries to connect to


 


X::1


X::2


X::3


 


Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable 
constant)


 


Each leaf elects own loopback in a well known range


Sandy> It's a reasonable design. For multiple RIFT instances, if multiple EVPN 
overlays can be built? Will they use the same well know range loopback address?


 


Y/64 :: something


 


On each RR any connection attempt from Y/64:: something is accepted (pretty 
much all mature implemenations today support that). If you want to be 
fastidious you could actually on the ToF that is RR (since it sees all node 
N-TIEs) even specify each leaf as allowed peer


Sandy> Do you mean the RR (ToF) is optional, leaf nodes can build BGP peering 
straightly?


 


All took a bit to figure out and my first input to the idea when brought to me 
was “well, of course it’s impossible to ZTP EVPN, even with RIFT”  But, with 
enough grey matter grease it actually works pretty well from all we see …


 


It will all become more concrete when we flesh the algorithm appendix albeit 
the description today already gives a pretty good idea but without standardized 
algorithms for the distributed elections interoperability cannot be guaranteed …


Sandy> Sound great. Looking forward to looking at it.


 


--- tony


 



From: "zhang.zh...@zte.com.cn" 
 Date: Wednesday, 10 March 2021 at 16:31
 To: Antoni Przygienda , Jordan Head , Wen 
Lin 
 Cc: "r...@ietf.org" 
 Subject: [Rift] comments on draft-head-rift-auto-evpn-00



 


[External Email. Be cautious of content]


 

Hi Tony, co-author, 

Thank for your presentation in RIFT and BESS WG.

I have question about the intent of this draft, before I read more on the 
detail. :-P

From the draft, seems like the leaf node will build BGP connection 
automatically, and exchange the necessary MAC/IP through EVPN advertisement. 

But does the info on leaf for BGP building (AS, router-id, etc.) derived from 
the leaf node itself? If it is, the BGP auto discovery function is included in 
(That is also the confusion from BESS WG).

If the info for BGP building on leaf comes from the TOF nodes (RR), then it has 
no relationship with BGP auto discovery, IMO necessary sourcebound KVs are 
needed. But I am not sure because I have 

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[zhang.zheng]

Hi Tony, 


Thank you for your response! It's interesting. 


So in some sense, the BGP auto discovery can be achieved by RIFT own way, in 
this situration, right? 


Please find more comments below with Sandy>.



Best regards,


Sandy



原始邮件



发件人：AntoniPrzygienda
收件人：张征7940;Jordan Head;Wen Lin;
抄送人：r...@ietf.org;bess@ietf.org;
日 期 ：2021年03月10日 23:45
主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00




Hey Sandy, yes, all sessions come up automatically


 


Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)


Sandy> Most of the info is topology info, but some may not, such as AS number. 
But I agree with you, it can be a small option to be added in the existed TIE 
or a new TIE.






There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today


Sandy> I have a question, If ToF is RR, does it need to establish BGP peering 
with leaf nodes?


 


KV  will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.


Sandy> OK. I understand.


 


In short:


 


RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference


 


X::[pref]


 


Every leaf tries to connect to


 


X::1


X::2


X::3


 


Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable 
constant)


 


Each leaf elects own loopback in a well known range


Sandy> It's a reasonable design. For multiple RIFT instances, if multiple EVPN 
overlays can be built? Will they use the same well know range loopback address?


 


Y/64 :: something


 


On each RR any connection attempt from Y/64:: something is accepted (pretty 
much all mature implemenations today support that). If you want to be 
fastidious you could actually on the ToF that is RR (since it sees all node 
N-TIEs) even specify each leaf as allowed peer


Sandy> Do you mean the RR (ToF) is optional, leaf nodes can build BGP peering 
straightly?


 


All took a bit to figure out and my first input to the idea when brought to me 
was “well, of course it’s impossible to ZTP EVPN, even with RIFT”  But, with 
enough grey matter grease it actually works pretty well from all we see …


 


It will all become more concrete when we flesh the algorithm appendix albeit 
the description today already gives a pretty good idea but without standardized 
algorithms for the distributed elections interoperability cannot be guaranteed …


Sandy> Sound great. Looking forward to looking at it.


 


--- tony


 



From: "zhang.zh...@zte.com.cn" 
 Date: Wednesday, 10 March 2021 at 16:31
 To: Antoni Przygienda , Jordan Head , Wen 
Lin 
 Cc: "r...@ietf.org" 
 Subject: [Rift] comments on draft-head-rift-auto-evpn-00



 


[External Email. Be cautious of content]


 

Hi Tony, co-author, 

Thank for your presentation in RIFT and BESS WG.

I have question about the intent of this draft, before I read more on the 
detail. :-P

From the draft, seems like the leaf node will build BGP connection 
automatically, and exchange the necessary MAC/IP through EVPN advertisement. 

But does the info on leaf for BGP building (AS, router-id, etc.) derived from 
the leaf node itself? If it is, the BGP auto discovery function is included in 
(That is also the confusion from BESS WG).

If the info for BGP building on leaf comes from the TOF nodes (RR), then it has 
no relationship with BGP auto discovery, IMO necessary sourcebound KVs are 
needed. But I am not sure because I have not seen explicit description in the 
draft. 

Best regards,

Sandy

 

 





 
Juniper Business Use Only___
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-mvpn-evpn-aggregation-label-04

[zhang.zheng]

Support the advancement of this draft.


Thanks,


Sandy



原始邮件



发件人：slitkows.i...@gmail.com
收件人：draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org;bess@ietf.org;
抄送人：bess-cha...@ietf.org;
日 期 ：2020年12月11日 23:54
主 题 ：[bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04




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



This email starts a two-week working group last call for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [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 the 28th December 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 one IPR disclosure.


 


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-mvpn-evpn-aggregation-label/ 


[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 for draft-gmsm-bess-evpn-bfd-04

[zhang.zheng]

Support the adoption.






Thanks,


Sandy









原始邮件



发件人：Bocci,Matthew(Nokia-GB) 
收件人：draft-gmsm-bess-evpn-...@ietf.org 
;bess@ietf.org ;
抄送人：bess-cha...@ietf.org ;
日 期 ：2020年02月26日 22:42
主 题 ：[bess] WG adoption poll for draft-gmsm-bess-evpn-bfd-04




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



Hello,


 


This email begins a two-weeks WG adoption poll
 for draft-gmsm-bess-evpn-bfd-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 Wednesday 11th March 2020.  


 


Regards,


Matthew and Stephane


 


[1] https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IP poll fordraft-wsv-bess-extended-evpn-optimized-ir

[zhang.zheng]

I read this draft and support the adoption.






Thanks,


Sandy









原始邮件



发件人：slitkows.i...@gmail.com 
收件人：'BESS' ;draft-wsv-bess-extended-evpn-optimized...@ietf.org 
;
抄送人：bess-cha...@ietf.org ;
日 期 ：2020年02月04日 21:50
主 题 ：[bess] WG adoption and IP poll fordraft-wsv-bess-extended-evpn-optimized-ir




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



Hi,


 


This email begins a two-weeks WG adoption poll for 
draft-wsv-bess-extended-evpn-optimized-ir [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 18th Feb 2020.  


 


Regards,


Stephane and Matthew


 


[1] https://datatracker.ietf.org/doc/draft-wsv-bess-extended-evpn-optimized-ir/___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[zhang.zheng]

Support the adoption. This document does make sense.






Thanks,


Sandy









原始邮件



发件人：Bocci,Matthew(Nokia-GB) 
收件人：bess@ietf.org ;
抄送人：bess-cha...@ietf.org ;
日 期 ：2019年11月27日 20:37
主 题 ：[bess] WG Adoption and IPR Poll fordraft-litkowski-bess-rfc5549revision-00




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



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

[bess] comments on draft-ietf-bess-evpn-bum-procedure-updates-06

[zhang.zheng]

Hi authors,







I read this version and have some comments.






Thanks,


Sandy


==

1. In section 6.1, since the example is about AS, if it is better to change the 
title of this section to "AS/Area va. Region" ?

2. In section 6.2, the last sentence of the fourth paragrah, if it should be 
"there is no per-region S-PMSI aggregation routes"?


3. In section 6.2, if it is better to add some detail description for area ID 
EC construction?


4. In section 6.3, if it is better to add some detail description for Route 
Target construction?


5. The following is the idnits result:





idnits 2.16.02 

/tmp/draft-ietf-bess-evpn-bum-procedure-updates-06.txt:


  Checking boilerplate required by RFC 5378 and the IETF Trust (see


  https://trustee.ietf.org/license-info):

  

 No issues found here.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:


  

 No issues found here.


  Checking nits according to https://www.ietf.org/id-info/checklist :


  

  ** There are 16 instances of too long lines in the document, the longest


 one being 3 characters in excess of 72.

  -- The draft header indicates that this document updates RFC7432, but the


 abstract doesn't seem to mention this, which it should.




  Miscellaneous warnings:

  

  -- The document date (June 17, 2019) is 22 days in the past.  Is this


 intentional?




  Checking references for intended status: Proposed Standard


  




 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)




  == Missing Reference: 'RFC 7524' is mentioned on line 196, but not defined

  == Unused Reference: 'RFC2119' is defined on line 763, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC7432' is defined on line 773, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC7524' is defined on line 778, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC7988' is defined on line 784, but no explicit


 reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-architecture' is defined on line 791,


 but no explicit reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-evpn' is defined on line 797, but no


 explicit reference was found in the text

  == Unused Reference: 'RFC6513' is defined on line 802, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC6514' is defined on line 806, but no explicit


 reference was found in the text

  == Outdated reference: draft-ietf-bess-evpn-df-election-framework has been


 published as RFC 8584

  == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published


 as RFC 8534

  == Outdated reference: draft-ietf-bier-architecture has been published as


 RFC 8279




 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--).




 Run idnits with the --verbose option for more detailed information about

 the items above.___
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

[zhang.zheng]

Support the adoption.






Thanks,


Sandy











原始邮件



发件人：stephane.litkow...@orange.com 
收件人：bess@ietf.org ;
日 期 ：2019年05月07日 15:37
主 题 ：[bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping


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

  

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] Slot requests for BESS WG session - IETF 104 - Prague

[zhang.zheng]

Hi Mankamana, Chairs,






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


presenter: Sandy Zhang


Thank you very much!






Best regards,


Sandy







原始邮件



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


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

  

All,


 


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


 


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


 


Preliminary agenda can be found at :


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


 


 


Thank you


 


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

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg,

Thank you very much for your clarification!
I made a mistake that I thought the BFD session is the base solution for UMH 
failover. 
Now I get it. Thank you!
BTW: In section 3.1.2, "draft-ietf-rtgwg-bgp-pic-08" may be mentioned as 
another example like MPLS FRR.

Thanks,
Sandy
--原始邮件--
发件人：GregMirsky 
收件人：张征7940;
抄送人：zzh...@juniper.net ;bess-cha...@ietf.org 
;Thomas Morin ;Robert Kebler 
;BESS ;
日 期 ：2019年02月14日 10:38
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover
Hi Sandy,
thank you for your kind consideration of the proposed updates. I've logged my 
answers under GIM3>> tag.

Regards,
Greg

On Mon, Feb 11, 2019 at 11:44 PM  wrote:
Hi Greg,
Thank you for your good modification and clarification!
About two sections I still have some comments, I copy the contents here because 
the mail is too long:
1,
3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision.
GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a 
combination of conditions (the combination being determined by policy) to 
control the state of the BFD session, e.g., set it to AdminDown. I think that 
the use of policy to control the conditions that affect the P-tunnel reception 
state is the advantage of the proposed solution. What do you think?
4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?
GIM2>> As above, this is one of the conditions, controlled by the policy, that 
may be considered to influence the state of the BFD session.
Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE can 
get the tunnel states by BFD detection timer expiration. So administrator may 
choose different policies to control the session state, but the bfd packets 
detection should be the base. IMO section 3.1.1~4 are optional.
GIM3>> I re-read the 3.1 and I think now better understand the original idea. 
All methods listed in sub-sections, including the one that describes use of 
p2mp BFD, are alternatives, options to detect a failure in the tunnel. Would 
the following update be helpful:
OLD TEXT:
The procedure proposed here also allows that all downstream PEs don't
apply the same rules to define what the status of a P-tunnel is
(please see Section 6), and some of them will produce a result that
may be different for different downstream PEs.
NEW TEXT:
The optional procedures proposed in this section also allow that all downstream 
PEs don't
apply the same rules to define what the status of a P-tunnel is
(please see Section 6), and some of them will produce a result that
may be different for different downstream PEs.

For section 3.1.5 counter information, how do the configurable timer work with 
the bfd detection timer? What should egress PE do with the expiration of the 
two timers when they are both used?
GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast 
restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD per 
protected link. If that's the case, for the scenario described in this 
sub-section, p2mp BFD is unnecessary.

2.
For section 3.1.7.1, the last sentence.
GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be sent 
and the new p2mp BFD session must be initiated. Your question, as I interpret 
it, is to how operationally an implementation can minimize the disruption when 
the new BFD session advertised to replace one that already exists. Firstly, 
would we agree that sending the new BGP-BFD Discriminator and starting the new 
p2mp BFD session when the RPF interface changes is the right action? If we 
agree, then I can add a sentence or two to describe optional procedure for the 
upstream PE to minimize the disruption when the egress PE switches to the new 
p2mp BFD session.
Sandy2>If the "old" BFD discriminator can be reused in the new advertisement 
when the switchover is happened on a same upstream PE? If the "old" 
discriminator can be reused, it seems like it isn't necessary to build a new 
BFD session. But if a new BFD discriminator MUST be generated, then the new add 
sentence looks good to me.
GIM3>> Would the following update to the last paragraph address your concern:
OLD TEXT:
If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that value of the BFD
Discriminator is associated with the new RPF link.
NEW TEXT:
If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that the previously advertised value of the 
BFD
Discriminator is associated with the new RPF link.

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg,

Thank you for your good modification and clarification!
About two sections I still have some comments, I copy the contents here because 
the mail is too long:
1,
3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision. 
GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a 
combination of conditions (the combination being determined by policy) to 
control the state of the BFD session, e.g., set it to AdminDown. I think that 
the use of policy to control the conditions that affect the P-tunnel reception 
state is the advantage of the proposed solution. What do you think?
4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?
GIM2>> As above, this is one of the conditions, controlled by the policy, that 
may be considered to influence the state of the BFD session.
Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE can 
get the tunnel states by BFD detection timer expiration. So administrator may 
choose different policies to control the session state, but the bfd packets 
detection should be the base. IMO section 3.1.1~4 are optional. 
For section 3.1.5 counter information, how do the configurable timer work with 
the bfd detection timer? What should egress PE do with the expiration of the 
two timers when they are both used?

2.
For section 3.1.7.1, the last sentence.
GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be sent 
and the new p2mp BFD session must be initiated. Your question, as I interpret 
it, is to how operationally an implementation can minimize the disruption when 
the new BFD session advertised to replace one that already exists. Firstly, 
would we agree that sending the new BGP-BFD Discriminator and starting the new 
p2mp BFD session when the RPF interface changes is the right action? If we 
agree, then I can add a sentence or two to describe optional procedure for the 
upstream PE to minimize the disruption when the egress PE switches to the new 
p2mp BFD session.
Sandy2>If the "old" BFD discriminator can be reused in the new advertisement 
when the switchover is happened on a same upstream PE? If the "old" 
discriminator can be reused, it seems like it isn't necessary to build a new 
BFD session. But if a new BFD discriminator MUST be generated, then the new add 
sentence looks good to me.

Thanks,
Sandy

--原始邮件--
发件人：GregMirsky 
收件人：张征7940;
抄送人：zzh...@juniper.net ;bess-cha...@ietf.org 
;Thomas Morin ;Robert Kebler 
;BESS ;
日 期 ：2019年02月07日 08:16
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover
Hi Sandy,much appreciate your comments. Please find my answers below tagged 
GIM2>>.
Attached, please find the updated working version and the diff to the last 
published version.

Kind regards,
Greg

On Thu, Jan 31, 2019 at 7:40 PM  wrote:
Hi Greg, Jeffrey, co-authors,

About the questions provided by Jeffrey, I have some concerns, please see below 
with Sandy>.
And I have some other questions:
1. According to "draft-ietf-bfd-multipoint-19" and the function defined in this 
draft, IMO the BFD session should be demultiplexed by the combination of 
upstream peer address, the discriminator and the X-PMSI which is used for flow 
forwarding. IMO these content should be written in the draft clearly.
GIM2>> Agreed and to clarify I propose the following update to the Downstream 
PE Procedures:
OLD TEXT:
On receiving the BGP-BFD Attribute in the x-PMSI A-D Route, the
Downstream PE:

o  MUST associate the received BFD discriminator value with the
P-tunnel originating from the Root PE;

o  MUST create p2mp BFD session and set bfd.SessionType =
MultipointTail as described in [I-D.ietf-bfd-multipoint];

o  MUST use the source IP address of a BFD control packet, the value
of BFD Discriminator from the BGP-BFD Attribute to properly
demultiplex BFD sessions;

NEW TEXT:
Upon receiving the BGP-BFD Attribute in the x-PMSI A-D Route, the
Downstream PE:

o  MUST associate the received BFD discriminator value with the
P-tunnel originating from the Root PE and the IP address of the
Upstream PE;

o  MUST create p2mp BFD session and set bfd.SessionType =
MultipointTail as described in [I-D.ietf-bfd-multipoint];

o  MUST use the source IP address of the BFD control packet, the
value of the BFD Discriminator field, and the x-PMSI tunnel
identifier the BFD control packet was received to properly
demultiplex BFD sessions.

2. The P2MP BFD packet should be delivered in the X-PMSI tunnel. The BFD 
multicast packet MUST be encapsulated in associated tunnel. It seems like there 
is no specifiction for it.
GIM2>> Agree and to clarify I propose the following text to be added to the 
Upstream PE Procedures section:
NEW TEXT:
o  MUST periodically transmit BFD control 

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg, Jeffrey, co-authors,







About the questions provided by Jeffrey, I have some concerns, please see below 
with Sandy>.


And I have some other questions:


1. According to "draft-ietf-bfd-multipoint-19" and the function defined in this 
draft, IMO the BFD session should be demultiplexed by the combination of 
upstream peer address, the discriminator and the X-PMSI which is used for flow 
forwarding. IMO these content should be written in the draft clearly.



2. The P2MP BFD packet should be delivered in the X-PMSI tunnel. The BFD 
multicast packet MUST be encapsulated in associated tunnel. It seems like there 
is no specifiction for it. 


3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision. 


4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?






Thanks,


Sandy



原始邮件



发件人：GregMirsky 
收件人：zzh...@juniper.net ;
抄送人：bess-cha...@ietf.org ;Thomas Morin 
;Robert Kebler ;BESS 
;
日 期 ：2018年12月06日 02:38
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


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







Hi Jeffrey,thank you for the review, detailed questions and helpful comments. 
Please find my notes, answers in-line tagged GIM>>.

Regards,
Greg



On Fri, Nov 30, 2018 at 5:14 PM Jeffrey (Zhaohui) Zhang  
wrote:




Hi,


 


I have the following questions/comments:


 


   The procedure described here is an OPTIONAL procedure that consists


   of having a downstream PE take into account the status of P-tunnels


   rooted at each possible upstream PEs, for including or not including


   each given PE in the list of candidate UMHs for a given (C-S,C-G)


   state.  The result is that, if a P-tunnel is "down" (see


   Section 3.1), the PE that is the root of the P-tunnel will not be


   considered for UMH selection, which will result in the downstream PE


   to failover to the upstream PE which is next in the list of


   candidates.


 


Is it possible that a p2mp tunnel is considered up by some leaves  but down by 
some other leaves, leaving to them choosing different UMH? In that case, 
procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE") of 
RFC 6513 must be used. I see that this is actually pointed out later in section 
6 – good to have  a pointer to it right here.



GIM>> Would the following new text that follows the quoted text address your 
concern:
NEW TEXT: 
   If rules to determine the state of the P-tunnel are not
   consistent across all PEs, then some may arrive at a different
   conclusion regarding the state of the tunnel, In such a scenario,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used.

Sandy> I think Jeffrey means that a egress PE may choose a new UMH after the 
the "old" UMH fails. Then the egress PE may also receive (C-S, C-G) flows from 
old UMH p-tunnel, these flows MUST be discarded according to section 9.1.1 of 
RFC6513. 








 


Additionally, the text in section 3 seems to be more biased on Single  
Forwarder Election choosing the UMH with the highest IP address. Section 5 of 
RFC6513 also describes two other options, hashing or based on “installed UMH 
route” (aka unicast-based). It is not clear how the text in this document 
applies to hashing based selection,  and I don’t see how the text applies to 
unicast-based selection. Some rewording/clarification are needed here.



GIM>> How would the use of an alternative UMH selection algorithm change 
documented use of p2mp BFD? Do you think that if the Upstream PE selected 
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself no 
longer applicable?

Sandy> Diffrent UMH selection methods don't influent p2mp BFD documented in 
this draft. IMO both of section 3 and section 5 need to be mentioned here in 
order to avoid confusion.







 


   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is


   considered up if one or more of the P2MP RSVP-TE LSPs, identified by


   the P-tunnel Attribute, are in Up state. 


 


Why is “one or more of …” used in the above text?



GIM>> Would s/one or more of/at least one of/ address your concern? 

Sandy> I am not sure there are the situations that  two or more LSPs are used 
to deliver a same (C-S, C-G). IMO only the LSP used by forwarding need to be 
mointor in egress PE. 







 


There are several occurrences of ((S, G)). I assume they should be  changed to 
(C-S, C-G).



GIM>> Indeed, globally replaced s/((S,G))/(C-S,C-G)/ 






 


   A PE can be removed from the UMH candidate list for a given ((S, G))


   if the P-tunnel for this (S, G) (I or S , depending) is leaf


   triggered (PIM, mLDP)


 


Perhaps either remove the (I or S , 

Re: [bess] [Bier] FW: WG adoption poll fordraft-zzhang-bess-mvpn-evpn-aggregation-label-01

[zhang.zheng]

Support the adoption.







Thanks,


Sandy











原始邮件



发件人：Jeffrey(Zhaohui)Zhang 
收件人：BIER WG ;
日 期 ：2018年10月31日 08:20
主 题 ：[Bier] FW: WG adoption poll 
fordraft-zzhang-bess-mvpn-evpn-aggregation-label-01


___
BIER mailing list
b...@ietf.org
https://www.ietf.org/mailman/listinfo/bier

  

Hi,


 


This BESS draft was triggered by a BIER use case. We believe it’s  a critical 
piece of BIER deployment with MVPN/EVPN overlay.


If you agree with the problem statement (section 2.1) and solution,  appreciate 
your show of support for the adoption.


If you don’t agree, also appreciate your input and discussion.


 


Thanks!


Jeffrey


 



From: BESS  On Behalf Of stephane.litkow...@orange.com
 Sent: Tuesday, October 30, 2018 4:22 PM
 To: bess@ietf.org
 Subject: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01




 


Hi WG,


 


This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-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 Tue 13th November.  


 


Regards,


Stéphane and Matthew


 


[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/


 


 


 


 


 





 


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] Call for adoption:draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

[zhang.zheng]

Support the adoption of this draft.







Thanks,


Sandy











原始邮件



发件人：stephane.litkow...@orange.com 
收件人：bess@ietf.org 
日 期 ：2018年02月26日 16:03
主 题 ：[bess] Call for adoption:draft-zzhang-bess-mvpn-msdp-sa-interoperation-01


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

  

Hello working group,


 


This email starts a two-week call for adoption on


draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group 
Document.


 


Please state on the list if you support the adoption or not (in both cases, 
please also state the reasons).


 


This poll runs until *the 19th of March*.


 


We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or 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.


 


Thank you


 


(Martin), Matthew, Stéphane


bess chairs


 


[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-msdp-sa-interoperation/


 


_
 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 Last Call for draft-ietf-bess-mvpn-expl-track

[zhang.zheng]

Support the publication of this draft. 





And in section 3,

"

Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2),

   then Route1 would be (C-S2,C-G2)'s match for reception and also its

   match for tracking.  Also note that if a match for tracking does not

   have the LIR flag or the LIR-pF flag set, no explicit tracking

   information will be generated.  See Section 5.

"


It seems like that it should be 

"


 then Route1 would be (C-S1,C-G1)'s match for reception and also its


   match for tracking.

"


If it is a nit?





Thanks,

Sandy






原始邮件



发件人： 
收件人：  
日 期 ：2017年07月10日 23:24
主 题 ：[bess] WG Last Call for draft-ietf-bess-mvpn-expl-track





Hello Working Group,

This email starts a Working Group Last Call on 
draft-ietf-bess-mvpn-expl-track-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 *24th of July*.
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 Standard 
Track RFC.

*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-mvpn-expl-track, 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 the draft 
please respond to this email and indicate whether or not you are aware 
of any relevant IPR, additionally to what was already disclosed ([2]).

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,
T

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-mvpn-expl-track
[3] 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-mackie-bess-nsh-bgp-control-plane

[zhang.zheng]

Support. 

IMO it is useful and feasible.





Thanks,

Sandy










原始邮件



发件人： ＜martin.vigour...@nokia.com＞
收件人： ＜bess@ietf.org＞
抄送人： ＜draft-mackie-bess-nsh-bgp-control-pl...@ietf.org＞
日 期 ：2017年03月06日 19:53
主 题 ：[bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane





Hello working group,

This email starts a two-week call for adoption on 
draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group Document.

Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).

This poll runs until *the 19th of March*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

IPR has been disclosed against this Document [2].

If you are not listed as an Author or Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.

Thank you

Martin & Thomas
bess chairs

[1] 
https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-mackie-bess-nsh-bgp-control-plane

___
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