Re: [bess] few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014

[Dikshit, Saumya]

Kindly help on the queries below

Regards,
Saumya/

From: Dikshit, Saumya
Sent: Friday, February 16, 2024 7:23 AM
To: Dikshit, Saumya ; BESS ; Jorge 
Rabadan (Nokia) 
Cc: bess-cha...@ietf.org
Subject: RE: few queries regarding rfc9014 : 
https://datatracker.ietf.org/doc/html/rfc9014

Gentle reminder to authors or anyone who can answer.

Regards,
Saumya.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Tuesday, February 13, 2024 5:20 PM
To: BESS mailto:bess@ietf.org>>; Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess-cha...@ietf.org
Subject: [bess] few queries regarding rfc9014 : 
https://datatracker.ietf.org/doc/html/rfc9014

Hello Authors of 
https://datatracker.ietf.org/doc/html/rfc9014

I have few queries specifically on the "UMR" and "arp/nd flooding control" and 
might be inter-related
 https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.1
  MAC Address Advertisement 
 Control
Host1-NVE1-PE1-(WAN)-PE2-NVE2Host2
For realization of UMR usage, does the logic entails that

*   the end-host (host1) shall learn the remote-hosts (host2) MAC and IP 
(in a remote DC/fabric/site for same-subnet) over data-plane via normal flood 
and learn via typical APR request/response; and

othe eventual data flow from host1 to the host2 shall hits the UMR on NVE1 
(first hop Vtep)

*   the first-hop vtep (NVE1) will not learn the MAC bindings over Control 
plane from the PE1

o   as the PE1 will publish only UMR in place of all remote MACs hosted in 
remote DC/fabric/site. ?

*   This shall also mandate proxy-arp functionality on PE1 for the requests 
arising from the hosts (host1) in attached DC,

o   else request for same credentials (host2) shall flood the WAN from other 
attached hosts to the fabric.
Or there is something more to it.
 https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.2:
  ARP/ND Flooding 
 Control
The ARP/ND queries should also be proxied by PE's (PE1 and PE2) to the request 
generated from inside the attached DC/fabric, as it will save on flooding over 
WAN.
Anyways, PE shall absorb all the remote fabric info (RT-2's from remote 
fabrics) to realize UMR and shall avoid relaying it to the attached fabric/DC.

Any thoughts on above shall be great.

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

[bess] [Technical Errata Reported] RFC9252 (7817)

[RFC Errata System]

The following errata report has been submitted for RFC9252,
"BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7817

--
Type: Technical
Reported by: Ketan Talaulikar 

Section: 3.2.1

Original Text
-
   As defined in [RFC8986], the sum of the Locator Block Length (LBL),
   Locator Node Length (LNL), Function Length (FL), and Argument Length
   (AL) fields MUST be less than or equal to 128 and greater than the
   sum of Transposition Offset and Transposition Length.

Corrected Text
--
   As defined in [RFC8986], the sum of the Locator Block Length (LBL),
   Locator Node Length (LNL), Function Length (FL), and Argument Length
   (AL) fields MUST be less than or equal to 128 and greater than or
   equal to the sum of Transposition Offset and Transposition Length.

Notes
-
The sum of Trans Off and Trans Length can be equal to the LBL+LNL+FL+AL when 
the last part of the SID (function or argument) is getting transposed.

This is clear also from the example below in the next paragraph of the same 
section:

   As an example, consider that the sum of the Locator Block and the
   Locator Node parts is 64.  For an SRv6 SID where the entire Function
   part of size 16 bits is transposed, the transposition offset is set
   to 64 and the transposition length is set to 16.  While for an SRv6
   SID for which the FL is 24 bits and only the lower order 20 bits are
   transposed (e.g., due to the limit of the MPLS Label field size), the
   transposition offset is set to 68 and the transposition length is set
   to 20.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC9252 (draft-ietf-bess-srv6-services-15)
--
Title   : BGP Overlay Services Based on Segment Routing over IPv6 
(SRv6)
Publication Date: July 2022
Author(s)   : G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. 
Decraene, S. Zhuang, J. Rabadan
Category: PROPOSED STANDARD
Source  : BGP Enabled ServiceS
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

[bess] please submit presentation request for IETF 119

[Mankamana Mishra (mankamis)]

All,
The preliminary agenda is ported, please send me a request for the slot.

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