Re: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI Supported

[Dongjie (Jimmy)]

Hi WG,

I support the merge of these documents. This is useful work, and hope this 
would simplify both the design options and the IETF process.

Best regards,
Jie

From: Gyan Mishra 
Sent: Friday, July 28, 2023 8:32 AM
To: BESS ; bess-cha...@ietf.org; Dongjie (Jimmy) 

Subject: IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI 
Supported

Dear BESS WG,

From my presentation today discussion on "merging" of drafts I  would like to 
poll the BESS WG on merging of the two drafts labeled #1 & #2 below into the WG 
document labeled #3 below:
Please respond  to this email.

Some history:
IPv6 Only PE design / ALL SAFI:
draft-ietf-bess-ipv6-only-pe-design-04 (BCP) (Original BCP testing draft with 
Cisco, Juniper, Nokia, Arista, Huawei) (WG document)
IPv6 Only PE design single IPv6 peer - testing SAFI 1,128,129
draft-mishra-bess-ipv6-only-pe-design-all-safi-04 (Standards Track) (New Draft) 
- Extended Standards Track to support ALL IPv4 SAFI

IPv4 Only PE design / ALL SAFI:
The below drafts were two separate drafts but I have combined into single draft 
since they both were not WG documents
draft-mishra-bess-ipv4-only-pe-design-02 -(BCP) (POC testing draft with Cisco, 
Juniper, Nokia, Arista, Huawei)
IPv4 Only PE design single IPv4 peer - testing SAFI 1,128,129
draft-mishra-bess-ipv4-only-pe-design-all-safi-05 (Standards track) (New Draft) 
- Extended Standards Track to support ALL IPv4 SAFI (Both v4 drafts have been 
combined into this Draft early this year)
(Introduces new IPv4 next hop encoding IANA capability codepoint 
standardization following RFC 8950 IPv4 next hop and not legacy IPv4 mapped 
IPv6 address next hop ::::1.1.1.1)
(Today there is a mix of IPv4 next hop and IPv4 mapped IPv6 next hop across all 
vendors and within same vendor platform -afi/safi matrix to be added to merged 
draft)

Combine these two drafts --> So now we are left with  these 2 new drafts that 
extend to support ALL SAFI

#1 draft-mishra-bess-ipv6-only-pe-design-all-safi-03 (Standards Track)
#2 draft-mishra-bess-ipv4-only-pe-design-all-safi-04 (Standard Track)

Into WG document below:

#3 draft-ietf-bess-ipv6-only-pe-design-04 (BCP)

And make the new combined draft "Standards Track" as it will have the 
operational process and procedure update for the alternative dual stacking 
method for all SAFI
as well as New IANA capability code point for IPv4 next hop encoding similar to 
RFC 8950.

NEW DRAFT NAME:

 draft-ietf-bess-v4-v6-pe-all-safi (Standards Track)

Why combine?

  *   Both IPv4 Only PE Design & IPv6 Only PE design are identical concepts of 
single IPv4 peer or single IPv6 peer carrying SAFI 1,128.129 for both v4 & v6 
prefixes being POC tested - can now be done in parallel
  *   Extensibility of both the IPv4 Only PE Design & IPv6 Only PE design 
extends to the same set of ALL IPv4 / IPv6 SAFI's
  *   Saves both WG time on progressing 3 separate drafts
  *   Single draft that has the entire v4 / v6 design & architecture in one 
spot versus being broken out into separate drafts added complexity

Thank you


[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

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

[Dongjie (Jimmy)]

Hi Chairs,

I support the adoption as a coauthor. The mechanism proposed in this document 
is useful for BFD provisioning and technically sound.

I'm not aware of any undisclosed IPR that is related to this draft.

Sorry for the late response.

Best regards,
Jie

From: BESS [mailto:bess-boun...@ietf.org] 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] [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

[Dongjie (Jimmy)]

Hi Sue and authors,

I've read the latest version of this document and have some questions,

I understand this document provides one mechanism to build P2MP Trees using the 
tree SIDs and the unicast SR SIDs.  While it is not quite clear to me how much 
it is analogous to SR policy, and whether BGP is the suitable tool for its 
provisioning.


1.   This document introduces 3 route types. The first route type is 
provisioned to the headend node (the root node), the second route type is used 
to provision the replication SID on each replication node individually, and the 
third route type is used to progress each outgoing interface individually for a 
replication cross connect.  This is different from SR Policy which only needs 
to be provisioned on the headend nodes of the path, and it seems that this is 
an extension to BGP for the provisioning of individual transit nodes and 
interfaces with different information.



2.   In this document, a P2MP candidate path carried in BGP tunnel encaps 
attribute consists of several path instances, one of the path instance is 
active, the others are used as backup paths. And under a path instance, it may 
contain a protection segment list.



While in BGP SR Policy,  the tunnel encaps attribute consists of multiple 
segment lists under one candidate path, and all the segment lists are used for 
load balancing purpose. Different candidate paths can be used as either active 
or backup paths, but they are carried with different SR Policy NLRIs. Since 
this document says it reuses the concept of candidate path, It would be helpful 
if it could highlight the difference from SR Policy candidate path in the 
structure.


Best regards,
Jie

From: pim [mailto:pim-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:55 PM
To: i...@ietf.org; p...@ietf.org; bess@ietf.org
Subject: [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?

5) Do you think this SR P2MP policies should not be advertised
via BGP?

Cheers, Susan Hares
___
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

[Dongjie (Jimmy)]

Hi,

I support the adoption of this document, it provides useful information which 
can help the transition towards IPv6.

Best regards,
Jie

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, April 13, 2021 5:37 PM
To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org; bess@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

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] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[Dongjie (Jimmy)]

Hi Matthew and Stephane,

I've read this document and support its publication as a standards track RFC.

Best regards,
Jie

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com
Sent: Friday, December 11, 2020 11:53 PM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04

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 Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Dongjie (Jimmy)]

Hi Matthew & Stephane,

I support publishing this draft as a standards track RFC.

Best regards,
Jie

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 Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Dongjie (Jimmy)]

Hi,

I support the adoption of this document.

Best regards,
Jie
发件人：Bocci, Matthew (Nokia - GB) 
收件人：bess 
抄 送：bess-chairs 
时 间：2019-11-27 20:37:25
主题[bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

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



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

Re: [bess] New bess Co-Chair

[Dongjie (Jimmy)]

+1

Thanks Thomas and welcome Stephane.

Best regards,
Jie

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Saturday, December 02, 2017 6:00 AM
To: Dolganow, Andrew (Nokia - SG/Singapore) 
Cc: Rabadan, Jorge (Nokia - US/Mountain View) ; Tony 
Przygienda ; bess@ietf.org; Alvaro Retana 

Subject: Re: [bess] New bess Co-Chair

+1
Regards,
Jeff

On Dec 1, 2017, at 13:08, Dolganow, Andrew (Nokia - SG/Singapore) 
> wrote:
+1

Andrew

Sent from my iPhone

On Dec 1, 2017, at 11:27 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
> wrote:
+1

Welcome Stephane!
And Thomas, thank you very much for all your hard work. You’ve been crucial for 
all the work in this WG.


On 12/1/17, 8:27 AM, "BESS on behalf of Tony Przygienda" 
 on behalf of 
tonysi...@gmail.com> wrote:

Ack, welcome, great to have more and more operators getting involved in the 
sausage definition. This leads often to early discussions and better 
appreciation of the challenges of ultimately pouring the resulting tapestry of 
RFCs into bits and silicon ;-)
--- tony

On Fri, Dec 1, 2017 at 8:16 AM, Alvaro Retana 
> wrote:
Dear bess WG:

I am sad to report that Thomas Morin has decided not to continue as bess 
Co-Chair due to the demands of his job.  Thomas: thank you for all the effort 
you have put into the WG, we all look forward to your continued contributions 
to the IETF!

In consultation with Martin and the other ADs, we have asked Stephane Litkowski 
to take on the role of bess Co-Chair.  As most of you know, Stephane works at 
Orange Business Services, has been involved in the IETF for several years and 
had made significant contributions in a number of WGs in and out of the Routing 
Area.  Welcome Stephane!

Stephane can be reached at 
stephane.litkow...@orange.com.

This change is effective immediately.

Thanks!

Alvaro.

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

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

Re: [bess] draft-rosen-idr-rfc3107bis-00

[Dongjie (Jimmy)]

Hi Eric, 

Thanks for writing this draft, it provides useful clarifications and updates 
for RFC 3107. 

After reading the draft, I have some comments:

1. For NLRI encoding with single label, this draft says that "the S bit MUST be 
set to one on transmission". IMO RFC 3107 does not mandate this, and as you 
said some existing implementations may not set the S bit. To ensure backward 
compatibility, maybe the requirement on setting the S bit can be relaxed.

