[bess] Éric Vyncke's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-pbb-evpn-isid-cmacflush-08

Thank you for the work put into this document. This is a very specific area of
work and the text is not easy to read for a non expert. So, I was happy to rely
on the Internet directorate review below by Pascal.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Matthew Bocci for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

Other thanks to Pascal Thubert, the Internet directorate reviewer (at my
request), please consider this int-dir review as if it was mine:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/reviewrequest/17846/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract

No need for action, but I have rarely seen such an acronym-dense abstract, it
is therefore hard to read.

## G.8032

G.8032 should be an informative reference (this would be DISCUSS level issue if
the reference was normative).

## Scalability

Should there be some text about the scalability issues ? I.e., MAC addresses
move (Wi-Fi roaming) and are changing (cfr MADINAS WG).



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

[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
DISCUSS:
--

Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
This seems operationally dangerous and will lead to additional operational
complexity, tricky to debug behaviors, additional implementation complexity,
etc. Assuming that there *is* a good reason (and "Well, we couldn't decide,,
so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators decide
which algorithm they should deploy, and the pro's and con's of each.

[0]: I did try and find this, but the closest I got was a note in the Shepherd
Writeup saying: "There was a "last minute" agreement on managing the
highest/lowest pref algorithm using different DF algs rather than a single
one+local configs." -- this doesn't actually answer the question.


--
COMMENT:
--

I support John Scudder's DISCUSS, as well as his comments -- the Introduction
seems quite incomplete, and just sort of throws the reader into the deep end.



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

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

[Haoyu Song]

BESS WG

I support the merge of the documents. Thanks!

Best regards,
Haoyu
-- Forwarded message -
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Thu, Jul 27, 2023 at 8:31 PM
Subject: IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI 
Supported
To: BESS mailto:bess@ietf.org>>, 
mailto:bess-cha...@ietf.org>>, Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>>

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://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

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

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

[Mankamana Mishra (mankamis)]

Support the merger of document.

From: Acee Lindem 
Date: Monday, August 7, 2023 at 6:46 AM
To: Jeff Tantsura 
Cc: Gyan Mishra , BESS , 
bess-cha...@ietf.org , Dongjie (Jimmy) 

Subject: Re: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design 
ALL SAFI Supported
I also support merger of the four documents with identification of common 
procedures.

Thanks,
Acee


On Aug 6, 2023, at 21:03, Jeff Tantsura  wrote:

As co-author I support the merge of the documents proposed, please do provide 
any objections you might have.

Cheers,
Jeff


On Jul 27, 2023, at 17:32, Gyan Mishra  wrote:

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


[Image removed by sender.]
Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com
M 301 502-1347

___
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] Meeting minutes uploaded

[Mankamana Mishra (mankamis)]

All,
Meeting minute uploaded for IETF 117. Thanks to Jorge and Krishna for helping 
out with minutes.

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

[bess] Intdir telechat review of draft-ietf-bess-pbb-evpn-isid-cmacflush-08

[Pascal Thubert via Datatracker]

Reviewer: Pascal Thubert
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

The following are other issues I found with this document that SHOULD be
corrected before publication:

Please indicate how the CE can know if the PW failure is not due to the PE
failure, in which case extending the Customer MAC flush solution in RFC7623
seems more efficient as all I-SIDs with link / PW starting there are affected.
And how the double flush in avoided in the case of a non-null ESI with this
spec on as well.

I found this
"
When I-SID-based C-MAC-flush is disabled, the PE will follow the [RFC7623]
procedures for C-MAC-flush. " but it does not answer either of the above. e.g.,
does the reciprocal of the above apply too? or can they be both on?

I'd have thought that upon loss of connectivity with PE3, CE3 enables the PW to
PE4 and tells PE4 to send the update. Now it seems that the main player of this
spec is actually PE4 and that it's death is reported some other way. If that's
correct, saying it earlier would have saved me a headache ;)

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

First use (in intro) of "Ethernet Segments" add "(ES)" since ES and ESI are
used later. On second use (with multi home) please indicate whether that is
equivalent to non-null ESI and virtual ES since they seem to be used
interchangeably later.

"
Since there are no multi-homed ES defined, the PEs keep their Attachment
Circuits active as long as the physical connectivity is established and the CEs
are responsible for managing the redundancy, avoiding loops and providing
per-I-SID load balancing to the PBB-EVPN network. " This makes sense but a
reference to a spec that explains that in details (: to the dumb reader :)
would be appreciated. Is this all in RFC7623?

"
For instance, CE2 will block its link to CE1 and CE3 will block its forwarding
path to PE4. " I understand that's the normal before-failure condition, like
having the ring open between CE1 and CE2. Suggestion:

"
For instance, in normal conditions, CE2 will block its link to CE1 and CE3 will
block its forwarding path to PE4. "

On first use of the BMAC/X format please clarify that it means BMAC/ISID. This
appears later but without clarification.



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

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

[Acee Lindem]

I also support merger of the four documents with identification of common 
procedures. 

Thanks,
Acee

