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

["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)
Thursday, 27 July 2023, Session I 0930-1130 America/Los_Angeles
Room Name: Continental 4 size: 200
-


iCalendar: https://datatracker.ietf.org/meeting/117/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: 

   
 Can't meet: Monday late afternoon, Tuesday late afternoon, Wednesday late 
afternoon, Thursday late afternoon, Friday late afternoon

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

[bess] Genart last call review of draft-ietf-bess-pbb-evpn-isid-cmacflush-07

[Joel Halpern via Datatracker]

Reviewer: Joel Halpern
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-pbb-evpn-isid-cmacflush-07
Reviewer: Joel Halpern
Review Date: 2023-06-30
IETF LC End Date: 2023-07-11
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard.

reviewers note: My thanks to the authors / editors for a very helpful
introduction that made clear the problem to be solved.

Major issues: N/A

Minor issues:
I got a bit confused in section 3, where the text says:
All the other fields are set and used as defined in [RFC7623]. This document
will refer to this route as the BMAC/I-SID route, as opposed to the [RFC7623]
BMAC/0 route (BMAC route sent with Ethernet Tag ID = 0).
I got confused because when I went to RFC 7623, I could not find the string
BMAC/0, and while I tried searching for related terms, I could not find
what term is being distinguished.  The string BMAC does not occur in RFC
7623.  So this and later (e.g. 4.1) references to 7623 use of BMAC/0 is
confusing.

Nits/editorial comments: N/A


___
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)]

Adrian

Thanks for the RTGDir review.

Authors: Please can you look at the review and address Adrian’s comments.

Regards

Matthew

From: Adrian Farrel via Datatracker 
Date: Saturday, 27 May 2023 at 20: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

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.



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 readable. While most of what I found is nits, they
somewhat detract from the clarity of the document. The minor points could do
with small additions to the text to help the reader and smooth the document's
passage through the IESG.

===

Abstract should note that this document updates RFC 8584 and say
(briefly) how. (Note that idnits warned you about this.)

I would put similar text in the Introduction, but that text can have a
pointer to Section 2.2).

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.

---

Abstract

Move "(DF)" to the first use of "Designated Forwarder"

Please expand "EVI" and "PE"

s/via a simple signaling/via simple signaling/

---

Move the requirements language into a new Section 1.1

Please use the correct version of the boilerplate text...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

---

1.

Please expand "DF", "EVI", and "PE" on first use.

s/applying Highest/applying the Highest/
s/independent of number/independent of the number/
s/via a simple signaling/via simple signaling/
s/on simple one-way signaling/on a simple one-way signaling/

---

1.2

s/in redundancy group/in a redundancy group/

---

1.2

The RFC Editor will ask you to consider another term in place of
"blackholing". You might choose to retain the term, or you might
think that it is OK to say "packets being dropped if the timer is
too long"

There are quite a few similar uses throughout the document.

---

1.2

   upon re-entry of the packet

I think you mean, "upon the packet re-entering the Ethernet Segment"

---

1.3.

This section is a bit messy because it talks about the "proposed
solution" in text that will eventually become an RFC, and because it
makes cryptic references to mechanisms that have not yet been described.

I am not convinced that you actually need this text (why are you trying
to sell the benefits having already told us there is a problem to be
solved?) but if you want to keep the text, I would suggest that you
position it as "design principles" and scale it right back. Something
like...

1.3.  Design Priniciples for a Solution

   The solution presented in this document follows several design
   pronciples as follows.

   *  Complicated handshake signamling mechanisms and state machines are
  avoided in favor of a simple uni-directional signaling approach.

   *  The solution is backwards-compatible (see Section 4).

   *  Existing DF Election algorithms are supported.

   *  The solution is independent of 

[bess] Genart last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

[Russ Housley via Datatracker]

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-mvpn-evpn-aggregation-label-10
Reviewer: Russ Housley
Review Date: 2023-06-30
IETF LC End Date: 2023-07-12
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns: None.


Minor Concerns:

Section 2.2: Please provide more discussion of "central authority".  I
do not think that a Internet-wide authority is required to meet this
requirement.  I think that the authority needs to be recognized
throughout a provider network.


Nits:

Section 1: please avoid splitting "I/S-PMSI" across multiple lines.

Section 2: s/ingress PE's default label space/default label space/

Section 2: s/packet's ingress PE/ingress PE of the packet/

Section 2.2.2.1: s/Route-2 respectively/Route-2, respectively/

Section 3.2: s/PTA's Label field/label field of the PTA/

Section 3.2: s/source PE's label space/label space of the source PE/

Section 4: s/third party's label space/label space of a third party/ (2 places)

Section 4: please spell out "LFIBs"; this term is not in the definitions.


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

Re: [bess] Please send slot request for BESS IETF 117

[Gyan Mishra]

Hi Mankamana

I would like to request a 10 minute slot for the two drafts below:

IPv4 Only PE Design ALL SAFI
https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/

IPv6 Only PE Design ALL SAFI
https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/

Thank you

Gyan


On Fri, Jun 30, 2023 at 10:32 AM Mankamana Mishra (mankamis)  wrote:

> All,
>
> Primary agenda has been posted. Please send me slot request for IETF 117.
>
>
>
> Mankamana
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 



*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] Please send slot request for BESS IETF 117

[Mankamana Mishra (mankamis)]

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

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