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

2022-07-01 Thread "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, 25 July 2022, Session III 1500-1700
Room Name: Philadelphia North size: 100
-


iCalendar: https://datatracker.ietf.org/meeting/114/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 early afternoon, Wednesday late 
afternoon, Thursday late afternoon, Friday late afternoon

People who must be present:
  Andrew Alston
  Mankamana Prasad Mishra
  Matthew Bocci
  Stephane Litkowski

Resources Requested:

Special Requests:
  
-


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


[bess] Routing directorate "last call" review of draft-ietf-bess-evpn-virtual-eth-segment-07

2022-07-01 Thread Jon Hardwick
Document:  draft-ietf-bess-evpn-virtual-eth-segment-07
Reviewer: Jon Hardwick
Review Date: 1 July 2022
IETF LC End Date: N/A (last call has not been issued for this draft yet)
Intended Status: Standards Track

Summary:
I have some minor concerns (mostly editorial) about this document that I think 
should be resolved before publication. 

Comments:
---

Section 4.2 reads like a procedure but is light on normative language. In 
particular, I think this could be formalized better:

   The ESI label extended community ([RFC7432] Section 7.5) is not
   relevant to Grouping Ethernet A-D per ES.  The label value is NOT
   used for encalsulating BUM packets for any split-horizon function and
   the 'Single-Active' but is left as 0.

Are we saying that the label value in this extended community MUST be set to 
zero?  Or that the extended community SHOULD NOT be included in the update?  
What is meant by ".and the 'Single-Active'"?

NB Typo "encalsulating" in the above.

---

Section 5.2 (p17) "it is recommended to assign a B-MAC per vES and upon EVC 
failure" - should that be RECOMMENDED?

---

Section 5.3 - I think this whole section is normative, and so each statement 
should use normative language and the active voice.  For example:

BEFORE: "When a PE advertises an Ethernet A-D per ES route for a given
   vES, it is coloured as described in Section 4.2.1 using the
   physical port MAC by default."

AFTER: "The PE SHOULD colour each Ethernet A-D per ES route that it advertises 
for a given
   vES, as described in Section 4.2.1.  The PE SHOULD use the
   physical port MAC by default."

(I think that SHOULD is the appropriate strength of requirement here.)

---

Section 5.3 (p18) "the propagation if failure" -> "the propagation of failure"

---

Section 5.4 - Same comments apply about using normative language and the active 
voice (albeit this section already does that in some places).
Section 5.5 - Ditto.

---

Section 8 - IANA Considerations
I cannot find reference to this new extended community anywhere in the 
document. I note that it was present in earlier versions of the draft. Has the 
need for it been removed? If so, you should change this section to request to 
IANA that they remove the early allocation.

---

References: I think the reference to [I-D.ietf-bess-pbb-evpn-isid-cmacflush] is 
a normative reference.

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


Re: [bess] FW: Call for publication of draft-ietf-idr-segment-routing-te-policy-18 - with multiple partial implementations (6/17 to 6/30)

2022-07-01 Thread Zafar Ali (zali)
Hi Sue and the WG

I support publication of the draft (in its current form)
I am aware of implementations of the draft

Thanks

Regards … Zafar


From: BESS  on behalf of Susan Hares 
Date: Wednesday, June 29, 2022 at 6:45 PM
To: "spr...@ietf.org" , "bess@ietf.org" , 
"i...@ietf.org" 
Subject: [bess] FW: Call for publication of 
draft-ietf-idr-segment-routing-te-policy-18 - with multiple partial 
implementations (6/17 to 6/30)

Spring and BESS WGs

Just a reminder, if you wish to provide any feedback on IDR publication of
draft-ietf-idr-segment-routing-te-policy-18.txt, please do so before Friday 
6/30/2022.

The mail thread for IDR is at the following link.
https://mailarchive.ietf.org/arch/msg/idr/r8aWDJDWyWexgpLZagKaFrTePG8/

At this time, as the IDR shepherd for this draft,
the consensus is that the IDR will forward the draft to the IESG on Friday.

Please do not reply to this email.  You can comment on the original IDR thread 
or
or send email directly (sha...@ndzh.com or 
idr-cha...@ietf.org).

Cheers, Sue

-

From: Susan Hares
Sent: Friday, June 17, 2022 9:15 AM
To: i...@ietf.org
Subject: Call for publication of draft-ietf-idr-segment-routing-te-policy-18 - 
with multiple partial implementations (6/17 to 6/30)


IDR:

This is a 2 week call for approval for publication of
draft-ietf-idr-segment-routing-te-policy-18
(https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-18).

This draft has past WG LC, and it has been implemented by five separate 
commercial vendors.
(I  do not have any implementation reports from open-source vendors.)

According to the implementation report, not all
features have been implemented.
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-segment-routing-te-policy%20implementations%20

At this point, it appears we do not have 2 implementations
Supporting the following TLV codes:

-  ENLP sub-TLV (code 14)

-  Priority sub-TLV (code 15)

-  SRv6 Binding SID (code 20)

-  Policy Candidate Path Name sub-TLV (code 129), and

-  Policy Name Sub-TLV (code 130).


And only segment types A and B out of types A-K have been implemented.

Should the IDR WG:
a) publish this draft as is,
b) put it in a “awaiting implementations” hold until more features are 
implemented,
c) remove unimplemented features and publish?

If you are an implemented (open-source or commercial), please
Update your implementation status on the implementation page
Or send me a note regarding your implementation.

Cheers, Sue


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