> On Aug 6, 2023, at 21:03, Jeff Tantsura  wrote:
> 
> As co-author I support the merge of the documents proposed, please do provide 
> any objections you might have.
> 
> Cheers,
> Jeff
> 
>> On Jul 27, 2023, at 17:32, Gyan Mishra  wrote:
>> 
>> 
>> 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
>> 
>>  
>> Gyan Mishra
>> Network Solutions Architect 
>> Email gyan.s.mis...@verizon.com 
>> M 301 502-1347
>> 
>> 
>> ___
>> 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] Zaheduzzaman Sarker's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

Thanks for working on this specification.

I don't have any transport related points on this specification. However, as
similar != same, it would be great if we can illustrate where the procedure in
section 4.1 bullet D might be different or have different considerations
between Highest-Preference and Lowest-Preference algorithms.



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

Re: [bess] Review of draft-ietf-bess-ebgp-dmz-03

[Susan Hares]

Satya:


Indeed the last sentence "Whether this"  was cut off.   The full sentence is



"Whether this linkage should be provided in a parallel document structure, is 
an editorial matter."



The point of that brief text was to indicate that I find it useful to have 
parallel naming structures.  As a theoretical example,



Protocol discussion-1:  (text)



Usage case illustrating protocol feature-1:  (text)



However, I leave the structure of the document to the authors.  As a reviewer, 
I simply look to find the parallel information.



Cheers, Sue





From: Satya Mohanty (satyamoh) 
Sent: Wednesday, August 2, 2023 12:49 PM
To: Susan Hares ; BESS 
Cc: Andrew Alston 
Subject: Re: [bess] Review of draft-ietf-bess-ebgp-dmz-03

Hi Sue, Thanks for your comments. Yes, we are in discussion with other vendors 
regarding link-bandwidth and we will together put a document that will consider 
all the aspects that you have mentioned.
External (satya...@cisco.com)
  Report This 
Email
  
FAQ
  GoDaddy Advanced Email Security, Powered by 
INKY

Hi Sue,

Thanks for your comments. Yes, we are in discussion with other vendors 
regarding link-bandwidth and we will together put a document that will consider 
all the aspects that you have mentioned. Indeed, the transitive or 
non-transitive implementation across vendors poses a challenge to 
implementation.
Yes, we will refresh draft-ietf-idr-link-bandwidth possibly with new authors. 
That was also one of the points in our offline discussions.

Regarding your comment and alluding to entropy label, we will need further 
internal discussion.
BTW, (2) use-cases, it seems your last sentence is truncated. Maybe a typo.

Thanks,
--Satya

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, July 27, 2023 at 4:36 PM
To: BESS mailto:bess@ietf.org>>
Cc: Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>>
Subject: [bess] Review of draft-ietf-bess-ebgp-dmz-03
Bess chairs:

The IDR WG was queried for a review of this document.  No responses were made.
I wrote an IDR chair review is contained on the IDR section of the IETF 
community wiki:
https://wiki.ietf.org/en/group/idr/draft-ietf-bess-ebgp-dmz


Summary:
The IDR chairs note that authors are discussing non-transitive and transitive 
extended communities for link bandwidth passed by BGP extended communities. We 
suggest that these efforts continue.   In this process, I have offered 
additional things the IDR chairs will review in these documents.  It is time to 
ensure "link bandwidth" uses are harmonized across BGP mechanisms (attributes 
or extended communities) and bgp-ls reporting.

As the reviewing IDR chair, I find the publication this document at this time 
is premature.  However, it is a useful input to the process.

The IESG while reviewing draft-ietf-idr-entropy-label for publication should 
consider how extended communities, the router capability attributes, and BGP-LS 
reporting aligns for link, router, and AS bandwidth.

I believe that the chairs of the WGs related to BGP and BGP-LS in IGPs should 
discuss this topic (e.g. IDR, BESS, Spring, LSVR, Grow, MPLS)

Sue

Full text
draft-ietf-bess-ebgp-dmz-03 IDR Chair review
Reviewer: Susan Hares
Issues with this draft:
1. Protocol Content

Four drafts deal with link bandwidth for a BGP router passed in an extended 
communities attribute or the entropy attribute outside of BGP-LS reporting.
a) draft-ietf-idr-link-bandwidth (a non-transitive extended community attribute)
b) draft-ietf-bess-ebgp-dmz-03 (a transitive extended community)
c) draft-ietf-entropy-label (router capability attribute)



Work is underway by the authors to harmonize the transitive and non-transitive 
use of the community.
Section 6 of draft-ietf-bess-ebgp-dmz-03 indicates a need for a refresh of 
draft-ietf-idr-link-bandwidth.

The IDR chairs suggest this work continues before publishing the use case found 
in this draft.

As part of this work, the authors should consider:
a) whether the description is a link, router, or AS bandwidth.
b) the ramifications of passing this information as
extended community or an attribute, and
c) how this relates to the BGP-LS definitions.

2. Use cases

The draft presents the following use cases:
a) large-scale dat

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

[MohanaSundari Muthusamy]

Dear BESS WG,

I support merging of the the drafts mentioned below.

Regards,
Mohana



On Thu, Jul 27, 2023 at 5:32 PM Gyan Mishra  wrote:

> 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
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> ___
> 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