2. For NLRI encoding with multiple labels, I guess the beginning of the prefix 
field is identified based on the S bit of the last label. If a malformed NLRI 
is received, in which the S bit of the last label is not set, then the prefix 
cannot be recognized, and the treat-as-withdraw error handling is not 
applicable. This may be worth mentioned in the draft. 

3. Section 2.5 describes implicit withdrawn and load balancing in detail. One 
possible issue here is it seems that the same next hop is required for the 
routes in Update U1 and U2. While section 9 of RFC 4271 specifies:

   "...if the NLRI of the new route is identical to the one the route currently 
has stored in the Adj-RIB-In, then the new route SHALL replace the older route 
in the Adj-RIB-In, thus implicitly withdrawing the older route from service."

Thus same next hop is not required for implicit withdrawn. This also applies to 
the load balancing case with Add_Path, in which the 2 paths used for load 
balancing may have different next hops.

Best regards,
Jie

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Eric C Rosen
> Sent: Thursday, January 14, 2016 2:11 AM
> To: i...@ietf.org; BESS ; m...@ietf.org
> Subject: [bess] draft-rosen-idr-rfc3107bis-00
> 
> Folks,
> 
> Pardon the cross-post, but I think this may be of interest to all three of
> the IDR, MPLS, and BESS WGs.
> 
> I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS Labels
> to Address Prefixes"), which is intended of course to obsolete RFC 3107
> ("Carrying Label Information in BGP").  (While I put "idr" in the name of
> the draft, it's not completely obvious which WG should own this draft
> (assuming it progresses)).
> 
> The purpose of this draft is the following:
> 
> - It fixes a number of errors in RFC3107.  It attempts to do so in a way
> that is compatible with existing implementations.
> 
> - It removes the material about "Advertising Multiple Routes to a
> Destination".  This is a feature that was never implemented as specified,
> and the text about it just causes confusion.  The functionality that this
> feature was intended to provide can now be better provided by using
> add-paths; this is discussed in the draft.
> 
> - It is explicit about its applicability to SAFI 128 as well as to SAFI 4.
> 
> - It clarifies the procedures for withdrawing and replacing label bindings.
> 
> - It discusses the relationship between SAFI-1 routes and SAFI-4 routes,
> which is very unclear in RFC3107.  Different implementations have
> treated the SAFI-1/SAFI-4 interactions differently, and the draft discusses
> these differences.  However, as the draft is not intended to favor any one
> implementation over another, it can't do much more than point out some
> of the differences among implementations.
> 
> - RFC 3107 provides an encoding that allows BGP to assign multiple labels
> (i.e., a label stack) to a given prefix.  However, it provides no semantics
> for this, and this feature has been only rarely implemented.
> In fact, it is believed that some implementations will not parse the
> Updates correctly if they encode multiple labels in the NLRI.  Therefore
> the draft only allows a label stack to be assigned to a given prefix if a new
> Capability has been exchanged.  It also discusses the semantics of
> assigning a label stack, and gives some examples of how this might be
> used.
> 
> I hope that those of you who are interested in this topic will provide your
> comments.  I've tried to make the draft compatible with existing
> implementations and deployments, so if anyone sees anything that
> negatively impacts an existing implementation, please comment on that.
> 
> I also removed most of the text that explains why it is a good idea to use
> BGP to distribute label bindings.  That text was important in the '90s, but
> now seems rather out of date.  However, I would welcome comments on
> whether an updated "motivation/positioning" section should be added.
> 
> Thanks,
> 
> Eric
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction

[Dongjie (Jimmy)]

Support the adoption. Draft provides a useful solution for FIB scalability.

Best regards,
Jie

 -Original Message-
 From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
 Sent: Wednesday, January 07, 2015 7:06 PM
 To: bess@ietf.org
 Cc: draft-xu-l3vpn-virtual-subnet-fib-reduct...@tools.ietf.org
 Subject: [bess] Poll for adoption: draft-xu-l3vpn-virtual-subnet-fib-reduction
 
 Hello working group,
 
 This email starts a two-week poll on adopting
 draft-xu-l3vpn-virtual-subnet-fib-reduction [1] as a working group item.
 
 Please send comments to the list and state if you support adoption or not (in
 the later case, please also state the reasons).
 
 This poll runs until **January 21st**.
 
 
 *Coincidentally*, we are also polling for knowledge of any IPR that applies to
 this draft, 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* please respond to
 this email and indicate whether or not you are aware of any relevant IPR.
 
 The draft will not be adopted until a response has been received from each
 author and contributor.
 
 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://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-reduction
 
 ___
 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