[bess] bess - Requested session has been scheduled for IETF 118

["IETF Secretariat"]

Dear Mankamana Mishra,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


bess Session 1 (2:00 requested)
Monday, 6 November 2023, Session II 1300-1500 Europe/Prague
Room Name: Congress Hall 2 size: 350
-


iCalendar: https://datatracker.ietf.org/meeting/118/sessions/bess.ics

Request Information:


-
Working Group Name: BGP Enabled ServiceS
Area Name: Routing Area
Session Requester: Mankamana Mishra


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 100
Conflicts to Avoid: 

   


Participants who must be present:
  Mankamana Prasad Mishra

Resources Requested:

Special Requests:
  
-


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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Matthew Bocci (Nokia)]

Authors, Working Group,

I would like to gauge the consensus of the group on the question below about 
the draft updating 8584. The meaning of “updates” is perhaps a little 
ambiguous, and the interpretation I had used when suggesting that we should 
mark the draft as updating 8584 was that it makes some changes to the 
procedures in 8584. Specifically, these changes are described in the 
introduction section of the draft, as follows:

“This document updates the state machine described in Section 2.1 of
   [RFC8584], by optionally introducing delays between some events, as
   further detailed in Section 2.2.  The solution is based on a simple
   one-way signaling mechanism.”


Are there any concerns about interoperability between a 8584-only compliant 
implementation, and one that also implements 
draft-ietf-bess-evpn-fast-df-recovery?

Thanks

Matthew



From: Luc Andre Burdet (lburdet) 
Date: Monday, 10 July 2023 at 19:46
To: Adrian Farrel , rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi Adrian,

Thank you for your valuable comments, and apologies for the late reply/update. 
I have incorporated all changes into -v08 which I hope address your feedback: 
some comments are replied to below:


I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

[LAB] It is worth noting that the delay introduced (change to 8584) is by 
default 0 i.e. no change to RFC8584 when the extcomm is not present.
An implementation which does not support this adding a delay of 0 and one 
supporting it but with a delay of 0 would display similar behaviours ?  I can 
defer to Matthew and the WG on this.


Why bit 3? I know the answer is "because that's the bit our
implementation uses" and I'm fine with that and I'm not asking for any
change, but it makes me suspicious about what happened to bits 0 and 2.
Why aren't they used? Is someone squatting on them?

[LAB] yes bits 0 and 2 are in-use already for Preference-Based DF indication;  
Bit 2 is iirc from an old version of this document which was also requesting a 
H=handshake bit, no longer is.  We felt it best to just leave this one at 3 
instead of shifting down. (Bit 5 is also in-use for Port-Mode in another 
document)



I see some challenges here.
The first is when a PE joins the segment while DF election is ongoing
among the other PEs.
The second is what happens if the SCT BGP extended community is present
when the T-bit is not set.
The third is what happens if the T-bit is set but no SCT BGP extended
community is provided.
All of these are easy to describe.

Does the backwards compatibility not describe these already i.e. “SHALL revert 
back to 7432” ?

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Adrian Farrel via Datatracker 
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Reviewer: Adrian Farrel
Review result: Has Issues

Hello

I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery. I
reviewed revision -07.

The Routing Directorate will, on request from the working group chair, perform
an early review of a draft before it is submitted for publication to the IESG.
The early review can be performed at any time during the draft's lifetime as a
working group document. The purpose of the early review depends on the stage
that the document has reached.

I reviewed revision -07 of this draft after the completion of WG last call and
shepherd review, but before the WG makes a publication request. The purpose of
a review at this stage is to improve the quality before AD review and so reduce
the AD workload as wellas improve the output of the working group and the final
quality of any published RFCs.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-bess-evpn-fast-df-recovery-07.txt
Reviewer: Adrian Farrel
Review Date: 2023-05-27
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the AD.

This document is short and 

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Matthew Bocci (Nokia)]

WG

Thanks for reviewing the draft. Note that it appears that the original adoption 
call on v16 on 5th October, and the authors updating the draft to v17 on 5th 
November seem to have crossed. The only differences between the versions are 
updating an informative reference to a newer version of 
draft-ietf-idr-sdwan-edge-discovery, and changing another informative reference 
to MEF3.0 to IEEE802.3. I did not see any other comments that required changes, 
so I believe there is consensus to adopt the draft.

Matthew

From: Matthew Bocci (Nokia) 
Date: Thursday, 5 October 2023 at 11:45
To: bess@ietf.org 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 

Subject: WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16
WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

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

This poll will close on Thursday 12th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network 
providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess