from:"Wanghaibo \(Rainsword\)"

Re: [bess] WG adoption poll for draft-wang-bess-sbfd-discriminator

2023-06-01 Thread Wanghaibo (Rainsword)

Hi Matthew and Stephane,

As a co-author, I support adoption of this draft by the BESS WG.

I am not aware of any undisclosed IPR, other than already disclosed, related to 
this draft.

Regards,
Haibo

From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Thursday, May 18, 2023 12:39 AM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG adoption poll for draft-wang-bess-sbfd-discriminator

Hello,

This email begins a two-weeks WG adoption poll for 
draft-wang-bess-sbfd-discriminator-05 [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 is one IPR disclosure 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 May 31th

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-wang-bess-sbfd-discriminator/
___
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-bgp-sdwan-usage-05

2022-10-07 Thread Wanghaibo (Rainsword)

Hi WG,
I support the publication of this draft.

Best wishes,
Haibo Wang

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Monday, September 26, 2022 7:06 PM
To: bess@ietf.org
Subject: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

This email starts a two-week working group last call for 
draft-ietf-bess-bgp-sdwan-usage-05 [1]

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

This poll runs until the 10th October 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 are currently two IPR disclosures.

Thank you,
Matthew & Stephane

[1]  
draft-ietf-bess-bgp-sdwan-usage-05

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

Re: [bess] Please send slot request for IETF-114

2022-07-15 Thread Wanghaibo (Rainsword)

Hi Mankamana,

If time permits, we'd like to request for a 10min time slot for a new draft 
https://datatracker.ietf.org/doc/draft-fu-bess-evpn-vpws-seamless/

Draft name: L2VPN VPWS Seamless with EVPN VPWS over SRv6
Presenter: Zheng Fu
Duration: 10 mins
Regards,
Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Mankamana Mishra 
(mankamis)
Sent: Monday, June 27, 2022 1:35 AM
To: bess@ietf.org
Subject: [bess] Please send slot request for IETF-114

All,
Please send me slot request for IETF 114. Primary agenda has been posted.

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

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

2022-03-23 Thread Wanghaibo (Rainsword)

Hi Greg,

Thanks for your suggestion.
I think your suggestion is good, we will modify it in the next version.

Regards,
Haibo

|-Original Message-
|From: Greg Mirsky [mailto:gregimir...@gmail.com]
|Sent: Sunday, March 20, 2022 4:29 AM
|To: Wanghaibo (Rainsword) 
|Cc: draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ; rtg-bfd
|WG 
|Subject: Re: A question about the draft-wang-bess-sbfd-discriminator
|
|Hi Haibo,
|thank you for the clarification. I may suggest a text for Section 3:
|
|In some EVPN deployments, for example, when it spans over multiple domains,
|only one of a pair of interconnected PEs benefits from monitoring the status of
|the connection. In such a case, using S-BFD [RFC7880] is advantageous as it
|reduces the load on one of the PEs while providing the benefit of faster
|convergence. The following sections provide examples of EVPNs that would
|benefit from using S-BFD.
|
|What are your thoughts?
|
|Regards,
|Greg
|
|On Tue, Mar 15, 2022 at 7:18 PM Wanghaibo (Rainsword) <
|rainsword.w...@huawei.com> wrote:
|
|> Hi Greg,
|>
|>Thanks for you comments.
|>
|> Yes, the resources will save at PE1 and PE2 as figure 1. This is a
|> typical 3PE scenario.
|>
|>The service is like this:
|>
|> +-++-++-+
|>
|> | UCE1|| APE1||SPE1 |,
|>
|> +-++-+`  /+-+ `.
|>
|>`,  .'   `.+-+
|>
|>..\/   | SCE1|
|>
|>  /\  `+-+
|>
|> `  `.  ,'
|>
|> +-++-+,' .+-+ `
|>
|> | uCEn|| APEn||SPE2 |`
|>
|> +-++-++-+
|>
|>There may be many Access PEs，used to access User CE. And they
|> all multi-homed to a couple Servicc PE, SPE1 and SPE2.
|>
|>(shown as the PE1 and PE2 as figure 1)
|>
|> Access PE needs to detect Service PE’s reachability. Access PE
|> creates SBFD session as an initiator, SPE as the reflector. This will
|> save Service PEs’ resources.
|>
|>
|>
|> Regards,
|>
|> Haibo
|>
|>
|>
|> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
|> *Sent:* Tuesday, March 15, 2022 11:12 PM
|> *To:* Wanghaibo (Rainsword) 
|> *Cc:* draft-wang-bess-sbfd-discrimina...@ietf.org; BESS
|> ; rtg-bfd WG 
|> *Subject:* Re: A question about the draft-wang-bess-sbfd-discriminator
|>
|>
|>
|> Hi Haibo,
|>
|> thank you for your expedient response. If I understand the scenario
|> you're addressing, it is where a single PE with moderate resources is
|> connected to a PE that acts as the edge device for the access network.
|> To improve the quality of user experience, customer's PE is connected
|> to a secondary PE that is used as a backup. You are concerned that
|> maintaining two BFD sessions on the customer's PE might overload the
|> resource-limited PE. But isn't that the PE that initiates S-BFD
|> sessions toward two access network edge PEs in your draft? I think
|> that the savings are on the side of these two PEs, not the subscriber's PE.
|Would you agree?
|>
|>
|>
|> Regards,
|>
|> Greg
|>
|>
|>
|> On Tue, Mar 15, 2022 at 7:20 AM Wanghaibo (Rainsword) <
|> rainsword.w...@huawei.com> wrote:
|>
|> Hi Greg,
|>
|>Thanks for your comments.
|>
|>The scenario you pointed out is a 4PE scenario, but in our
|> solution, a large number of scenarios are based on 3PE.
|>
|> In a 3PE scenario, deploying BFD wastes resources. A large number of
|> single-homed PEs may be connected to the dual-homed PEs. The
|> dual-homed PEs may not have enough resources to create BFD sessions.
|>
|>
|>
|> Regards,
|>
|> Haibo
|>
|>
|>
|> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
|> *Sent:* Tuesday, March 15, 2022 12:44 AM
|> *To:* Wanghaibo (Rainsword) ;
|> draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ;
|> rtg-bfd WG 
|> *Subject:* A question about the draft-wang-bess-sbfd-discriminator
|>
|>
|>
|> Hi Haibo and the Authors,
|>
|> thank you for updating the draft. I've read the new version and have a
|> question about the use case presented in the document. There are three
|> PEs with two of them providing redundant access to a CE. It appears
|> that a more general case would be if both CEs use redundant connections to
|the EVPN.
|> Asume, PE4 is added and connected to CE2. In that case, it seems
|> reasonable that each PE is monitoring remote PEs, i.e., PE1 monitors
|> PE3 and PE4, PE2
|> - PE3 and PE4, PE3 - PE1 and PE2, and PE4 - PE1 and PE2. So, now there
|> are pairs of S-BFD sessions between PEs connected to CE1 and CE2
|respectively
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

2022-03-15 Thread Wanghaibo (Rainsword)

Hi Greg,
   Thanks for you comments.
Yes, the resources will save at PE1 and PE2 as figure 1. This is a typical 3PE 
scenario.
   The service is like this:
+-++-++-+
| UCE1|| APE1||SPE1 |,
+-++-+`  /+-+ `.
   `,  .'   `.+-+
   ..\/   | SCE1|
 /\  `+-+
`  `.  ,'
+-++-+,' .+-+ `
| uCEn|| APEn||SPE2 |`
+-++-++-+
   There may be many Access PEs，used to access User CE. And they all 
multi-homed to a couple Servicc PE, SPE1 and SPE2.
   (shown as the PE1 and PE2 as figure 1)
Access PE needs to detect Service PE’s reachability. Access PE creates 
SBFD session as an initiator, SPE as the reflector. This will save Service PEs’ 
resources.

Regards,
Haibo

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Tuesday, March 15, 2022 11:12 PM
To: Wanghaibo (Rainsword) 
Cc: draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ; rtg-bfd 
WG 
Subject: Re: A question about the draft-wang-bess-sbfd-discriminator

Hi Haibo,
thank you for your expedient response. If I understand the scenario you're 
addressing, it is where a single PE with moderate resources is connected to a 
PE that acts as the edge device for the access network. To improve the quality 
of user experience, customer's PE is connected to a secondary PE that is used 
as a backup. You are concerned that maintaining two BFD sessions on the 
customer's PE might overload the resource-limited PE. But isn't that the PE 
that initiates S-BFD sessions toward two access network edge PEs in your draft? 
I think that the savings are on the side of these two PEs, not the subscriber's 
PE. Would you agree?

Regards,
Greg

On Tue, Mar 15, 2022 at 7:20 AM Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>> wrote:
Hi Greg,
   Thanks for your comments.
   The scenario you pointed out is a 4PE scenario, but in our solution, a 
large number of scenarios are based on 3PE.
In a 3PE scenario, deploying BFD wastes resources. A large number of 
single-homed PEs may be connected to the dual-homed PEs. The dual-homed PEs may 
not have enough resources to create BFD sessions.

Regards,
Haibo

From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Tuesday, March 15, 2022 12:44 AM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; 
draft-wang-bess-sbfd-discrimina...@ietf.org<mailto:draft-wang-bess-sbfd-discrimina...@ietf.org>;
 BESS mailto:bess@ietf.org>>; rtg-bfd WG 
mailto:rtg-...@ietf.org>>
Subject: A question about the draft-wang-bess-sbfd-discriminator

Hi Haibo and the Authors,
thank you for updating the draft. I've read the new version and have a question 
about the use case presented in the document. There are three PEs with two of 
them providing redundant access to a CE. It appears that a more general case 
would be if both CEs use redundant connections to the EVPN. Asume, PE4 is added 
and connected to CE2. In that case, it seems reasonable that each PE is 
monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2 - PE3 and PE4, PE3 - 
PE1 and PE2, and PE4 - PE1 and PE2. So, now there are pairs of S-BFD sessions 
between PEs connected to CE1 and CE2 respectively. That seems like too many 
sessions and that number can be reduced if one uses BFD instead of S-BFD. Would 
you agree? To simplify operations, it might be helpful to use the technique 
described in 
draft-ietf-bfd-unsolicited<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09>.
 In the recent discussion of the draft on the BFD WG ML, the authors noted that 
they are working on extending the scope to include the multi-hop BFD.
Greatly appreciate your thoughts about the number of S-BFD sessions.

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

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

2022-03-15 Thread Wanghaibo (Rainsword)

Hi Reshad,

   Thanks for your comments first.

|Authors, in section 3.1 3rd paragraph, last sentence, I'm not sure I fully 
understand. Instead of |having 2 S-BFD sessions on PE3 (as initiator) to PE1 
and PE2 (the responders), how are you merging |this into 1 single session?
[Haibo]: There may be a misinterpretation of the description here. Here we want 
to say, for PE3 (as initiator) and PE1 (as the responder)，there may be some 
SBFD sessions used to detect the VPNSID. For this case, we may merged them to 
an SBFD session used to detect the PE3’s locator.


|Also, I think the document would be clearer if the terms initiator and 
responder (as per RFC7880) are |used in the document.
   [Haibo]: We will modified it in the next version.


Regards,
Haibo

From: Reshad Rahman [mailto:res...@yahoo.com]
Sent: Tuesday, March 15, 2022 10:36 AM
To: Wanghaibo (Rainsword) ; 
draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ; rtg-bfd WG 
; Greg Mirsky 
Subject: Re: A question about the draft-wang-bess-sbfd-discriminator

Hi Greg, authors,


Greg, is your point is that instead of having a pair of S-BFD sessions between 
2 PEs, we can have 1 (traditional) BFD session between 2 PEs? In general I 
agree that S-BFD is better suited when only 1 side needs to perform continuity 
tests.

Authors, in section 3.1 3rd paragraph, last sentence, I'm not sure I fully 
understand. Instead of having 2 S-BFD sessions on PE3 (as initiator) to PE1 and 
PE2 (the responders), how are you merging this into 1 single session?

Also, I think the document would be clearer if the terms initiator and 
responder (as per RFC7880) are used in the document.

Regards,
Reshad.


On Monday, March 14, 2022, 12:44:55 PM EDT, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:


Hi Haibo and the Authors,
thank you for updating the draft. I've read the new version and have a question 
about the use case presented in the document. There are three PEs with two of 
them providing redundant access to a CE. It appears that a more general case 
would be if both CEs use redundant connections to the EVPN. Asume, PE4 is added 
and connected to CE2. In that case, it seems reasonable that each PE is 
monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2 - PE3 and PE4, PE3 - 
PE1 and PE2, and PE4 - PE1 and PE2. So, now there are pairs of S-BFD sessions 
between PEs connected to CE1 and CE2 respectively. That seems like too many 
sessions and that number can be reduced if one uses BFD instead of S-BFD. Would 
you agree? To simplify operations, it might be helpful to use the technique 
described in 
draft-ietf-bfd-unsolicited<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09>.
 In the recent discussion of the draft on the BFD WG ML, the authors noted that 
they are working on extending the scope to include the multi-hop BFD.
Greatly appreciate your thoughts about the number of S-BFD sessions.

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

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

2022-03-15 Thread Wanghaibo (Rainsword)

Hi Greg,
   Thanks for your comments.
   The scenario you pointed out is a 4PE scenario, but in our solution, a 
large number of scenarios are based on 3PE.
In a 3PE scenario, deploying BFD wastes resources. A large number of 
single-homed PEs may be connected to the dual-homed PEs. The dual-homed PEs may 
not have enough resources to create BFD sessions.

Regards,
Haibo

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Tuesday, March 15, 2022 12:44 AM
To: Wanghaibo (Rainsword) ; 
draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ; rtg-bfd WG 

Subject: A question about the draft-wang-bess-sbfd-discriminator

Hi Haibo and the Authors,
thank you for updating the draft. I've read the new version and have a question 
about the use case presented in the document. There are three PEs with two of 
them providing redundant access to a CE. It appears that a more general case 
would be if both CEs use redundant connections to the EVPN. Asume, PE4 is added 
and connected to CE2. In that case, it seems reasonable that each PE is 
monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2 - PE3 and PE4, PE3 - 
PE1 and PE2, and PE4 - PE1 and PE2. So, now there are pairs of S-BFD sessions 
between PEs connected to CE1 and CE2 respectively. That seems like too many 
sessions and that number can be reduced if one uses BFD instead of S-BFD. Would 
you agree? To simplify operations, it might be helpful to use the technique 
described in 
draft-ietf-bfd-unsolicited<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09>.
 In the recent discussion of the draft on the BFD WG ML, the authors noted that 
they are working on extending the scope to include the multi-hop BFD.
Greatly appreciate your thoughts about the number of S-BFD sessions.

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

Re: [bess] IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior to adoption of CAR/CT solutions

2022-03-07 Thread Wanghaibo (Rainsword)

Hello Sue,

I'm not aware of any IPR.

Regards
Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Friday, March 4, 2022 3:54 AM
To: bess@ietf.org; i...@ietf.org
Cc: spring-cha...@ietf.org
Subject: [bess] IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior 
to adoption of CAR/CT solutions

Greetings Bess and IDR:

The IDR chairs request that each of the authors of
draft-dskc-bess-bgp-car-03.txt.
submit an IPR statement in response to this email.
The motivation for this IPR call is below.

We expect IPR responses from the authors:
Dhananjaya Rao, Swadesh Agrawal, Clarence Filsfils,
 Ketan Talaulikar, Dirk Steinberg, Luay Jalil,
Yuanchao Su, Bruno Decraene, Jim Guichard,
Keyur Patel, Haibo Wang

There is one  IPR filed against this draft:
https://datatracker.ietf.org/ipr/4844/
Motivation for IPR call
==

Why are the IDR calling for IPR statements?
The authors of draft-kaliraj-idr-bgp-classful-transport-planes-13.txt
have asked for WG Adoption.

We have two drafts that are discussing embedded NLRI (color).
draft-dskc-bess-bgp-car-03.txt
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/
and
draft-kaliraj-idr-bgp-classful-transport-planes-13.txt

https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/

Since the IDR chairs know these drafts may overlap,
we expect to work closely with the bess-chairs, spring-chairs,
IDR WG, and BESS WG any WG adoption  and WG LC.

Other Discussions
==
IDR WG held an interim on 1/24/2022 that discussed these two drafts:
The minutes are at:
https://datatracker.ietf.org/meeting/interim-2022-idr-02/materials/minutes-interim-2022-idr-02-202201241000-01

Jeff has started two mail threads for CAR/CT drafts based on 2 Questions:
Question 1: BGP routes with color, Question 1: How does route resolution work 
with your feature?
https://mailarchive.ietf.org/arch/msg/idr/OaNnE5epcaK7GtcV8OlAVdD3ZbI/

Question 2: BGP routes with color, Question 2: Route origination and propagation
https://mailarchive.ietf.org/arch/msg/idr/4MYIFyHWITj8-Kk38AmKlkhh5b8/

Kaliraj began discussion on this email on IDR:
https://mailarchive.ietf.org/arch/msg/idr/_RB9Md01RXUPQ5g-8hzOfJPhT7k/

The BESS email discussion regarding CAR (11/18/2021 to 1/24/2022) can be found 
at:

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

Sue Hares
IDR chair
Document Shepherd

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

Re: [bess] Please send me slot request for IETF 113 (BESS is only remote )

2022-03-07 Thread Wanghaibo (Rainsword)

Hi Mankamana,

I would like to request a 10 minute time slot for the draft below:

In this version, we have updated the detail usage about the scenario that we 
want to use.
Also, we have revised our document according to the comments from the last 
meeting.

https://datatracker.ietf.org/doc/draft-wang-bess-sbfd-discriminator/

Regards,
Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Mankamana Mishra 
(mankamis)
Sent: Friday, February 18, 2022 11:22 PM
To: bess@ietf.org
Subject: [bess] Please send me slot request for IETF 113 (BESS is only remote )

All,
Please send me slot request for IETF 113. Please note BESS session would be 
only remote since none of the chairs are able to travel in person this time.


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

Re: [bess] I-D Action: draft-wang-bess-sbfd-discriminator-01.txt

2022-01-03 Thread Wanghaibo (Rainsword)

Hi All,

   We have update the draft: Advertising S-BFD Discriminators in BGP. 
   Thanks for Greg's comments. 
   In this version , we have described the usage of the proposed mechanism in 
more detail. Welcome more review & comments. Thanks.

Regards,
Haibo

-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, January 4, 2022 10:13 AM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-wang-bess-sbfd-discriminator-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Advertising S-BFD Discriminators in BGP
Authors : Haibo Wang
  Yang Huang
  Jie Dong
Filename: draft-wang-bess-sbfd-discriminator-01.txt
Pages   : 11
Date: 2022-01-03

Abstract:
   This document defines the method of transmitting S-BFD discriminators
   through BGP attributes.  This method makes it easier for operators to
   create S-BFD for services.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wang-bess-sbfd-discriminator/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-bess-sbfd-discriminator-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wang-bess-sbfd-discriminator-01


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

2021-11-06 Thread Wanghaibo (Rainsword)

Hi Greg,

Thanks for your comments. Please see my answers below under the [Habio] tag.

Regards,
Haibo
From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Saturday, November 6, 2021 1:03 AM
To: Wanghaibo (Rainsword) 
Cc: draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org; BESS ; idr 
wg 
Subject: Re: [bess] A question to the Authors of 
draft-wang-bess-sbfd-discriminator

Hi Haibo,
thank you for the detailed answers. I have added my follow-up notes below under 
the GIM>> tag.

Regards,
Greg

On Fri, Nov 5, 2021 at 1:22 AM Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>> wrote:
Hi Greg,
Thanks for your discussion.

•  The First scenario is an inter-domain SRv6 scenario, which is similar to 
OptionC. In this scenario, we must firstly make the SRv6 locator reachable. We 
may redistribute the SRv6 locator routes into BGP and advertise them to the 
other AS. This is a common solution, so we don't describe it in our document.
GIM>> Indeed, it is a well-known technique that can be mentioned with 
reference. I see it being helpful to a reader.

[Haibo] Thanks for your suggestion, and we'll make this part clearer.

•  Yes, in order to speed up fault detection, we need a S-BFD session from PE3 
to PE1 and also a S-BFD session from PE3 to PE2.
GIM>> As I understand the use of S-BFD in this case, PE3 transmits BFD control 
packets over the SRv6 Policy. If that is the case, I have two questions:

  *   Several SRv6 Policies between PE3 and, for example, PE1 might be used. If 
that is the case, would each such SRv6 Policy be monitored by its dedicated 
S-BFD session?
  *   It is still not clear to me how a reflected BFD control packet reaches 
PE3 from, for example, PE1.
[Haibo] The last answer is specify the figure 1. The S-BFD session created here 
is to detect the SRv6 locator IP reachability. The S-BFD control packet from 
PE3 to PE1 is according to PE1’s SRv6 locator IP’s reachability, which can be 
achieved by ASBR1/2 advertise PE1’s SRv6 locator IP to AS65002.

•  Figure 2 is a common scenario, here we just show a scenario which the 
service is over SRv6-Policy. We just show a scenario for intra-domain here, it 
also can be used for inter-domain.
For intra-domain scenario, we can advertise the discriminator with IGP 
according to RFC7883 or RFC7884. But there may be create unnecessary S-BFD 
sessions.
GIM>> That is an interesting point. Could you please share more details on what 
you consider as "unnecessary S-BFD session" and in what case these might be 
created?
[Haibo] If we use IGP to flood the S-BFD discriminator, each node in the domain 
will receive the information. If we create a session as soon as we receive this 
information, there will be redundancy. Therefore, S-BFD sessions need to be 
established based on service requirements.
In fact, we may also add a S-BFD discriminator Sub-TLV for SR-Policy to create 
the session. But this will be only used for the service over SRv6-Policy.
GIM>> Would then S-BFD session be created for each SRv6 Policy?
[Haibo] For scenario 2, the S-BFD session is created based on the next-hop 
address, that is, the endpoint of the SRv6-Policy. So the S-BFD session is not 
for each SRv6 Policy.
In our opinion, we need a common S-BFD discriminator to create the S-BFD 
session for detection the nexthop's reachability.
GIM>> Can you please clarify what is the "common S-BFD discriminator"? And what 
is the scope of the monitoring process - each next-hop or each SRv6 policy?
[Haibo] For “common S-BFD discriminator” mode, we want to create an S-BFD 
session according to the next-hop. SRv6 Policy is only a scenario that may be 
widely used. In fact, SRv6 can be used as well as IPv6 MPLS or even IPv4 MPLS. 
That is, the S-BFD session created for the next hop address is called “common 
S-BFD discriminator” mode. This is to distinguish the SRv6 locator mode, which 
will use the SRv6 locator as the destination.
Regrads,
Haibo
From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Wednesday, November 3, 2021 10:15 AM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Cc: 
draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org<mailto:draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org>;
 BESS mailto:bess@ietf.org>>; idr wg 
mailto:i...@ietf.org>>
Subject: Re: [bess] A question to the Authors of 
draft-wang-bess-sbfd-discriminator

Hi Haibo,
thank you for your detailed response to my question. I agree that drafts 
address different use cases. I also have several questions about the use cases 
presented in draft-wang-bess-sbfd-discriminator:

  *   As I understand the case presented in Figure 1, PE3 uses S-BFD to monitor 
interdomain SRv6 tunnels to PE1 and PE2 respectively. I couldn't find 
discussion of how reflected BFD packets reach PE3. I hope you can clarify that 
for me.
  *   Also to the case in Figure 1, do you envision also establishing S-BFD 
sessions f

Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

2021-11-05 Thread Wanghaibo (Rainsword)

Hi Greg,
Thanks for your discussion.

l  The First scenario is an inter-domain SRv6 scenario, which is similar to 
OptionC. In this scenario, we must firstly make the SRv6 locator reachable. We 
may redistribute the SRv6 locator routes into BGP and advertise them to the 
other AS. This is a common solution, so we don't describe it in our document.

l  Yes, in order to speed up fault detection, we need a S-BFD session from PE3 
to PE1 and also a S-BFD session from PE3 to PE2.

l  Figure 2 is a common scenario, here we just show a scenario which the 
service is over SRv6-Policy. We just show a scenario for intra-domain here, it 
also can be used for inter-domain.
For intra-domain scenario, we can advertise the discriminator with IGP 
according to RFC7883 or RFC7884. But there may be create unnecessary S-BFD 
sessions.
In fact, we may also add a S-BFD discriminator Sub-TLV for SR-Policy to create 
the session. But this will be only used for the service over SRv6-Policy.
In our opinion, we need a common S-BFD discriminator to create the S-BFD 
session for detection the nexthop's reachability.

Regrads,
Haibo


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Wednesday, November 3, 2021 10:15 AM
To: Wanghaibo (Rainsword) 
Cc: draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org; BESS ; idr 
wg 
Subject: Re: [bess] A question to the Authors of 
draft-wang-bess-sbfd-discriminator

Hi Haibo,
thank you for your detailed response to my question. I agree that drafts 
address different use cases. I also have several questions about the use cases 
presented in draft-wang-bess-sbfd-discriminator:

  *   As I understand the case presented in Figure 1, PE3 uses S-BFD to monitor 
interdomain SRv6 tunnels to PE1 and PE2 respectively. I couldn't find 
discussion of how reflected BFD packets reach PE3. I hope you can clarify that 
for me.
  *   Also to the case in Figure 1, do you envision also establishing S-BFD 
sessions from PE1 and PE2 to PE3?
  *   The use case presented in Figure 2 seems to be within a single domain. If 
that is the case, wouldn't advertising S-BFD discriminators via IGP achieve the 
goal?
I greatly appreciate it if you can clarify these questions for me.The

Regards,
Greg

On Thu, Oct 28, 2021 at 7:24 PM Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>> wrote:
Hi Greg,

Thanks for you comments.
I have read the 
draft-ietf-idr-bgp-ls-sbfd-extensions<https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sbfd-extensions/>.
 The problems and scenarios he's trying to solve are different from the way we 
use them.
The extension of the bgp-ls-sbfd-extension is to report the information 
collected by IS-IS/OSPF to the controller. The controller collects the 
information and delivers configurations to devices based on service 
requirements.
For example, the SBFD session is configured between PEs based on this 
descriminator.

In our solution, service routes are used to directly establish S-BFD sessions, 
and no controller coordination is required, simplifying deployment in some 
scenarios.
The two scenarios are oriented to different scenarios.
The bgp-ls-sbfd-extension solution mainly used for reports information. 
Therefore, only the information carried by IS-IS/OSPF needs to be reported. 
Therefore, the current extension is sufficient.
As our draft needs to be service-driven. In our scenarios, intermediate routers 
may change nexthops. To ensure service consistency, nexthop information needs 
to be added to verify S-BFD the creation of redundant S-BFD sessions.

Regards,
Haibo

From: BESS [mailto:bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] On 
Behalf Of Greg Mirsky
Sent: Friday, October 29, 2021 3:54 AM
To: 
draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org<mailto:draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org>;
 BESS mailto:bess@ietf.org>>; idr wg 
mailto:i...@ietf.org>>
Subject: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

Dear Authors,
thank you for bringing your work to the BESS WG. I've read the draft and 
couldn't find a reference to the IDR WG draft that, as it seems to me, 
addresses the same problem - 
draft-ietf-idr-bgp-ls-sbfd-extensions<https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sbfd-extensions/>.
 Could you take a look at the IDR draft and share your thoughts? Do you find 
that anything is missing in the draft-ietf-idr-bgp-ls-sbfd-extensions?


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

Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

2021-10-28 Thread Wanghaibo (Rainsword)

Hi Greg,

Thanks for you comments.
I have read the 
draft-ietf-idr-bgp-ls-sbfd-extensions.
 The problems and scenarios he's trying to solve are different from the way we 
use them.
The extension of the bgp-ls-sbfd-extension is to report the information 
collected by IS-IS/OSPF to the controller. The controller collects the 
information and delivers configurations to devices based on service 
requirements.
For example, the SBFD session is configured between PEs based on this 
descriminator.

In our solution, service routes are used to directly establish S-BFD sessions, 
and no controller coordination is required, simplifying deployment in some 
scenarios.
The two scenarios are oriented to different scenarios.
The bgp-ls-sbfd-extension solution mainly used for reports information. 
Therefore, only the information carried by IS-IS/OSPF needs to be reported. 
Therefore, the current extension is sufficient.
As our draft needs to be service-driven. In our scenarios, intermediate routers 
may change nexthops. To ensure service consistency, nexthop information needs 
to be added to verify S-BFD the creation of redundant S-BFD sessions.

Regards,
Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, October 29, 2021 3:54 AM
To: draft-ietf-idr-bgp-ls-sbfd-extensi...@ietf.org; BESS ; idr 
wg 
Subject: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

Dear Authors,
thank you for bringing your work to the BESS WG. I've read the draft and 
couldn't find a reference to the IDR WG draft that, as it seems to me, 
addresses the same problem - 
draft-ietf-idr-bgp-ls-sbfd-extensions.
 Could you take a look at the IDR draft and share your thoughts? Do you find 
that anything is missing in the draft-ietf-idr-bgp-ls-sbfd-extensions?


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

Re: [bess] Please send slot request for IETF 112

2021-10-27 Thread Wanghaibo (Rainsword)

Hi Mankamana,


  I would like to request one slot:

Draft:Advertising S-BFD Discriminators in BGP

Document:  https://datatracker.ietf.org/doc/draft-wang-bess-sbfd-discriminator/

Speaker:  Haibo Wang

Time:   10 minutes

Regards,
Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Mankamana Mishra 
(mankamis)
Sent: Friday, October 15, 2021 5:33 AM
To: bess@ietf.org
Subject: [bess] Please send slot request for IETF 112

All,
Primary schedule has been already posted for IETF. Please send me slot request 
for IETF112.

If this is for draft which has been already presented in previous IETF, please 
provide write up as well about what changed and why it would be presented again.


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

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

2021-09-28 Thread Wanghaibo (Rainsword)

Hi Ketan,

I’m sorry I have missed your reply.

For SRv6 services, we may have two choice for service. Use SRv6 SID to do best 
effort, or use  to steering to a SRv6 Policy。
Also we may use both of them, but most time we are priority to use the SRv6 
Policy than fall-back to SRv6 best effort, while SRv6 Policy is down.
So I think maybe use “alternate steering mechanism” is better.  Or maybe I 
misunderstood the sentence?

Regards,
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, September 16, 2021 4:55 PM
To: Wanghaibo (Rainsword) ; bess@ietf.org
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; Aissaoui, Mustapha 
(Nokia - CA/Ottawa) ; Shraddha Hegde 

Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Haibo,

Since the discussion on the list was related to fallback mechanisms, we have 
those words.

How about s/fallback mechanism /alternate steering mechanism ? Or please 
suggest if you had something else in your mind.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 16 September 2021 14:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 spr...@ietf.org<mailto:spr...@ietf.org>; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

   I think the overall description is OK. But is it appropriate to use the 
word “fallback mechanism”?

Regards,
Haibo

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Wednesday, September 15, 2021 11:00 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 spr...@ietf.org<mailto:spr...@ietf.org>; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the 
draft.

The objective of this change is to clarify the use of the SHOULD that is used 
in this text.

OLD/CURRENT
   When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.

NEW
   When the steering for SRv6 services is based on shortest path forwarding 
(e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to the 
egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change 
along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, July 23, 2021 11:08 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

< trimming list to mostly mailers >

Hi Mustapha,

I agree.

Also after seeing Shraddha’

[bess] Some YANG validator error info about draft-ietf-bess-l3vpn-yang

2021-09-14 Thread Wanghaibo (Rainsword)

Hi Authors,

Recently, we are preparing to use the L3VPN yang model, we check it with the 
yang-validator at https://yangcatalog.org/yangvalidator,
and found the following errors:

Pyang Validation
/var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-TwlCIaOZ/ietf-bgp-l3...@2018-04-17.yang:508:
 error: node ietf-bgp::bgp is not found
/var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-TwlCIaOZ/ietf-bgp-l3...@2018-04-17.yang:515:
 error: node ietf-bgp::bgp is not found
/var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-TwlCIaOZ/ietf-bgp-l3...@2018-04-17.yang:523:
 error: node ietf-bgp::bgp is not found
/var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-TwlCIaOZ/ietf-bgp-l3...@2018-04-17.yang:532:
 error: node ietf-bgp::bgp is not found
These errors appears to be model reference error.  The yang info are defined 
like this:
  augment "/bgp:bgp/bgp:global/bgp:afi-safis/" +
  "bgp:afi-safi/bgp:l3vpn-ipv4-unicast" {
description "Retain route targets for ASBR scenario";
uses retain-route-targets;
uses vpn-pfx-limit;
  }


 Reference to the correct model, eg. ietf-bgp-sr , it looks like should be 
defined like this:
  augment "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/" +
  "bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast" {
description
  "Augment BGP SAFI route";
uses common-bgp-route-grouping;
  }

Please confirm this issue and hope to update the document to fix it.

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

[bess] Mail regarding draft-ietf-bess-srv6-services

2021-08-02 Thread Wanghaibo (Rainsword)

Hi authors,

I have a question about the SRv6 Service Data Sub-Sub-TLVs, whether it should 
be mandatory or optional.

>From a practical point of view, this TLV can help identifier the locator or 
>optimize packaging efficiency by transposition.
But it doesn't seem it's must to do like this.

Regards,
Haibo
___
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-srv6-services-05

2020-12-04 Thread Wanghaibo (Rainsword)

Hi Matthew & Stephane,

Support for publication.

Thanks,
Haibo


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [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 Monday 14th 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-srv6-services/
[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-srv6-services-05

2020-12-04 Thread Wanghaibo (Rainsword)

Hi Rabadan & Ketan,

 I agree that the present description is clear.

  At the EANTC 2020 test, we found that the NX-OS has implement the 
transposition as 24bits for IPv4 VPN,  and it will parse a 20bits transposition 
as a wrong value.

   If we all agree on this description, I think it's okay.

Regards,
Haibo

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Thursday, December 3, 2020 9:50 PM
To: Ketan Talaulikar (ketant) ; Wanghaibo (Rainsword) 
; Bocci, Matthew (Nokia - GB) 
; draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: Re: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi Haibo,

I agree with Ketan… furthermore, the spec clearly defines the structure 
sub-sub-TLV, where the transposition length and offset are needed; it also 
defines how to place those bits into the label field of the NLRI, irrespective 
of the transposition length being 24 or 20 or anything different.

Out of interest, how can that lead to interop issues? Can you please elaborate?

Thank you.
Jorge

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Date: Thursday, December 3, 2020 at 11:25 AM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>, Bocci, Matthew 
(Nokia - GB) mailto:matthew.bo...@nokia.com>>, 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05
Hi Haibo,

This is not a change but a clarification to avoid exactly those kind of issues.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 03 December 2020 15:39
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi Ketan,

 Thanks for your reply.

RFC 8277 has clearly described that the label field is only 20 bits.

At the beginning, we consider it to use the 20-bits to do the transposition. 
But in some interconnection tests, some vendors are use the 24-bits to do the 
transposition.

So I’m worried about that the change may cause incompatible interop.

Regards，
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, December 3, 2020 5:01 PM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; Bocci, Matthew 
(Nokia - GB) mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi Haibo,

This clarification was explicitly added based on feedback that the authors 
received.

This document does not change the definition of the Label Field of RFC4364 and 
so it has always been 20 bits. There has been this text about 24-bit in other 
parts of the draft since RFC7432 allows that.

If you see the previous versions of this document, the encoding of the label 
was also previously clarified with a reference to RFC8277.

Regarding the BOS bit, the clarification is provided by RFC8277. Previously, 
this was under-specified by RFC3107. There are implementations around that do 
not check/examine the BOS field and assume a single label. You can see some of 
this history captured in RFC8277.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05


Dear authors and all,



 I find the following changes in the new version, which may cause incompatible 
changes in the implemented version.
[cid:image001.png@01D6CAE5.829FA370]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP<https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where the 
prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

  b) Label:



 The Label field carries one or more labels (that corresponds to

 the stack of labels 
[MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).  Each 
label is encoded as 3

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

2020-12-03 Thread Wanghaibo (Rainsword)

Hi Ketan,

 Thanks for your reply.

RFC 8277 has clearly described that the label field is only 20 bits.

At the beginning, we consider it to use the 20-bits to do the transposition. 
But in some interconnection tests, some vendors are use the 24-bits to do the 
transposition.

So I’m worried about that the change may cause incompatible interop.

Regards，
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, December 3, 2020 5:01 PM
To: Wanghaibo (Rainsword) ; Bocci, Matthew (Nokia - 
GB) ; draft-ietf-bess-srv6-servi...@ietf.org; 
bess@ietf.org
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi Haibo,

This clarification was explicitly added based on feedback that the authors 
received.

This document does not change the definition of the Label Field of RFC4364 and 
so it has always been 20 bits. There has been this text about 24-bit in other 
parts of the draft since RFC7432 allows that.

If you see the previous versions of this document, the encoding of the label 
was also previously clarified with a reference to RFC8277.

Regarding the BOS bit, the clarification is provided by RFC8277. Previously, 
this was under-specified by RFC3107. There are implementations around that do 
not check/examine the BOS field and assume a single label. You can see some of 
this history captured in RFC8277.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05


Dear authors and all,



 I find the following changes in the new version, which may cause incompatible 
changes in the implemented version.
[cid:image001.png@01D6C99E.5738BC00]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP<https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where the 
prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

  b) Label:



 The Label field carries one or more labels (that corresponds to

 the stack of labels 
[MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).  Each 
label is encoded as 3

 octets, where the high-order 20 bits contain the label value,

 and the low order bit contains "Bottom of Stack" (as defined in

 [MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).


According to the definition, the label field in RFC 4364 should be 3 bytes,  
but only 20 bits are used as the label value. So we may also use the entire 3 
octets.

On the other hand,  if only 20 bits are used, do we need to add the BoS flag to 
the part when do the transposition?



Best Regards,

Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [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 Monday 14th 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-srv6-services/
[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-srv6-services-05

2020-12-02 Thread Wanghaibo (Rainsword)

Dear authors and all,



 I find the following changes in the new version, which may cause incompatible 
changes in the implemented version.
[cid:image001.png@01D6C95C.F862B140]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP], where the 
prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

  b) Label:



 The Label field carries one or more labels (that corresponds to

 the stack of labels 
[MPLS-ENCAPS]).  Each 
label is encoded as 3

 octets, where the high-order 20 bits contain the label value,

 and the low order bit contains "Bottom of Stack" (as defined in

 [MPLS-ENCAPS]).


According to the definition, the label field in RFC 4364 should be 3 bytes,  
but only 20 bits are used as the label value. So we may also use the entire 3 
octets.

On the other hand,  if only 20 bits are used, do we need to add the BoS flag to 
the part when do the transposition?



Best Regards,

Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [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 Monday 14th 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-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

[bess] Mail regarding draft-ietf-bess-bgp-sdwan-usage

2020-11-01 Thread Wanghaibo (Rainsword)

Hi authors,

 About the section 4.1 BGP Walk Through for Homogeneous SDWAN.
  It shows an example that:
  - MP-NLRI Path Attribute: to indicate multiple routes attached to
 the C-PE2:
 10.1.x.x/16
 VLAN #15
 12.1.1.x/24
 - Tunnel-Encap Path Attribute: to describe the IPsec attributes

 This is a way of associating routea with tunnels, but each route has a large 
amount of information.

  However, there is another way to advertise routes with Tunnel Encapsulation 
Extend Community attributes, like draft-ietf-idr-segment-routing-te-policy.
In this method, tunnel information is advertised using independent SAFIs. 
Routes are associated with tunnels based on the Tunnel Encap EC.
Regards,
Haibo
___
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

2019-11-27 Thread Wanghaibo (Rainsword)

Support adoption of this draft.

Regards,
Haibo

发件人: BESS [mailto:bess-boun...@ietf.org] 代表 Bocci, Matthew (Nokia - GB)
发送时间: 2019年11月27日 20:37
收件人: bess@ietf.org
抄送: bess-cha...@ietf.org
主题: [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

[bess] Some question about the evpn yang

2018-12-05 Thread Wanghaibo (Rainsword)

Dear Editors of the EVPN YANG data model draft,


1. I have found that there are list ip-prefix-route under the 
evpn-instance, when will use this?
  +--rw evpn-instances
 +--rw evpn-instance* [name]

+--ro routes

|  +--ro ip-prefix-route*

2. According to this model, how to support EVPN vlan-aware service?


would highly appreciated your responses.

Regards,
Haibo

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

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

2018-10-26 Thread Wanghaibo (Rainsword)

Hi John,

I think the control word function is independent of the tunnel encapsulation. 
It is not very suitable to use the tunnel-encap draft extension.

Regards,
Haibo

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, October 25, 2018 12:03 AM
To: Alexander Vainshtein ; Yutianpeng (Tim) 

Cc: bess@ietf.org; draft-wang-bess-evpn-control-word.auth...@ietf.org; 
Wanghaibo (Rainsword) 
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi,

Comment inline

Yours Irrespectively,

John

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Alexander Vainshtein
Sent: Wednesday, October 24, 2018 11:57 AM
To: Yutianpeng (Tim) mailto:yutianp...@huawei.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>;
 Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Tim,
Lots of thanks for your email, it really clarifies your approach.

Regarding your proposal to “isolate” PEs that do not support the CW - I suspect 
this is not practical.

EVPN-MPLS implementations are not REQUIRED to support usage of CW. Some 
EVPN-MPLS implementations that I am aware of explicitly state that the CW usage 
can be disabled for interoperability with other vendors, so I think that there 
EVPN implementations that do not support the CW have been deployed.


draft-ietf-pals-ethernet-cw<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dpals-2Dethernet-2Dcw-2D07=DwMFoQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE=RlsyHSL6EDro6sABzjF38r6G2sDcGBosVDYDmwnPbZA=>
 (already in the RFC Editor queue in the AUTH48 state) says that “where both 
the ingress PE and the egress PE support the Ethernet pseudowire control word, 
then the CW MUST be used”.



Personally I think that this sets the goal that we should achieve in EVPN as 
well:

1.   All EVPN-MPLS implementations MUST support EVPN encapsulations without 
the CW

2.   An egress PE SHOULD indicate, per each L2VPN/EVPN route it advertises, 
whether it can handle received CW in the EVPN encapsulation for packets that 
are sent to it based on this route by ingress PEs, or not, and, if it can, how 
the presence of the CW is indicated.  This can be done using the CW Next-Hop 
Capability and the CWI label as explained in the draft



[JD]  I think it would be better to use this draft:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-10





3.   An ingress PE that accepts a L2VPN/EVPN route with the CW next Hop 
Capability, MUST insert the CW and indicate its presence, if it supports CWI 
and CW insertion in the appropriate EVPN encapsulation. Please note that the 
ability to insert CWI and CW may differ for different L2VPN/EVPN routes. E.g.. 
the same PE can:

a.   Support the CWI and CW insertion in the EVPN encapsulation of “known 
unicast” frames and BUM frames if their encapsulation does not require 
insertion of the ESI label

b.  Not support CWI and CW insertion in the EVPN encapsulation of BUM 
frames if this inclusion of the ESI label in their encapsulation is required.



This approach would  meet with the old IETF design principle: “Be strict in 
what you transmit and liberal in what you receive”.

Hope this helps.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Yutianpeng (Tim) [mailto:yutianp...@huawei.com]
Sent: Wednesday, October 24, 2018 5:32 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>
Cc: 
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Sasha,
Thanks a lot for your advice.
I agree with you that CW is not mandatory for all traffic, mainly unicast. This 
draft focuses on CW capability advertisement and is applicable to traffic needs 
CW processing.  So far BUM should be not relevant to this draft. (Multicast 
might need CW potentially we realize recently, but we will visit this topic 
later.)
Some clarification on my proposal:
I believe we need a mechanism of negotiation on CW capabilities in EVPN ELAN. 
If you check PW or EVPN VPWS there is a clear procedure on negotiation between 
two ends.
Refer to: 
https://tools.ietf.org/html/rfc4447#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4447-23section-2D6=DwMFoQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

2018-10-24 Thread Wanghaibo (Rainsword)

Dear Sasha,

Thanks for your advice.

Your understanding is correct.
Regarding your question, I don't think that all BUM traffic does not need a 
control word.
First of all, for broadcast traffic, there is really no need for a control word.
Secondly, for unknown unicast traffic, perhaps there is no problem with the 
control word, but the message may also be out of order due to load sharing. 
Finally, it is necessary for multicast traffic, otherwise it may also cause 
out-of-order problems due to load sharing.

Regards,
Haibo

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Wednesday, October 24, 2018 4:39 PM
To: Yutianpeng (Tim) 
Cc: draft-wang-bess-evpn-control-word.auth...@ietf.org; bess@ietf.org; 
Wanghaibo (Rainsword) 
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Tim,
Lots of thanks for sharing your views.

Unfortunately, I doubt the approach that you propose: always use or do not use 
CW in the same EVI.

The problem, as I see it is that known unicast and BUM traffic may be handled 
differently when it comes to EVPN encapsulation:

1.   Section 18 of RFC 7432 explicitly states that “When sending 
EVPN-encapsulated packets over a P2MP LSP or P2P LSP, then the control word 
SHOULD NOT be used”

a.   This recommendation is quite reasonable because the LSPs in question 
are not affected by ECMP, so there is no need to use the CW to prevent 
ECMP-cause reordering

b.  It is quite possible to P2MP LSPs as the P-tunneling technology 
delivery of BUM traffic in EVPN while using MP2P LSPs for carrying known 
unicast traffic

c.   The bottom line: RFC 7432 defines the  scenario when the CW SHOULD be 
used in the EVPN encapsulation of the known unicast traffic but SHOULD NOT be 
used in the EVPN encapsulation of BUM traffic as valid

2.   I am aware (this information is publicly available) of at least one 
deployed EVPN implementation that:

a.   By default includes the CW in the EVPN encapsulation of known unicast 
traffic (this default behavior can be disabled by explicit configuration)

b.  Does not include the CW in the EVPN encapsulation of BUM traffic, 
presumably due to limitations imposed by the forwarding HW.

c.   The bottom line: inconsistent usage of CW in the EVPN encapsulation 
within the same EVI (with differences between known unicast and BUM traffic) is 
already a fact on the ground (at least, to some extent).

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Yutianpeng (Tim) [mailto:yutianp...@huawei.com]
Sent: Tuesday, October 23, 2018 5:48 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Cc: 
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Sasha,
I am also thinking of this recently but haven’t talked with author yet.
What was in my mind the solution is actually simple: directly tear down (part 
of) the mac-VRF or EVI directly if CW capabilities not consistent, considering 
behavior in one EVI should keep consistent (personally believe).
I might tend to the mechanism as below:
If router A has CW capabilities and receive type 1 or type 2 routes without CW, 
then A should drop these routes and report an alarm.
If router A does not has CW capabilities and receive type 1 or type 2 routes 
with CW, then A should drop these routes and report an alarm.
I believe the behavior within EVI or Mac-VRF should keep consistent, otherwise, 
more questions will pop out.
Considering if a service is sensitive to packet misordering and it is ELAN, I 
tend to keep behavior within this ELAN consistent.
There could also be other problems with this approach, just share an idea so 
far open the discussion.
Regards, and lots of thanks in advance,
Tim

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 23 October 2018 14:42
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Cc: 
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,
Again,
Lots of thanks for a prompt response.

My reading of your response is as following:

1.   All egress PEs can receive EVPN-encapsulated packets without the CW

2.   All ingress PEs can sent EVPN-encapsulated packets without the CW

3.   An egress PE that can receive EVPN-encapsulated packets with the CW in 
the EVPN encapsulation,  must add the appropriate NH Capability attribute that 
indicates the CW-indicating label value (explicitly or implicitly) to all 
relevan

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

2018-10-23 Thread Wanghaibo (Rainsword)

Hi Alexander,

The solution here is to carry the next hop capability attribute when the route 
is advertised. The capability carried here is the control word capability.
The specific format of the next hop capability can be referred to the draft.: 

 +--+
 | Capability Code (2 octets)   |
 +--+
 | Capability Length (2 octets) |
 +--+
 | Capability Value (variable)  |
 ~  ~
 +--+
For the control word capability , it may encode as :
 +--+
 | CW Capabality Type (TBD) |
 +--+
 | CW Length (0 or 3)   |
 +--+
 | CWI Label (may not exist)|
 +--+
CWI (Control word indication)

And the forwarding Packet example.
 +--+
 | Tunnel Label |
 +--+
 | EVI Label|
 +--+
 | CW Indicate Label|
 +--+
 | Control word |
 +--+

The difference between the two methods is that which value should be use for 
the control word capability indicates label.

Method 1, use reserved label, which should be assigned by IANA, (such as the 
entropy label, which is the value of 7)
If we use this method, then the control word capability attribute’s CW length 
use 0 is enough.
And the forwarding packet use the IANA specified value as the CWI (Control word 
indication) Label .(Perhaps 8 or others)

Method2, use normal value, which is assigned by router.
If we use this method, then the router must assign a label used for the CWI. 
Perhaps label. And the control word capability attribute’s CW length must be 3 
and must contain the value in the update message.
The forwarding packet must use that value as the CWI label.

Regards,
Haibo

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Tuesday, October 23, 2018 6:09 PM
To: Wanghaibo (Rainsword) 
Cc: bess@ietf.org; draft-wang-bess-evpn-control-word.auth...@ietf.org
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,
Lots of thanks for an extra-prompt response to my question.

There may be some misunderstanding here.

The draft says (the important text is highlighted):

  There are two methods to specified the control word indicator label:

  The first method is to apply for a reserved label to indicate
  whether the packet contains a control word;

  The second method is to apply for a new label when the sending
  router advertises the control word capability, which is used to
  indicate whether the control word is included in the packet.

My question referred just to the 2nd method, while your response seems to deal 
with the 1st one.

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Wanghaibo (Rainsword)
Sent: Tuesday, October 23, 2018 12:03 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] 答复: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

The number of routes advertised by the Sender router in our solution will not 
change, but only carries a next hop capability attribute with control word 
capability
The Receiver router determines whether to carry the control word when 
forwarding packets according to its own capabilities.

The following figure is an example.:
PE1--PE2
|---PE3
When PE1 advertises a route, it carries the next hop attribute of the control 
word capability. The routes received by PE2 and PE3 are the same.

If  PE2 do not support the control word, it will not carry the control word 
when forwarding packets to PE1.
PE1 cannot find the control word indication label when parsing the PE2 packet. 
PE1 will treat the packet as normal.

If  PE3 support the control word, it can add a control word when forwarding the 
packet to the PE1, and add the control word indication label specified by the 
PE1.
When the PE1 receives the packet and finds the contr

[bess] 答复: A question regarding draft-wang-bess-evepn-control-word

2018-10-23 Thread Wanghaibo (Rainsword)

Hi Alexander,

The number of routes advertised by the Sender router in our solution will not 
change, but only carries a next hop capability attribute with control word 
capability
The Receiver router determines whether to carry the control word when 
forwarding packets according to its own capabilities.

The following figure is an example.:
PE1--PE2
|---PE3
When PE1 advertises a route, it carries the next hop attribute of the control 
word capability. The routes received by PE2 and PE3 are the same.

If  PE2 do not support the control word, it will not carry the control word 
when forwarding packets to PE1.
PE1 cannot find the control word indication label when parsing the PE2 packet. 
PE1 will treat the packet as normal.

If  PE3 support the control word, it can add a control word when forwarding the 
packet to the PE1, and add the control word indication label specified by the 
PE1.
When the PE1 receives the packet and finds the control word indication label in 
the packet. PE1 will correctly process the control word.

Thanks
Haibo

发件人: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
发送时间: 2018年10月23日 16:46
收件人: draft-wang-bess-evpn-control-word.auth...@ietf.org
抄送: bess@ietf.org
主题: A question regarding draft-wang-bess-evepn-control-word

Dear authors of 
draft-wang-bess-evpn-control-word,
I have doubts regarding at least one of the approaches for negotiating the CW 
usage in the EVPN encapsulation between egress and ingress PE that is defined 
in the draft.

In the case when the egress PE can receive EVPN-encapsulated packets both with 
and without CW, the draft seems to propose (as one of the possibilities) 
advertisement of two EVPN routes for each ES or MAC/IP pair:

-  One of these routes would use the CW Capability to indicate that it 
refers to the EVPN encapsulation that uses the CW, and would carry the 
appropriate label in its NLRI

-  The other route would not use the CW Capability to indicate that it 
refers to the EVPN encapsulation that does not use the CW, and carry a 
different label in its NLRI

The ingress PE that accepts these routes would then use one of them based on 
its own ability to use the CW (or lack thereof), and use the corresponding 
label it its EVPN encapsulation, while  the DP in the egress PW would infer 
presence or absence of the CW from the received EVPN application label.

Unfortunately, I do not think that this can work because, as per RFC 
7432, labels in the labeled NLRI of EVPN 
routes are not part of the route key for the purpose of the BGP route key 
processing, while the label is treated just as the BGP attribute. This means 
that, unless some form of BGP multi-path is enabled in the ingress PE (and in 
all RRs on the way between the egress PE and ingress PE) for the L2VPN/EVPN  
AFI/SAFI, only one of these routes will be selected by the BGP selection 
process.

Did I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-wang-bess-sbfd-discriminator

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

Re: [bess] Please send slot request for IETF-114

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

Re: [bess] A question about the draft-wang-bess-sbfd-discriminator

Re: [bess] IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior to adoption of CAR/CT solutions

Re: [bess] Please send me slot request for IETF 113 (BESS is only remote )

Re: [bess] I-D Action: draft-wang-bess-sbfd-discriminator-01.txt

Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

Re: [bess] A question to the Authors of draft-wang-bess-sbfd-discriminator

Re: [bess] Please send slot request for IETF 112

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[bess] Some YANG validator error info about draft-ietf-bess-l3vpn-yang

[bess] Mail regarding draft-ietf-bess-srv6-services

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[bess] Mail regarding draft-ietf-bess-bgp-sdwan-usage

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

[bess] Some question about the evpn yang

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

[bess] 答复: A question regarding draft-wang-bess-evepn-control-word

28 matches

Site Navigation

Mail list logo

Footer information