[bess] Re: Fwd: I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt

[Gyan Mishra]

in the draft given the reasons I stated
> above.  Also we can make crystal clear that the goal is broader
> applicability.
>

>
> Btw you may want to look at the references for this document. When running
> the idnits tool there are errors found:
>
>
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-v4-v6-pe-all-safi-01.txt
>
>  Gyan>  I will fix in next revision
>
Many Thanks!

>   Checking references for intended status: Proposed Standard
>
>
> 
>
>
>
>  (See RFCs 3967 and 4897 for information about using normative
> references
>
>  to lower-maturity documents in RFCs)
>
>
>
>   == Unused Reference: 'I-D.ietf-bess-bgp-multicast' is defined on line
> 1855,
>
>  but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-bess-ipv6-only-pe-design' is defined on
> line
>
>  1863, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-bgp-car' is defined on line 1871, but
> no
>
>  explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-flowspec-nvo3' is defined on line
> 1878,
>
>  but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-rpd' is defined on line 1886, but no
>
>  explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-sdwan-edge-discovery' is defined on
> line
>
>  1894, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined
> on
>
>  line 1902, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-l3vpn-bgpvpn-auto' is defined on line
> 1910,
>
>  but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-lsvr-bgp-spf' is defined on line 1917, but
>
>  no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.mpmz-bess-mup-safi' is defined on line 1932,
> but
>
>  no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4291' is defined on line 1956, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4364' is defined on line 1960, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4761' is defined on line 1969, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC5492' is defined on line 1979, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC8277' is defined on line 2018, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC9015' is defined on line 2038, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 2046,
>
>  but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4659' is defined on line 2053, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4798' is defined on line 2065, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4925' is defined on line 2071, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC5549' is defined on line 2076, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC5565' is defined on line 2081, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC6074' is defined on line 2085, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC6513' is defined on line 2091, but no explicit
>
>  reference was found in the text
>
>
>
>   == Unused Reference: 'RFC8126' is defined on line 2100, but no explicit
>
>  reference was found in the text
>
>
>
>   ** Downref: Normative reference to an Experimental draft:
>
>  draft-ietf-idr-bgp-car (ref. 'I-D.ietf-idr-bgp-car')
>
>
>
>   ** Downref: Normative referenc

[bess] Fwd: I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt

[Gyan Mishra]

s 4 byte field for IPv4 next hop address for Unicast SAFI
1, Multicast SAFI2 and BGP-LU SAFI 4, and 12 byte next hop field, 4
byte IPv4 address plus 8 byte RD (Route Distinguisher) set to 0 for
VPN SAFI 128, MVPN SAFI 129.
   - This draft standardizes that encoding to ensure interoperability
with IANA BGP Capability codepoint allocation thus providing parity
between the RFC 5549/RFC 8950 IPv6 next hop encoding where the next
hop address follows the underlay core which is an IPv6 core and how
the next hop here being an IPv6 address and not following the NLRI
with IPv6 mapped IPv4 address.  Now with this draft the next hop
encoding follows the  underlay core which is an IPv4 core and so now
the next hop being an IPv4 address and not following the NLRI with an
IPv4 mapped IPv6 address.  So this parity between IPv4 next encoding
and IPv6 next hop encoding savings in OPEX and operations
troubleshooting as well as interoperability that all vendor
implementations now use the same IPv4 next hop encoding is the reason
the encoding must be standardized.
   - This IPv4 next hop encoding is applicable for IPv6 NLRI for both
iBGP control plane (CP) peering as well as eBGP PE-CE, PE-PE in-line
control / data plane (CP-DP) peering which is used for IPv4-Only PE
design.
   - Completed research on vendors using IPv4 mapped IPv6 address
versus IPv4 next hop and within the same vendor in many cases with the
same SAFI I have even noticed a mix of both options in the RIB and FIB
programming which this standardization to use IPv4 next hop will
cleanup discrepancies even within the same vendor on the same
platforms as well as all platforms across all vendors.

   IANA BGP Capability - New codepoint for IPv4 Next hop encoding

   https://www.iana.org/assignments/capability-codes/capability-codes.xhtml

   We will plan to have one of the 4 vendors add the IPv4 next hop encoding
   implemented prior to WGLC.


Thank you


Gyan


-- Forwarded message -
From: 
Date: Mon, Jul 29, 2024 at 2:11 AM
Subject: [bess] I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt
To: 
Cc: 


Internet-Draft draft-ietf-bess-v4-v6-pe-all-safi-01.txt is now available. It
is a work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI
   Authors: Gyan Mishra
Sudha Madhavi
Adam Simpson
Mankamana Mishra
Jeff Tantsura
Shuanglong Chen
   Name:draft-ietf-bess-v4-v6-pe-all-safi-01.txt
   Pages:   54
   Dates:   2024-07-28

Abstract:

   As Enterprises and Service Providers upgrade their brown field or
   green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-
   BGP)now plays an important role in the transition of their Provider
   (P) core network as well as Provider Edge (PE) Inter-AS peering
   network from IPv4 to IPv6.  Operators must have flexiblity to
   continue to support IPv4 customers when both the Core and Edge
   networks migrate to IPv6.  As well as must be able to support IPv6
   networks in cases where operators decide to remain on an IPv4 network
   or during transition.

   This document details the External BGP (eBGP) PE-PE Inter-AS and PE-
   CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all
   supported SAFI NLRI can be advertised over a single IPv4 peer and
   IPv6-Only PE Design where all supported SAFI NLRI can be advertised
   over a single IPv6 peer.

   This document also defines a new IPv4 BGP next hop encoding standard
   that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6
   address.

   This document also provides vendor specific test cases for the
   IPv4-Only peering design and IPv6-Only PE design as well as test
   results for the four major vendors stakeholders in the routing and
   switching indusrty, Cisco, Juniper, Nokia and Huawei.  With the test
   results provided for the IPv6-Only Edge peering design, the goal is
   that all other vendors around the world that have not been tested
   will begin to adopt and implement the design.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-v4-v6-pe-all-safi/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-v4-v6-pe-all-safi-01

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-v4-v6-pe-all-safi-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org


-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

[Gyan Mishra]

Hi Chongfeng

I thought about this drafts use case a bit further and I AFAIK secure EVPN
draft is the solution that exists for this type of use case where you have
disparate EVPN PE gateways.

Since you can build a eBGP multihop tunnel for the control plane typically
done for OTT overlay EVPN for BGP Only DC over L3 core the same concept can
be applied here for your use case over public Internet and can use secure
EVPN.

https://datatracker.ietf.org/doc/draft-sajassi-bess-secure-evpn/


Kind Regards


Gyan
On Sat, Jul 27, 2024 at 1:35 AM Gyan Mishra  wrote:

> Hi Chongfeng
>
> To expand on the use case for the disparate network PEs is the they have
> IPv6 connectivity between them so could be remote PE gateways under their
> admin control however all intermediate nodes are outside their admin
> control. Data plane stitch even without overlay stitch does require some
>  trust level.  Also generally if you are able to stitch data plane more
> then likely trust level is such that  you can extend the overlay as well.
>
> This is a good use case for SRv6 Compression C-SID Nexf SID (uSID)  which
> allows you to use IPv6 data plane to stitch so can stitch seamlessly and
> the other side does not have to be aware and can blindly forward the
> packets.
>
> So the situation use case is interesting but I think corner case.
>
> Kind Regards
>
> Gyan
>
>
> On Fri, Jul 26, 2024 at 11:59 PM Gyan Mishra 
> wrote:
>
>>
>> Hi Chongfeng
>>
>> This is a very intriguing solution.
>>
>> The use case for this solution is EVPN L2 stretch  over the internet or
>> disparate IP networks that could be in the same OAD admin domain and have
>> IP connectivity between disparate PEs but do not have the availability to
>> natively extend the EVPN control plane but are able to stitch the data
>> plane.
>>
>> I think if you are able to extend EVPN control plane natively then you
>> would do regular EVPN but if you cannot then you are stuck and this
>> solution fills that gap.
>>
>> I guess there could be case of a Telco cloud providet with hybrid cloud
>> on prem and off prem DC CSP cloud provider through a CXP POP and now this
>> could be method of providing L2 stretch of data plane via EVN6 control
>> plane.
>>
>> With the procedure once the tunnel is established at the beginning once
>> the dynamic mapping happens would you not need DF election ?
>>
>> Since this is all new procedures from RFC 7432 and RFC 8365 base RFCs
>> would you have to write the entire new EVPN control plane procedures.  For
>> example how would RFC 9135 inter subnet forwarding work?
>>
>> Very nice indeed!
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>> On Fri, Jul 26, 2024 at 12:52 AM Chongfeng Xie 
>> wrote:
>>
>>>
>>> Hello everyone,
>>> We have submitted a new draft on "EVPN Route Types and Procedures for
>>> EVN6" to BESS WG,  it proposes extensions to EVPN for EVN6. EVN6 is a
>>> Layer-2 network model built on top of the IPv6 underlay to provide
>>> connectivity between dispersed customer sites, the draft of EVN6 has been
>>> presented in Intarea and v6ops WGs.  We are looking forward to your review
>>> and comments to this new draft.
>>> Thanks.
>>>
>>> Best regards
>>> Chongfeng
>>>
>>>
>>> *From:* 【外部账号】 
>>> *Date:* 2024-07-26 12:25
>>> *To:* Chongfeng Xie ; Guoliang Han
>>> ; Jibin Sun ; Xing
>>> Li 
>>> *Subject:* New Version Notification for
>>> draft-xie-bess-evpn-extension-evn6-00.txt
>>> A new version of Internet-Draft
>>> draft-xie-bess-evpn-extension-evn6-00.txt has
>>> been successfully submitted by Chongfeng Xie and posted to the
>>> IETF repository.
>>>
>>> Name: draft-xie-bess-evpn-extension-evn6
>>> Revision: 00
>>> Title:EVPN Route Types and Procedures for EVN6
>>> Date: 2024-07-25
>>> Group:Individual Submission
>>> Pages:13
>>> URL:
>>> https://www.ietf.org/archive/id/draft-xie-bess-evpn-extension-evn6-00.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-xie-bess-evpn-extension-evn6/
>>> HTMLized:
>>> https://datatracker.ietf.org/doc/html/draft-xie-bess-evpn-extension-evn6
>>>
>>>
>>> Abstract:
>>>
>>>EVN6 is a mechanism designed to carry Ethernet virtual networks,
>>>providing Ethernet connectivity to customer sites dispersed on public
>>>IPv6 networks.  At the data layer, EVN6 directly places the Ethernet
>>>frames in the payload of IPv6 packet, and dynamically generates the
>>>IPv6 addresses of the IPv6 header using host MAC addresses and other
>>>information, then sends them into IPv6 network for transmission.
>>>This document proposes extensions to EVPN for EVN6, including two new
>>>route types and related procedures.
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>>
>>> ___
>>> BESS mailing list -- bess@ietf.org
>>> To unsubscribe send an email to bess-le...@ietf.org
>>>
>>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

[Gyan Mishra]

Hi Chongfeng

To expand on the use case for the disparate network PEs is the they have
IPv6 connectivity between them so could be remote PE gateways under their
admin control however all intermediate nodes are outside their admin
control. Data plane stitch even without overlay stitch does require some
 trust level.  Also generally if you are able to stitch data plane more
then likely trust level is such that  you can extend the overlay as well.

This is a good use case for SRv6 Compression C-SID Nexf SID (uSID)  which
allows you to use IPv6 data plane to stitch so can stitch seamlessly and
the other side does not have to be aware and can blindly forward the
packets.

So the situation use case is interesting but I think corner case.

Kind Regards

Gyan


On Fri, Jul 26, 2024 at 11:59 PM Gyan Mishra  wrote:

>
> Hi Chongfeng
>
> This is a very intriguing solution.
>
> The use case for this solution is EVPN L2 stretch  over the internet or
> disparate IP networks that could be in the same OAD admin domain and have
> IP connectivity between disparate PEs but do not have the availability to
> natively extend the EVPN control plane but are able to stitch the data
> plane.
>
> I think if you are able to extend EVPN control plane natively then you
> would do regular EVPN but if you cannot then you are stuck and this
> solution fills that gap.
>
> I guess there could be case of a Telco cloud providet with hybrid cloud on
> prem and off prem DC CSP cloud provider through a CXP POP and now this
> could be method of providing L2 stretch of data plane via EVN6 control
> plane.
>
> With the procedure once the tunnel is established at the beginning once
> the dynamic mapping happens would you not need DF election ?
>
> Since this is all new procedures from RFC 7432 and RFC 8365 base RFCs
> would you have to write the entire new EVPN control plane procedures.  For
> example how would RFC 9135 inter subnet forwarding work?
>
> Very nice indeed!
>
> Kind Regards
>
> Gyan
>
>
> On Fri, Jul 26, 2024 at 12:52 AM Chongfeng Xie 
> wrote:
>
>>
>> Hello everyone,
>> We have submitted a new draft on "EVPN Route Types and Procedures for
>> EVN6" to BESS WG,  it proposes extensions to EVPN for EVN6. EVN6 is a
>> Layer-2 network model built on top of the IPv6 underlay to provide
>> connectivity between dispersed customer sites, the draft of EVN6 has been
>> presented in Intarea and v6ops WGs.  We are looking forward to your review
>> and comments to this new draft.
>> Thanks.
>>
>> Best regards
>> Chongfeng
>>
>>
>> *From:* 【外部账号】 
>> *Date:* 2024-07-26 12:25
>> *To:* Chongfeng Xie ; Guoliang Han
>> ; Jibin Sun ; Xing
>> Li 
>> *Subject:* New Version Notification for
>> draft-xie-bess-evpn-extension-evn6-00.txt
>> A new version of Internet-Draft draft-xie-bess-evpn-extension-evn6-00.txt
>> has
>> been successfully submitted by Chongfeng Xie and posted to the
>> IETF repository.
>>
>> Name: draft-xie-bess-evpn-extension-evn6
>> Revision: 00
>> Title:EVPN Route Types and Procedures for EVN6
>> Date: 2024-07-25
>> Group:Individual Submission
>> Pages:13
>> URL:
>> https://www.ietf.org/archive/id/draft-xie-bess-evpn-extension-evn6-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-xie-bess-evpn-extension-evn6/
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-xie-bess-evpn-extension-evn6
>>
>>
>> Abstract:
>>
>>EVN6 is a mechanism designed to carry Ethernet virtual networks,
>>providing Ethernet connectivity to customer sites dispersed on public
>>IPv6 networks.  At the data layer, EVN6 directly places the Ethernet
>>frames in the payload of IPv6 packet, and dynamically generates the
>>IPv6 addresses of the IPv6 header using host MAC addresses and other
>>information, then sends them into IPv6 network for transmission.
>>This document proposes extensions to EVPN for EVN6, including two new
>>route types and related procedures.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> ___
>> BESS mailing list -- bess@ietf.org
>> To unsubscribe send an email to bess-le...@ietf.org
>>
>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

[Gyan Mishra]

Hi Chongfeng

This is a very intriguing solution.

The use case for this solution is EVPN L2 stretch  over the internet or
disparate IP networks that could be in the same OAD admin domain and have
IP connectivity between disparate PEs but do not have the availability to
natively extend the EVPN control plane but are able to stitch the data
plane.

I think if you are able to extend EVPN control plane natively then you
would do regular EVPN but if you cannot then you are stuck and this
solution fills that gap.

I guess there could be case of a Telco cloud providet with hybrid cloud on
prem and off prem DC CSP cloud provider through a CXP POP and now this
could be method of providing L2 stretch of data plane via EVN6 control
plane.

With the procedure once the tunnel is established at the beginning once the
dynamic mapping happens would you not need DF election ?

Since this is all new procedures from RFC 7432 and RFC 8365 base RFCs would
you have to write the entire new EVPN control plane procedures.  For
example how would RFC 9135 inter subnet forwarding work?

Very nice indeed!

Kind Regards

Gyan


On Fri, Jul 26, 2024 at 12:52 AM Chongfeng Xie 
wrote:

>
> Hello everyone,
> We have submitted a new draft on "EVPN Route Types and Procedures for
> EVN6" to BESS WG,  it proposes extensions to EVPN for EVN6. EVN6 is a
> Layer-2 network model built on top of the IPv6 underlay to provide
> connectivity between dispersed customer sites, the draft of EVN6 has been
> presented in Intarea and v6ops WGs.  We are looking forward to your review
> and comments to this new draft.
> Thanks.
>
> Best regards
> Chongfeng
>
>
> *From:* 【外部账号】 
> *Date:* 2024-07-26 12:25
> *To:* Chongfeng Xie ; Guoliang Han
> ; Jibin Sun ; Xing
> Li 
> *Subject:* New Version Notification for
> draft-xie-bess-evpn-extension-evn6-00.txt
> A new version of Internet-Draft draft-xie-bess-evpn-extension-evn6-00.txt
> has
> been successfully submitted by Chongfeng Xie and posted to the
> IETF repository.
>
> Name: draft-xie-bess-evpn-extension-evn6
> Revision: 00
> Title:EVPN Route Types and Procedures for EVN6
> Date: 2024-07-25
> Group:Individual Submission
> Pages:13
> URL:
> https://www.ietf.org/archive/id/draft-xie-bess-evpn-extension-evn6-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xie-bess-evpn-extension-evn6/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-xie-bess-evpn-extension-evn6
>
>
> Abstract:
>
>EVN6 is a mechanism designed to carry Ethernet virtual networks,
>providing Ethernet connectivity to customer sites dispersed on public
>IPv6 networks.  At the data layer, EVN6 directly places the Ethernet
>frames in the payload of IPv6 packet, and dynamically generates the
>IPv6 addresses of the IPv6 header using host MAC addresses and other
>information, then sends them into IPv6 network for transmission.
>This document proposes extensions to EVPN for EVN6, including two new
>route types and related procedures.
>
>
>
> The IETF Secretariat
>
>
>
>
> ___
> BESS mailing list -- bess@ietf.org
> To unsubscribe send an email to bess-le...@ietf.org
>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: [Idr] Re: Do we need yet another link bandwidth community?

[Gyan Mishra]

All

I think has been a great effort by all authors involved over many years in
trying to encode link bandwidth to be carried in BGP for weighted UCMP load
balancing.

Many thanks to all the authors on your work!

Here is some history on all of these drafts below and my take on possible
path forward and which drafts could be combined.

All of these drafts I agree should be consolidated into a a single draft
single source or truth.  However some may or may not be possible due to
need for backwards compatibility for what has already been deployed as well
as some drafts are similar but different enough that could remain as a
separate draft.

Applies to all AFI/SAFI

2009 standards track
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07

Original draft was adopted by most all vendors Cisco, Juniper, Nokia etc

Extended community HO/LO byte type / sub type 0x4/0x4, global
administrative (AS_TRANS) local administrative - bandwidth

Bandwidth is expressed in bytes floating point format in bytes/second

Gap - non transitive only advertised intra-as

2022 informational introduces knob for transitive
https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/

Supports  transitive and non transitive extended to eBGP peering aggregate
link bandwidth cumulative bandwidth across the internal iBGP paths to build
the aggregate weight and regenerated when advertised over eBGP peering.

Since the original draft has been implemented by many vendors both non
transitive so now both would be supported sub TLV  0x0004 and transitive
0x4004 via vendor specific knob

2021 standards track

https://datatracker.ietf.org/doc/draft-li-idr-link-bandwidth-ext/02/

Bandwidh expressed as unsigned integer
Supports transitive and non transitive
Extended community sub type is same as original draft and global
administrative is ASN and local administrative is bandwidth

More discrete unit bandwidth values for bps,kbs etc using unsigned integer

2024 standards track
https://datatracker.ietf.org/doc/html/draft-xu-idr-fare-01

Path bandwidth extended community for adaptive routing for AI workloads and
signals minimum bandwidth path towards a destination.
New IPv4 specific address community that can be transitive or non
transitive.

Extended community HO/LO TLV/Sub TLV is 0x01 or 0x/41 , sub TLV / LO is TBD

Global Administrative is router id of advertising router similar to type-1
 extended community and local administrative contains the path bandwidth in
floating point format units GB/s


EVPN AFI/SAFI specific W-UCMP

 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb

EVPN load balancing and routed and BUM traffic
distributed DF election distribution for a given ES for multi homed PE in
proportion to PE-CE link bandwidth and uses the two DF election algorithms
HRW or highest preference.
-Introduces new link bandwidth extended community bandwidth encoded as
unsigned integer MB/s unit value encoded as weight for ucmp load balancing.

Summary:
There is some backwards compatibility to take into account on the original
dmz and cumulative which are in alignment and can be easily combined.

The other remaining drafts except path bandwidth could be combined into a
net new draft with agreement on units to use unsigned integer.

I think the path bandwidth procedure and objective is different enough that
I would keep as separate draft.

Kind Regards

Gyan




On Wed, Jul 24, 2024 at 10:02 PM Ketan Talaulikar 
wrote:

> Hi Reshma,
>
> Glad to see that we are in agreement to avoid another LBW extcomm.
>
> One of the points that I was trying to make is that we don't have a
> "single source of truth" if we look at this more holistically from BGP
> protocol perspective. We have two that have been implemented and deployed
> (even if for different address families).
>
> Let's work this out keeping the full and broader picture in mind.
>
> Thanks,
> Ketan
>
> On Wed, 24 Jul, 2024, 6:00 pm Reshma Das,  wrote:
>
>> Hi Ketan,
>>
>>
>>
>> I agree we don’t need yet another new draft to carry LBW community.
>>
>>
>>
>> As we know the base draft(draft-ietf-idr-link-bandwidth) is being revived
>> to support both transitive and non-transitive use cases. This was presented
>> in Mondays IDR session: (https://www.youtube.com/watch?v=ePPCAPOSQfM).
>>
>>
>>
>> It is worth updating the base draft as a single source of truth to
>> accommodate all use cases. That provides the most interop.
>>
>>
>>
>> Since this is an effort initiated by IDR chairs, you are more than
>> welcome to contribute to this effort as part the IDR WG.
>>
>>
>>
>> Thanks & Regards,
>> Reshma Das
>>
>>
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From: *Ketan Talaulikar 
>> *Date: *Wednesday, July 24, 2024 at 2:57 PM
>> *To: *idr@ietf. org ,
>> draft-li-idr-link-bandwidth-...@ietf.org <
>> draft-li-idr-link-bandwidth-...@ietf.org>
>> *Cc: *BESS 
>> *Subject: *[Idr] Do we need yet another link bandwidth community?
>>
>> *[External Email. Be cautious of content

[bess] Re: Initial agenda for BESS

[Gyan Mishra]

Thank you!

Gyan



On Mon, Jul 22, 2024 at 1:31 PM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> Hi Gyan
>
>
>
> That should be fine.
>
>
>
> Matthew
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, 18 July 2024 at 08:11
> *To: *Mankamana Mishra (mankamis) 
> *Cc: *bess@ietf.org 
> *Subject: *[bess] Re: Initial agenda for BESS
>
>
>
> *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 Mankamana
>
>
>
> I would like to request if you move me to the end of the agenda.
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
>
>
> On Sat, Jul 13, 2024 at 9:14 PM Mankamana Mishra (mankamis)  40cisco@dmarc.ietf.org> wrote:
>
> All,
>
> https://datatracker.ietf.org/doc/agenda-120-bess/
>
>
>
> please unicast if something missed in agenda.
>
>
>
> Mankamana
>
> ___
> BESS mailing list -- bess@ietf.org
> To unsubscribe send an email to bess-le...@ietf.org
>
>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: Initial agenda for BESS

[Gyan Mishra]

Hi Mankamana

I would like to request if you move me to the end of the agenda.

Thank you

Gyan



On Sat, Jul 13, 2024 at 9:14 PM Mankamana Mishra (mankamis)  wrote:

> All,
>
> https://datatracker.ietf.org/doc/agenda-120-bess/
>
>
>
> please unicast if something missed in agenda.
>
>
>
> Mankamana
> ___
> BESS mailing list -- bess@ietf.org
> To unsubscribe send an email to bess-le...@ietf.org
>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] IETF 120 time slot request

[Gyan Mishra]

Hi  Mankamana

I would like to request a 5 minute time slot for updates on this draft on
testing updates and plan for initiate WGLC this fall.  Also plans for
interoperability testing this work at EANTC labs at MPLS World Congress
next year as well as on the agenda officially to present this work at MPLS
World Congress next year.

https://datatracker.ietf.org/doc/draft-ietf-bess-v4-v6-pe-all-safi/

Thanks

Gyan
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

Re: [bess] Mail regarding draft-ietf-bess-rfc7432bis

[Gyan Mishra]

Hi Mankamana

I believe all the route types for MVPN multicast control plane exists in
EVPN as well but with all different numberings.

MVPN has:
RT-6 and RT-7 for shared and source tree.

EVPM has:
RT-10 S-PMSI AD Route type for S,G and *,G states

So the ASM or SSM IGMP join would be carried in the EVPN corresponding
route type.

There have been a lot of EVPN route types added since RFC 7432.

RFC 9469 lists all the EVPN route types in section 4.1.

Hope that helps

Kind Regards



*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*



On Tue, Jan 16, 2024 at 4:20 PM Mankamana Mishra (mankamis)  wrote:

> Authors, WG
>
>
>
> Can we add an explicit statement in the spec about what to do with
> multicast control packets in the EVPN domain?
>
>
>
>1. IGMP snooping enabled :
>   1. IGMP packets are terminated and not flooded over the EVPN domain
>2. IGMP snooping disabled :
>   1. IGMP and any other control packets will be flooded over EVPN
>   domain.
>
>
>
> Please let me know if we think otherwise.
>
>
>
> Mankamana
>
>
> ___
> 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

Re: [bess] Adoption call: draft-zhao-pim-evpn-multicast-yang in pim

[Gyan Mishra]

Support adoption.

I see the yang model has RT 6-8 but wondering why RT-3 IMET was not
included.

Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*



On Thu, Jan 4, 2024 at 5:40 PM Michael McBride <
michael.mcbr...@futurewei.com> wrote:

> Happy New Year,
>
>
>
> Today begins a two week adoption call for
> https://datatracker.ietf.org/doc/draft-zhao-pim-evpn-multicast-yang/ in
> the pim wg. This document describes a yang data model for evpn multicast
> services hence adding bess to the call for adoption. Our poll in Prague was
> 8 in favor and 1 against.
>
>
>
> Please review and comment.
>
>
>
> Thanks,
>
> mike
>
>
>
>
>
> *From:* BESS  *On Behalf Of *Michael McBride
> *Sent:* Monday, November 6, 2023 11:28 PM
> *To:* bess@ietf.org
> *Subject:* [bess] draft-zhao-pim-evpn-multicast-yang in pim
>
>
>
> Hello bess,
>
>
>
> We will have draft-zhao-pim-evpn-multicast-yang presented in pim tomorrow.
> Hongji has presented this draft a few times in pim because he hasn’t been
> able to get time in bess and we have progressed several of his other yang
> drafts in pim. It was suggested that we consider adopting in pim since bess
> is extremely busy. So just a heads up that we will take an adoption poll
> tomorrow per his request. We have discussed with bess chairs. Please review
> the draft.
>
>
>
> Thanks,
>
> mike
>
>
>
>
>
>
> ___
> 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

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Gyan Mishra]

I support adoption.

Thanks

Gyan

On Wed, Nov 29, 2023 at 6:12 PM Suresh Pasupula (surpasup)  wrote:

> I support the adoption of this document as a WG draft and I am not aware
> of any undisclosed IPR.
>
>
> Thanks
> Suresh
>
>
> On 11/13/23, 5:50 AM, "Jeffrey (Zhaohui) Zhang"  > wrote:
>
>
> Hi,
>
>
> This email begins a two-week WG adoption and IPR poll for
> draft-sajassi-bess-evpn-ip-aliasing-09 (
> https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09
> <
> https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09
> >).
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond to the IPR poll only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
>
> This poll for adoption closes on Monday, 27th of November, 2023.
>
>
> Thanks.
> Jeffrey
>
>
> Juniper Business Use Only
>
>
>
> ___
> 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] draft-burdet-bess-evpn-fast-reroute - Review

[Gyan Mishra]

Dear Authors

I reviewed the EVPN FRR draft and it is well written.

There is a tremendous amount of detail in this draft and wonder if it
should be easier to split into different drafts that focus on different
underlays or technologies.

My understanding from reading the draft is that this draft uses a
“secondary” redirect label “ERL” using downstream label allocation for the
FRR next hop path to provide a pre programmed backup FRR path BDF peer next
hop, that can provide data plane based convergence improvement over the
existing RFC 7432bis EVPN mechanisms for control plane based convergence.

This concept of utilizing a secondary label for faster convergence has
similarities to IDR draft for IP VPN BGP PIC Edge pre programmed FRR PE-CE
path protection draft below:

https://datatracker.ietf.org/doc/html/draft-mohanty-idr-secondary-label-00

Maybe worth reading to compare notes and the ML archive.

https://mailarchive.ietf.org/arch/msg/idr/ZucrYt9amGP8DD_BAXb6rwwpRGA/

In the discussion it was mentioned solving the issue at the service level
and it’s complexity versus solving at the transport layer with BGP-LU.
Not sure that would apply here but just wanted to mention.

3. Requirements section

Would this draft apply to IP VPN / EVPN interworking

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking

Would this also apply to RFC 9014 DCI Overlay?

https://datatracker.ietf.org/doc/rfc9014/

And EVPN Multisite below

https://datatracker.ietf.org/doc/draft-sharma-bess-multi-site-evpn/

Item #11 Solution should not relay on adding labels to the label stack or
underlay specific SPL.

Since this draft is providing PE-CE AC EVPN all active multi home fast
reroute protection service level label allocation similar to IP VPN per CE
label allocation mode on egress PE-CE AC.

Normally you would have a BOS service  label for the EVPN ESL, however for
the additional ERL label why would there not be an additional label added
to the label stack and this would be an MNA action for PSD for the ERL SPL?

I think you mentioned that the solution would be transport underlay
agnostic and maybe that could be added to section 3.

That is great that this solution is underlay agnostic!

This solution requires that the DF algorithm used must support BDF election
RFC 8584 so if PE1 AC fails it used ERL2 signaled by PE2 NH pre programmed
BDF FRR path and if PE2 AC fails or uses ERL1 signaled by PE1 NH pre
programmed BDF FRR path.  Correct?

5.2 Terminal disposition behavior

Basically the ERL redirect BDF NH can only be signaled once and then is
terminated so it’s a one time FRR until the link is restored.   This is to
prevent looping in case of simultaneous PE-CE failure.  However in a
simultaneous failure PE1 would signal ERL1 to PE2 and PE2 would signal ERL2
to PE1 in this case both PE-CS links bounced and both would PEs would
redirect to each other. Due to timing of redirect from link flapping it
seems you could have a continual bouncing back and forth of redirects
between the PEs.

5.2

The ERL acts like a local cross-connect by providing a direct channel from
disposition to the AC. ERLs are terminal-disposition and prevents
once‑redirected packets from being redirected again. With this forwarding
attribute on ERLs, known only locally to the downstream-allocating PE,
redirection is achieved without growing the label stack with another
special purpose label.¶

Section 5.2 is talking about the terminal disposition using the section 5.1
discussion that the redirect label must carry a special attribute in the
local forwarding and decapsulation chain where an override to DF election
is applied where traffic from the ERL will bypass the local blocking state.
So once control plane is converged the ERL will stop and that will
basically terminate the redirect loop from happening after the 1st
occurrence?

7.1 NVO Tunnels

This section briefly describes NVO and applicability of this ERL solution
to NVO and for Non MPLS based NVO VXLAN & GENEVE, I am guessing those
details would be split off into a different draft.

7.1 and 7.1.1 should take into account RFC 9014 DCI overlay where the VNI
is regenerated and not globally significant.  Also for Non MPLS NVO VXLAN
should account for ESI MLAG hosts and BGP Only DC using RFC 9014 DCI
overlay regeneration of VNI.

7.2 SRv6

The draft should mention that RFC 9252 does not account for ARG field and
point to BIS update.

https://datatracker.ietf.org/doc/html/draft-trr-bess-bgp-srv6-args-02

Should mention that SRv6 PGM below description of the two endpoint
functions used.

End.DT2U is decapsulation and Unicast MAC L2 table lookup

End.DT2U+Arg.FR2

So we have a double SID for the endpoint behavior , the regular End.DT2U
endpoint function L2 table traffic lookup.

I think this section for End.DT2U is for L2 table lookup and not for the
redirect reroute which is handled by END.DX2.

End

Re: [bess] Please send slot request for IETF 118

[Gyan Mishra]

Mankamana

I would like to request 10 minute slot for the updated combined draft.

*draft-ietf-bess-v4-v6-pe-all-safi (Standards Track)*

Thanks

Gyan

On Mon, Oct 9, 2023 at 4:39 PM Mankamana Mishra (mankamis)  wrote:

> All,
>
> Primary agenda has been posted. Please send me slot request for BESS 118.
>
>
>
> Mankamana
> ___
> 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

Re: [bess] draft-boutros-bess-elan-services-over-sr review

[Gyan Mishra]

Dear Authors

To help provide some clarity on MNA, MNA (MPLS Network Actions)  inherits
it’s extensibility concepts from the IPv6 data plane extension header
concept with HBH header -MPLS parity with  hop by  hop bSPL (base special
purpose label) which is the topmost transport label  in the label stack MNA
extensibility referred to as “ISD” (in stack data)and  DOH (Destination
Options Header) - MPLS parity with E2E bSPL (base special purpose label) in
the label stack MNA extensibility referred to as “PSD” (post stack data).

Hope that helps in defining the use case for this new  PSD bSPL.

Cheers,

Gyan

On Mon, Oct 9, 2023 at 11:16 PM Gyan Mishra  wrote:

>
> Dear authors
>
> Slight correction on SRv6 uSID service sid.
>
> So the F3216 uSID format 32 bit block with 16 bit uSID entry in the uSID
> carrier, you can have different types or “service sid” which comes out of
> the expanded WLIB  wide LIB local SID block allocation.
>
> Nice thing about SRv6 is sky is the limit of ideas for SRv6 uSID
> forwarding plane service sid use case extensibility and SRv6 endpoint
> instantiation and what you want to encode into the service sid field.
>
> Kind Regards
>
> Gyan
> On Mon, Oct 9, 2023 at 10:52 PM Gyan Mishra  wrote:
>
>>
>> Dear authors
>>
>> I would like to provide some feedback on this draft follow up from the
>> presentation given at IETF 117.
>>
>> After reviewing this draft it seems this draft is trying apply the
>> concept of “service sid” to both SR-MPLS and SRv6 uSID forwarding planes.
>> Interesting idea.
>>
>> This draft seems to overlap or conflict with the important concept of
>> “service sid” used by RFC 9252 SRv6 BGP service overlay which defines the
>> BGP prefix SID encoding schema for SRv6 L2
>> service TLV encoding of SRv6 service  SID for SRv6 based L2 services
>> functionally equivalent to EVPN MPLS label routes types for L2 service and
>> SRv6 L3 service TLV encoding of SRv6 service  SID for SRv6 based L3
>>  services functionally equivalent to L3 VPN MPLS label service routes types
>> for L3 services.
>>
>> Segment Routing has the concept of topological sid and service sid where
>> the topological sid is equivalent to the MPLS label stack topmost label and
>> the service sid is equivalent to the BOS S bit set bottom of stack service
>> label where with SRv6 is analogous to a a single level label stack with the
>> locator acting as the topmost label and the SRv6 SID  IPv6 address IID FUNC
>> field encoding the L2 L3 VPN  service label.  Thus the single level label
>> stack trickery optimization in the SRv6 forwarding plane encoding schema
>> and as is a different forwarding plane paradigm shift requires the concept
>> of service sid for the L2 L3 VPN label encodings.
>>
>> AFAIK this concept of service sid does not apply to SR-MPLS as it reuses
>> the label stack of the MPLS data plane and with MNA extensibility is
>> further extended.  SR-MPLS use ISD for its framework identical to MPLS RFC
>> 6790 or SR-MPLS RFC 8662 Entropy label {TL,ELI,EL} where now with SR-MPLS
>> with ISD the topological SIDs are now stacked representing the transport
>> label layer of the label stack followed by the BOS S bit set L2 / L3 VPN
>> service labels.  Adding an additional special purpose service label as this
>> draft describes sounds like would be a possible use case for PSD
>> extensibility of the bottom of stack with post stack data.  Overall for MNA
>> most of the existing ancillary data use cases as described have been for
>> ISD and not yet any for PSD, however there are some use cases in the works
>> and maybe this would be another possibility of a use case.
>>
>> The service SID concept used in this draft for L2 VPN EPN does talk about
>> a bit mapping and possible aggregation or some sort of optimizations maybe
>> even network slicing using bits for services slice selector could be an
>> idea for use of the service sid and there could be many other
>> possibilities.
>>
>> I believe the below draft maybe what you are trying to accomplish with
>> the EVPN service sid from an optimization perspective.
>>
>> MVPN EVPN tunnel aggregation with common labels
>>
>> This draft takes advantage of upstream assigned context labels RFC 5331.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-14
>>
>> I would be happy to collaborate on this draft.
>>
>> Kind Regards
>>
>> Gyan
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-boutros-bess-elan-services-over-sr review

[Gyan Mishra]

Dear authors

Slight correction on SRv6 uSID service sid.

So the F3216 uSID format 32 bit block with 16 bit uSID entry in the uSID
carrier, you can have different types or “service sid” which comes out of
the expanded WLIB  wide LIB local SID block allocation.

Nice thing about SRv6 is sky is the limit of ideas for SRv6 uSID forwarding
plane service sid use case extensibility and SRv6 endpoint instantiation
and what you want to encode into the service sid field.

Kind Regards

Gyan
On Mon, Oct 9, 2023 at 10:52 PM Gyan Mishra  wrote:

>
> Dear authors
>
> I would like to provide some feedback on this draft follow up from the
> presentation given at IETF 117.
>
> After reviewing this draft it seems this draft is trying apply the concept
> of “service sid” to both SR-MPLS and SRv6 uSID forwarding planes.
> Interesting idea.
>
> This draft seems to overlap or conflict with the important concept of
> “service sid” used by RFC 9252 SRv6 BGP service overlay which defines the
> BGP prefix SID encoding schema for SRv6 L2
> service TLV encoding of SRv6 service  SID for SRv6 based L2 services
> functionally equivalent to EVPN MPLS label routes types for L2 service and
> SRv6 L3 service TLV encoding of SRv6 service  SID for SRv6 based L3
>  services functionally equivalent to L3 VPN MPLS label service routes types
> for L3 services.
>
> Segment Routing has the concept of topological sid and service sid where
> the topological sid is equivalent to the MPLS label stack topmost label and
> the service sid is equivalent to the BOS S bit set bottom of stack service
> label where with SRv6 is analogous to a a single level label stack with the
> locator acting as the topmost label and the SRv6 SID  IPv6 address IID FUNC
> field encoding the L2 L3 VPN  service label.  Thus the single level label
> stack trickery optimization in the SRv6 forwarding plane encoding schema
> and as is a different forwarding plane paradigm shift requires the concept
> of service sid for the L2 L3 VPN label encodings.
>
> AFAIK this concept of service sid does not apply to SR-MPLS as it reuses
> the label stack of the MPLS data plane and with MNA extensibility is
> further extended.  SR-MPLS use ISD for its framework identical to MPLS RFC
> 6790 or SR-MPLS RFC 8662 Entropy label {TL,ELI,EL} where now with SR-MPLS
> with ISD the topological SIDs are now stacked representing the transport
> label layer of the label stack followed by the BOS S bit set L2 / L3 VPN
> service labels.  Adding an additional special purpose service label as this
> draft describes sounds like would be a possible use case for PSD
> extensibility of the bottom of stack with post stack data.  Overall for MNA
> most of the existing ancillary data use cases as described have been for
> ISD and not yet any for PSD, however there are some use cases in the works
> and maybe this would be another possibility of a use case.
>
> The service SID concept used in this draft for L2 VPN EPN does talk about
> a bit mapping and possible aggregation or some sort of optimizations maybe
> even network slicing using bits for services slice selector could be an
> idea for use of the service sid and there could be many other
> possibilities.
>
> I believe the below draft maybe what you are trying to accomplish with the
> EVPN service sid from an optimization perspective.
>
> MVPN EVPN tunnel aggregation with common labels
>
> This draft takes advantage of upstream assigned context labels RFC 5331.
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-14
>
> I would be happy to collaborate on this draft.
>
> Kind Regards
>
> Gyan
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] draft-boutros-bess-elan-services-over-sr review

[Gyan Mishra]

Dear authors

I would like to provide some feedback on this draft follow up from the
presentation given at IETF 117.

After reviewing this draft it seems this draft is trying apply the concept
of “service sid” to both SR-MPLS and SRv6 uSID forwarding planes.
Interesting idea.

This draft seems to overlap or conflict with the important concept of
“service sid” used by RFC 9252 SRv6 BGP service overlay which defines the
BGP prefix SID encoding schema for SRv6 L2
service TLV encoding of SRv6 service  SID for SRv6 based L2 services
functionally equivalent to EVPN MPLS label routes types for L2 service and
SRv6 L3 service TLV encoding of SRv6 service  SID for SRv6 based L3
 services functionally equivalent to L3 VPN MPLS label service routes types
for L3 services.

Segment Routing has the concept of topological sid and service sid where
the topological sid is equivalent to the MPLS label stack topmost label and
the service sid is equivalent to the BOS S bit set bottom of stack service
label where with SRv6 is analogous to a a single level label stack with the
locator acting as the topmost label and the SRv6 SID  IPv6 address IID FUNC
field encoding the L2 L3 VPN  service label.  Thus the single level label
stack trickery optimization in the SRv6 forwarding plane encoding schema
and as is a different forwarding plane paradigm shift requires the concept
of service sid for the L2 L3 VPN label encodings.

AFAIK this concept of service sid does not apply to SR-MPLS as it reuses
the label stack of the MPLS data plane and with MNA extensibility is
further extended.  SR-MPLS use ISD for its framework identical to MPLS RFC
6790 or SR-MPLS RFC 8662 Entropy label {TL,ELI,EL} where now with SR-MPLS
with ISD the topological SIDs are now stacked representing the transport
label layer of the label stack followed by the BOS S bit set L2 / L3 VPN
service labels.  Adding an additional special purpose service label as this
draft describes sounds like would be a possible use case for PSD
extensibility of the bottom of stack with post stack data.  Overall for MNA
most of the existing ancillary data use cases as described have been for
ISD and not yet any for PSD, however there are some use cases in the works
and maybe this would be another possibility of a use case.

The service SID concept used in this draft for L2 VPN EPN does talk about a
bit mapping and possible aggregation or some sort of optimizations maybe
even network slicing using bits for services slice selector could be an
idea for use of the service sid and there could be many other
possibilities.

I believe the below draft maybe what you are trying to accomplish with the
EVPN service sid from an optimization perspective.

MVPN EVPN tunnel aggregation with common labels

This draft takes advantage of upstream assigned context labels RFC 5331.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-14

I would be happy to collaborate on this draft.

Kind Regards

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

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Gyan Mishra]

I reviewed the draft and it’s important updates to RFC 9252 to support SRV6
BGP service overlay to support SRv6 SID  ARG  field for endpoint behaviors
that require it namely with EVPN RT-1 and RT-3.

I support WG adoption.

Thanks

Gyan

On Thu, Sep 28, 2023 at 10:50 AM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> This email begins a two-week WG adoption and IPR poll for
> draft-trr-bess-bgp-srv6-args-02 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
>
> Currently, there is currently no IPR disclosure against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond to the IPR poll only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Thursday 12th October 2023.
>
>
>
> [1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP
> Services (ietf.org)
> 
> ___
> 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

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

[Gyan Mishra]

I support WG adoption.

Thanks

Gyan

On Thu, Oct 5, 2023 at 6:45 AM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> 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
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Appointment of additional WG Chair

[Gyan Mishra]

Congratulations Jeffrey!

You will be a great addition to the team.

Gyan

On Thu, Aug 3, 2023 at 10:45 PM Andrew Alston - IETF  wrote:

> Hi WG,
>
>
>
> Following consultation with Matt and Stephane I have opted to appoint a
> third chair to BESS to provide additional coverage considering the document
> working load through the working group.
>
>
>
> As such, I would like to welcome Jeffery Zhang as the third chair to BESS
> and to thank him for his willingness to take up the position.  I believe
> Jeffrey will be a solid addition to the team.
>
>
>
> Thanks
>
>
>
> Andrew Alston
>
> Routing Area Director
>
>
>
> Internal All Employees
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

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

[Gyan Mishra]

Thanks Ketan

Yes this Will tremendously simplify the design options and all the
redundant information spread across many drafts.

Gyan
On Fri, Jul 28, 2023 at 10:39 AM Ketan Talaulikar 
wrote:

> Hi Gyan,
>
> Thanks a lot for acting on this feedback from myself and others in the WG.
> This is really helpful and will benefit readers of the document but also
> through the IETF process all the reviewers and contributors.
>
> With this merge, I hope you are able to consolidate and simplify these
> various design options and illustrate the similarities.
>
> I support this merge.
>
> Thanks,
> Ketan
>
>
> 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
>>
>> <http://www.verizon.com/>
>>
>> *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
>>
> --

<http://www.verizon.com/>

*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] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI Supported

[Gyan Mishra]

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://www.verizon.com/>

*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

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
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WG adoption poll for draft-wang-bess-sbfd-discriminator

[Gyan Mishra]

Dear chairs

Sorry for the late response and I support WG adoption.

This draft makes S-BFD viable for operators deploying SRv6, simplifying the
deployment configuration by being able to advertise the BFD discriminator
defined in RFC 9026 MVPN Fast Upstream failover extended now  to support
SRv6 overlay services over SRv6-BE or SRv6-TE.

Kind Regards

Gyan

On Wed, May 17, 2023 at 12:39 PM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-wang-bess-sbfd-discriminator-05 [1].
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
> Currently, there is one IPR disclosure against this document.
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on May 31th
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-wang-bess-sbfd-discriminator/
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

[Gyan Mishra]

I support adoption.

Thank you

Gyan

On Wed, May 24, 2023 at 4:02 AM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for 
> draft-brissette-bess-evpn-vpws-seamless-07
> [1].
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
>
> Currently, there is currently no IPR disclosure against this document.
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on June 7th.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-vpws-seamless/
> _______
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

[Gyan Mishra]

I reviewed the draft and support adoption.

Thanks

Gyan

On Thu, May 25, 2023 at 6:35 AM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-week
> WG adoption poll for draft-sajassi-bess-secure-evpn-06 [1].
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
>
> Currently, there is currently no IPR disclosure against this document.
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on June 9th 2023
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/html/draft-sajassi-bess-secure-evpn
>
>
> _______
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

[Gyan Mishra]

Hi Satya

Backwards compatibility is critical and completely understand.

However let’s say all routers are upgraded to support 8584 and Type 1 HRW
and negotiate the AC-DF capability exchange codepoint P2P then would all
routers supporting type 1 automatically start using Type 1 HRW Alg?

Kind Regards

Gyan

On Mon, Mar 6, 2023 at 12:21 AM Satya Mohanty (satyamoh) 
wrote:

> Thanks Jorge.
>
>
>
> Gyan, indeed all the three algorithms have their use-cases.
>
>
>
> As pointed out below in case of inconsistency (the “Alg type”) in the DF
> election extended community for a given ES, it was decided that the DF
> election must default to the modulo-based simply because modulo-based was
> proposed first and all existing deployments already had it, before the
> other two (Pref-based and HRW) came into existence.
> https://www.rfc-editor.org/rfc/rfc8584.html#section-2.2.1
>
>
>
> Thanks,
>
> --Satya
>
>
>
> *From: *BESS  on behalf of Jorge Rabadan (Nokia) <
> jorge.raba...@nokia.com>
> *Date: *Friday, March 3, 2023 at 11:06 PM
> *To: *Gyan Mishra 
> *Cc: *mdodge , bess@ietf.org 
> *Subject: *Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
>
> Hi Gyan,
>
>
>
> I agree with your two first statements, but I’m afraid I don’t agree with
> this one:
>
> “I would think HRW would be the new default algorithm used for DF election
> and would not be a knob as it fixes the major deficiencies with the modulus
> algorithm.”
>
>
>
> The modulo-based DF algorithm remains the default algorithm in case of
> inconsistency in the Ethernet Segment peers. It uses DF Alg 0, while HRW
> uses type 1 and Preference type 2. HRW is not obsoleting the modulo-based
> or anything like that. The three algorithms are widely used in networks,
> and while the default one has limitations, it is simple and works out in
> many networks.
>
>
>
> Thank you!
>
> Jorge
>
>
>
>
>
> *From: *Gyan Mishra 
> *Date: *Friday, March 3, 2023 at 11:50 PM
> *To: *Jorge Rabadan (Nokia) 
> *Cc: *Menachem Dodge , bess@ietf.org 
> *Subject: *Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See http://nok.it/ext for
> additional information.
>
>
>
>
>
> Hi Jorge
>
>
>
> As defined in RFC 8584 AC-DF and HRW are independent of each other.
>
>
>
> RFC 8584 updates RFC 7432, however RFC 7432 bis does not update any aspect
> of RFC 8584 including HRW as you stated.
>
>
>
> I would think HRW would be the new default algorithm used for DF election
> and would not be a knob as it fixes the major deficiencies with the modulus
> algorithm.
>
>
>
> Thanks
>
>
>
> Gyan
>
> On Fri, Feb 10, 2023 at 2:01 PM Jorge Rabadan (Nokia) <
> jorge.raba...@nokia.com> wrote:
>
> Hi Menachem,
>
>
>
> The way I see it, draft-ietf-bess-rfc7432bis will obsolete RFC7432, but it
> does not update or change RFC8584, so I don’t think
> draft-ietf-bess-rfc7432bis needs to repeat the aspects of RFC8584.
>
>
>
> In particular, the AC-DF, as the other capabilities defined in other
> documents, is a capability that can be turned on or off. While it is very
> useful in many cases, it actually needs to be disabled in some others,
> e.g., draft-ietf-bess-evpn-mh-pa-07
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-pa-07>
>
>
>
> So the answer to your second question could be that the AC-DF capability
> should be configurable in the implementation, and used on all cases where
> issues with individual Attachment Circuits may create blackholes. However,
> it has to be disabled in case of port-active multi-homing.
>
>
>
> My 2 cents..
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
> *From: *BESS  on behalf of Menachem Dodge <
> mdo...@drivenets.com>
> *Date: *Friday, February 10, 2023 at 8:10 AM
> *To: *bess@ietf.org 
> *Subject: *[bess] Section 8.5 of draft-ietf-bess-rfc7432bis
>
> Some people who received this message don't often get email from
> mdo...@drivenets.com. Learn why this is important
> <https://aka.ms/LearnAboutSenderIdentification>
>
> Hello All,
>
>
>
> In section 8.5 of draft-ietf-bess-rfc7432bis there is a reference to the
> Finite State Machine in section 2.1 of RFC 8584.
>
>
>
> However, in section 4 of RFC 8584 the AC Influenced DF Election Capability
> is described and it states that this updates Step 3 of the procedure for
> service carving of RFC 7432.
>
>
>
> Shouldn’t this AC-DF update be mentioned in the procedures of section 8.5

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

[Gyan Mishra]

Thanks Jorge!

Gyan


On Sat, Mar 4, 2023 at 2:06 AM Jorge Rabadan (Nokia) <
jorge.raba...@nokia.com> wrote:

> Hi Gyan,
>
>
>
> I agree with your two first statements, but I’m afraid I don’t agree with
> this one:
>
> “I would think HRW would be the new default algorithm used for DF election
> and would not be a knob as it fixes the major deficiencies with the modulus
> algorithm.”
>
>
>
> The modulo-based DF algorithm remains the default algorithm in case of
> inconsistency in the Ethernet Segment peers. It uses DF Alg 0, while HRW
> uses type 1 and Preference type 2. HRW is not obsoleting the modulo-based
> or anything like that. The three algorithms are widely used in networks,
> and while the default one has limitations, it is simple and works out in
> many networks.
>
>
>
> Thank you!
>
> Jorge
>
>
>
>
>
> *From: *Gyan Mishra 
> *Date: *Friday, March 3, 2023 at 11:50 PM
> *To: *Jorge Rabadan (Nokia) 
> *Cc: *Menachem Dodge , bess@ietf.org 
> *Subject: *Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See http://nok.it/ext for
> additional information.
>
>
>
>
>
> Hi Jorge
>
>
>
> As defined in RFC 8584 AC-DF and HRW are independent of each other.
>
>
>
> RFC 8584 updates RFC 7432, however RFC 7432 bis does not update any aspect
> of RFC 8584 including HRW as you stated.
>
>
>
> I would think HRW would be the new default algorithm used for DF election
> and would not be a knob as it fixes the major deficiencies with the modulus
> algorithm.
>
>
>
> Thanks
>
>
>
> Gyan
>
> On Fri, Feb 10, 2023 at 2:01 PM Jorge Rabadan (Nokia) <
> jorge.raba...@nokia.com> wrote:
>
> Hi Menachem,
>
>
>
> The way I see it, draft-ietf-bess-rfc7432bis will obsolete RFC7432, but it
> does not update or change RFC8584, so I don’t think
> draft-ietf-bess-rfc7432bis needs to repeat the aspects of RFC8584.
>
>
>
> In particular, the AC-DF, as the other capabilities defined in other
> documents, is a capability that can be turned on or off. While it is very
> useful in many cases, it actually needs to be disabled in some others,
> e.g., draft-ietf-bess-evpn-mh-pa-07
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-pa-07>
>
>
>
> So the answer to your second question could be that the AC-DF capability
> should be configurable in the implementation, and used on all cases where
> issues with individual Attachment Circuits may create blackholes. However,
> it has to be disabled in case of port-active multi-homing.
>
>
>
> My 2 cents..
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
> *From: *BESS  on behalf of Menachem Dodge <
> mdo...@drivenets.com>
> *Date: *Friday, February 10, 2023 at 8:10 AM
> *To: *bess@ietf.org 
> *Subject: *[bess] Section 8.5 of draft-ietf-bess-rfc7432bis
>
> Some people who received this message don't often get email from
> mdo...@drivenets.com. Learn why this is important
> <https://aka.ms/LearnAboutSenderIdentification>
>
> Hello All,
>
>
>
> In section 8.5 of draft-ietf-bess-rfc7432bis there is a reference to the
> Finite State Machine in section 2.1 of RFC 8584.
>
>
>
> However, in section 4 of RFC 8584 the AC Influenced DF Election Capability
> is described and it states that this updates Step 3 of the procedure for
> service carving of RFC 7432.
>
>
>
> Shouldn’t this AC-DF update be mentioned in the procedures of section 8.5
> of draft-ietf-bess-rfc7432bis?
>
>
>
> Is AC Influenced DF Election the preferred DF election method ?
>
>
>
>
>
> According to RFC 8584 “ The procedure discussed in this section is
> applicable to the DF
>
>election in EVPN services [RFC7432 
> <https://datatracker.ietf.org/doc/html/rfc7432>] and EVPN VPWS [RFC8214 
> <https://datatracker.ietf.org/doc/html/rfc8214>]. “
>
>
>
>
>
>
>
> Thank you kindly.
>
>
>
> Best Regards,
>
>
>
> *Menachem Dodge**​**​**​**​*
>
> System Architect
>
> [image: signature_3305758272]
>
> +972-526175734
>
> mdo...@drivenets.com
>
> follow us on Linkedin <https://www.linkedin.com/company/drivenets>
>
> www.drivenets.com
>
> [image: DriveNets Network Cloud]
> <https://get.drivenets.com/mwc-2023-schedule-a-meeting>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

[Gyan Mishra]

Hi Jorge

As defined in RFC 8584 AC-DF and HRW are independent of each other.

RFC 8584 updates RFC 7432, however RFC 7432 bis does not update any aspect
of RFC 8584 including HRW as you stated.

I would think HRW would be the new default algorithm used for DF election
and would not be a knob as it fixes the major deficiencies with the modulus
algorithm.

Thanks

Gyan
On Fri, Feb 10, 2023 at 2:01 PM Jorge Rabadan (Nokia) <
jorge.raba...@nokia.com> wrote:

> Hi Menachem,
>
>
>
> The way I see it, draft-ietf-bess-rfc7432bis will obsolete RFC7432, but it
> does not update or change RFC8584, so I don’t think
> draft-ietf-bess-rfc7432bis needs to repeat the aspects of RFC8584.
>
>
>
> In particular, the AC-DF, as the other capabilities defined in other
> documents, is a capability that can be turned on or off. While it is very
> useful in many cases, it actually needs to be disabled in some others,
> e.g., draft-ietf-bess-evpn-mh-pa-07
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-pa-07>
>
>
>
> So the answer to your second question could be that the AC-DF capability
> should be configurable in the implementation, and used on all cases where
> issues with individual Attachment Circuits may create blackholes. However,
> it has to be disabled in case of port-active multi-homing.
>
>
>
> My 2 cents..
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
> *From: *BESS  on behalf of Menachem Dodge <
> mdo...@drivenets.com>
> *Date: *Friday, February 10, 2023 at 8:10 AM
> *To: *bess@ietf.org 
> *Subject: *[bess] Section 8.5 of draft-ietf-bess-rfc7432bis
>
> Some people who received this message don't often get email from
> mdo...@drivenets.com. Learn why this is important
> <https://aka.ms/LearnAboutSenderIdentification>
>
> Hello All,
>
>
>
> In section 8.5 of draft-ietf-bess-rfc7432bis there is a reference to the
> Finite State Machine in section 2.1 of RFC 8584.
>
>
>
> However, in section 4 of RFC 8584 the AC Influenced DF Election Capability
> is described and it states that this updates Step 3 of the procedure for
> service carving of RFC 7432.
>
>
>
> Shouldn’t this AC-DF update be mentioned in the procedures of section 8.5
> of draft-ietf-bess-rfc7432bis?
>
>
>
> Is AC Influenced DF Election the preferred DF election method ?
>
>
>
>
>
> According to RFC 8584 “ The procedure discussed in this section is
> applicable to the DF
>
>election in EVPN services [RFC7432 
> <https://datatracker.ietf.org/doc/html/rfc7432>] and EVPN VPWS [RFC8214 
> <https://datatracker.ietf.org/doc/html/rfc8214>]. “
>
>
>
>
>
>
>
> Thank you kindly.
>
>
>
> Best Regards,
>
>
>
> *Menachem Dodge**​**​**​**​*
>
> System Architect
>
> [image: signature_3305758272]
>
> +972-526175734
>
> mdo...@drivenets.com
>
> follow us on Linkedin <https://www.linkedin.com/company/drivenets>
>
> www.drivenets.com
>
> [image: DriveNets Network Cloud]
> <https://get.drivenets.com/mwc-2023-schedule-a-meeting>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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] IETF 116 10 minute time slot request for IPv4-Only PE Design All SAFI & IPv6-Only PE Design All SAFI

[Gyan Mishra]

Hi Mankamana & Chairs

I would like to request a 10 minute time slot for updates on the 2 drafts
below in preparation to queue for adoption call:

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/


https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/

Thank you

<http://www.verizon.com/>

*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

Re: [bess] Suggestion on v4-only/v6-only drafts

[Gyan Mishra]

Hi Robert

See my email from this morning after BESS as well as response to Ketan as
it explains the 4 BESS drafts and 1 IDR drafts in detail and the game plan
moving forward.

Thanks

Gyan

On Fri, Nov 11, 2022 at 7:29 AM Robert Raszuk  wrote:

> Hi Ketan,
>
> If you are referring to interconnecting v4 only sites draft I have number
> of comments:
>
> * The draft is not needed at all
>
> * we can seamlessly interconnect v4 sites over v6 core using v4 mapped v6
> addresses
>
> * Zero control plane change is required/needed
>
> * number of vendors are shipping it
>
> Moreover sites even if today speaking v4 only sooner then later will talk
> also v6. We can not ship a std track document which makes v6 deployment
> harder or no-op for any site.
>
> Best,
> Robert
>
> On Fri, Nov 11, 2022, 11:19 Ketan Talaulikar 
> wrote:
>
>> Hi Gyan,
>>
>> Sharing a couple of suggestions here for your 5 drafts (4 in BESS + 1 in
>> IDR) as we lost time due to the audio issues:
>>
>> (1) put the portions to be standardized (very focussed/small hopefully)
>> in one single draft and post/share with both IDR and BESS since you are
>> changing NH encoding (from what I heard?)
>> (2) all other informational/BCP material could be combined in a single
>> draft (perhaps the existing BESS WG draft)
>>
>> IMHO, that would facilitate an appropriate focussed review of the
>> content/proposals.
>>
>> Thanks,
>> Ketan
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> --

<http://www.verizon.com/>

*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

Re: [bess] Suggestion on v4-only/v6-only drafts

[Gyan Mishra]

Hi Ketan

Thank you for the feedback on the drafts.

See my email I sent this morning readout on the drafts presentation.  That
will explain in detail and answer all of your questions.

IDR draft:

The 4PE draft connecting IPv4 islands over an IPv6 core  over the global
table is similar in semantics to 6PE RFC 4798 which connects IPv6 islands
over an IPv4 core over the global table and the draft is extensible to
SR-MPLS and SRv6. There currently is not a standard for 4PE so this draft
would standardize 4PE for vendor  interoperability.

https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/

BESS drafts - these drafts are completely different from IDR 4PE draft.

I have already combined two of the drafts into one for the IPv4-Only PE All
SAFI draft

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/

IPv6 Only PE Design BCP draft below was adopted  last year and the new
draft extensible to ALL SAFI Standards Track below I plan to progress
separately.  As one is BCP and the other Standards track I don’t think they
could be combined and even if they were combined into the super set all
SAFI that would have to go through adoption process again anyway so I plan
to keep separate.

This draft I will queue up for adoption call.

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/


Many Thanks

Gyan

On Fri, Nov 11, 2022 at 6:19 AM Ketan Talaulikar 
wrote:

> Hi Gyan,
>
> Sharing a couple of suggestions here for your 5 drafts (4 in BESS + 1 in
> IDR) as we lost time due to the audio issues:
>
> (1) put the portions to be standardized (very focussed/small hopefully) in
> one single draft and post/share with both IDR and BESS since you are
> changing NH encoding (from what I heard?)
> (2) all other informational/BCP material could be combined in a single
> draft (perhaps the existing BESS WG draft)
>
> IMHO, that would facilitate an appropriate focussed review of the
> content/proposals.
>
> Thanks,
> Ketan
>
> --

<http://www.verizon.com/>

*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

Re: [bess] Please send me presentation slot request for IETF 115

[Gyan Mishra]

Hi Mankamana

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

IPv4-Only PE Design / ALL SAFI - I will combine these two drafts before the
10/24 deadline and present
https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/
https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design/

IPv6-Only PE Design / ALL SAFI --> Present updates on these two drafts
https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/

https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/

Thanks

Gyan

On Sun, Oct 16, 2022 at 10:03 AM Mankamana Mishra (mankamis)  wrote:

> All
> Please send me slot request for IETF 115 . Agenda has been posted and we
> are scheduled on Friday .
>
> Mankamana
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>


-- 

<http://www.verizon.com/>

*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

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-ac-aware-bundling

[Gyan Mishra]

I support WG adoption.

Thanks

Gyan

On Mon, Oct 10, 2022 at 4:40 AM Stephane Litkowski (slitkows)  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-sajassi-bess-evpn-ac-aware-bundling-06 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on October 24th 2022.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ac-aware-bundling/
>
>
> _______
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

[Gyan Mishra]

I support publication.

Thanks

Gyan

On Mon, Sep 26, 2022 at 7:05 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> This email starts a two-week working group last call for 
> draft-ietf-bess-bgp-sdwan-usage-05
> [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as an Informational RFC.
>
>
>
> This poll runs until the 10th October 2022
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The document won't progress without answers from
> all the authors and contributors.
>
> There are currently two IPR disclosures.
>
>
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1]  draft-ietf-bess-bgp-sdwan-usage-05
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage>
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[Gyan Mishra]

 and, call this
>> a call for expressions of interest in those who may be willing to work
>> towards something like this.  Happy to take emails on list or off list and
>> see if we can find a solution.
>>
>>
>>
>> Looking forward to hearing from you all
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>>
>> ___
>> spring mailing list
>> spr...@ietf.org
>>
>> https://clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>>
>>
>> Notice: This e-mail together with any attachments may contain information
>> of Ribbon Communications Inc. and its Affiliates that is confidential
>> and/or proprietary for the sole use of the intended recipient. Any review,
>> disclosure, reliance or distribution by others or forwarding without
>> express permission is strictly prohibited. If you are not the intended
>> recipient, please notify the sender immediately and then delete all copies,
>> including any attachments.
>>
>>
>> Notice: This e-mail together with any attachments may contain information
>> of Ribbon Communications Inc. and its Affiliates that is confidential
>> and/or proprietary for the sole use of the intended recipient. Any review,
>> disclosure, reliance or distribution by others or forwarding without
>> express permission is strictly prohibited. If you are not the intended
>> recipient, please notify the sender immediately and then delete all copies,
>> including any attachments.
>>
>> Notice: This e-mail together with any attachments may contain information
>> of Ribbon Communications Inc. and its Affiliates that is confidential
>> and/or proprietary for the sole use of the intended recipient. Any review,
>> disclosure, reliance or distribution by others or forwarding without
>> express permission is strictly prohibited. If you are not the intended
>> recipient, please notify the sender immediately and then delete all copies,
>> including any attachments.
>> ___
>> 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
>
-- 

<http://www.verizon.com/>

*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] Rtgdir last call review of draft-ietf-bess-evpn-vpws-fxc-07

[Gyan Mishra via Datatracker]

Reviewer: Gyan Mishra
Review result: Ready

This specification specifies a important optimization for operators using VPWS
EVPN for scalability of millions of P2P AC provisioning using a VPWS EVPN
Flexible Cross connect service which multiplexes multiple attachment circuits
across different Ethernet Segments and physical interfaces into a single EVPN
VPWS service tunnel and still providing Single-Active and All-Active
multi-homing.

The draft is very well written and is ready for publication.

Few nits below need to be addressed prior to publication.  I did not find any
technical issues related to the solution.

Nits:
s/withdraw/s//withdrawal
s/control- plane/s//control-plane

Add to terminology section and / or expand and and show abbreviation in ()
example Flexible Cross Connect (FXC)

FXC - Flexible Cross Connect
VPWS -Virtual Private Wire Service
EVPN - Ethernet Virtual Private Network
MTU - Maximum Transmit Unit
L2 - Layer 2
VID - Vlan ID
ESI - Ethernet Segment Identififer
EVI - EVPN Instance Identifier
AC - Attachment Circuit
A-D - Auto Discovery
ES - Ethernet Segment
VRF - Virtual Route Forwarding
PW - Pseudowire
VCCV - Virtual circuit connection verification

In section 2 requirements 5th paragraph

An endpoint can be an AC, MAC-VRF, IP-VRF, global table, or etc.

I can see endpoint being AC as endpoint but not the others in the context of
this specification which is about multiplexing the ACs into a single tunnel.  I
think that line can be omitted or maybe changed to say an endpoint is one end
of an AC.

Section 3 solution

   Since there is only a single EVPN VPWS service tunnel associated with
   many normalized VIDs (either single or double) across multiple
   physical interfaces, MPLS lookup at the disposition PE is no longer
   sufficient to forward the packet to the right egress
   endpoint/interface.  Therefore, in addition to an EVPN label lookup
   corresponding to the VPWS service tunnel, a VID lookup (either single
   or double) is also required.

Is there any performance impact with the additional lookups?

Trade off for the operators deploying this feature providing scalability but at
a performance price.  If so this should be noticed in a deployment
considerations section.

Is section 3.2 the default FXC mode.  That needs to be made clear.

Section 3.2 states below

This mode of operation is only suitable for single-homing because in
   multi-homing the association between EVPN VPWS service tunnel and
   remote AC changes during the failure and therefore the VLANs
   (normalized VIDs) need to be signaled.

However section 3.2.1 states that multihome can use the default FXC mode,
however since multihome needs to signal as stated in section 3.2 it does not
seem that it can use the default FXC mode.  Please clarify.

3.2.1.  Multi-homing

   The default FXC mode can also be used for multi-homing.

Why don’t the normalized VIDs need to be signaled in BGP here for multihome?

Section 3.3

   In this solution, on each PE, the multi-homing ACs represented by
   their normalized VIDs are configured with a single EVI.  There is no
   need to configure VPWS service instance ID in here as it is the same
   as the normalized VID

Even though the normalized VID is the same as the VPN Service Instance ID, I
would think you would still need the Service Instance ID for for VPWS tunnel
creation.

In section 3.3 when the consistency check runs why does it not bring down the
VPWS or is the inconsistency superficial that it does not adversely effect
service.  Maybe should explain why the error does not bring down the service. 
This is like a false negative alarm.

Section 3.3.1 is local switching similar to analogy to RFC 8365 split horizon
local bias.

You should mention that there are only two new modes which you don’t realize
until you get to section 4 M mode bit.

M00 mode of operation as defined in [RFC8214]
01 VLAN-Signaled FXC
10 Default FXC

Section 3.2 you should call the default FXC mode 1 and section 3.3 mode 2

Section 3.4 which talks about V bit you should call it service normalization I
think makes more sense then service instantiation

Section 3.2.1

When the default FXC mode is used for multi-homing, instead of a
   single EVPN VPWS service tunnel, there can be many service tunnels
   per pair of PEs - i.e, there is one tunnel per group of VIDs per pair
   of PEs and there can be many groups between a pair of PEs, thus
   resulting in many EVPN service tunnels.

How are the VIDs grouped into the service tunnels.  If you have an interface
with many subintefaces are all the subinterfaces grouped together into the same
service tunnel.  Is the grouping  an implementation specific aspect?

s/normalisation//normalization

   If single VID normalisation is signaled in the Ethernet Tag ID field
   (12-bits) yet dataplane is operating based double tags, the VID
   normalisation applies only to outer tag.  If double VID normalisation
   is signaled in the

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[Gyan Mishra]

Hi Susan

Thanks for the heads up.

I will look out for the WG LC in IDR and BESS.

Kind Regards

Gyan

On Thu, Jul 7, 2022 at 7:40 PM Susan Hares  wrote:

> Gyan:
>
>
>
> IDR WG have also adopted
>
>
>
> draft-ietf-idr-sr-p2mp-policy-00
> <https://datatracker.ietf.org/doc/draft-ietf-idr-sr-p2mp-policy/>
>
>
>
> Jeffrey Zhang has joined as co-author.
>
> Work is undergoing in the author group
>
> To help align it to other work.
>
>
>
> It will be WG LC in IDR and BESS.
>
>
>
> Cheers, Sue
>
>
>
>
>
> *From:* BESS  *On Behalf Of * Gyan Mishra
> *Sent:* Monday, May 30, 2022 10:15 AM
> *To:* Rabadan, Jorge (Nokia - US/Sunnyvale) 
> *Cc:* Alexander Vainshtein ; Andrew Alston
> - IETF ; SPRING WG <
> spr...@ietf.org>; Stewart Bryant ; bess@ietf.org;
> mpls-chairs ; p...@ietf.org
> *Subject:* Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires
> and SR
>
>
>
>
>
> Other options for operators migrating to SR for Multicast P-Tree which is
> still being developed by vendors is BIER which is stateless.
>
>
>
> BGP Multicast Controller is a new solution which is being developed which
> uses TEA RFC 9012 for signaling encoding alternative to MVPN procedures
> defined in RFC 6513 and 6514  for P2P Tree PTA encoding.  This is based on
> BGP MCAST TREE SAFI defined in BGP Multicast draft. This draft provides a
> more general solution and as well supports both mLDP inband and out of band
> signaling as well as non mLDP based  SR use cases.
>
>
>
> BIER RFC 8296 & RFC 8279
>
>
>
> BGP Multicast
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00
>
>
>
>
>
> BGP Multicast Controller
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1
>
>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Mon, May 30, 2022 at 9:56 AM Gyan Mishra  wrote:
>
> I agree with Saha and Jorge as I stated in my response that the
> directional choice for use cases VPLS  E-Line, E-LAN, E-Tree signaling is
> to transition off LDP to BGP based signaling processing using EVPN for any
> L2 VPN use cases when migrating to Segment Routing both SR-MPLS and SRv6.
>
>
>
> As I mentioned in my initial response, part of the transition in the
> migration is to be able to use RFC 7473 Controlling State Advertisements of
> Non Negotiated LDP Applications, which provides a vendor knob to turn off
> LDP advertisements for unicast and selectively only allow on a per
> application basis for both L2 VPN  customers using T-DP for signaling and
> MVPN PTA application PTA mLDP P2MP and MP2MP.
>
>
>
> This knob allows the ability to create a slimmed down profile of LDP so
> it’s no longer used for Unicast application flows once all unicast is
> migrated to Segment Routing and selectively allows the per application SAC
> capabilities know to keep the applications requiring LDP to continue to use
> until the application has migrated off LDP.
>
>
>
> For multicast solutions operators have the option of TREE SID which uses
> the Replication SID in SR P2MP policy which has been implemented by most
> vendors.
>
>
>
> RFC 7473 SAC knob
>
> https://datatracker.ietf.org/doc/html/rfc7473
>
>
>
>
>
> Once all applications are migrated off LDP, LDP can be safely removed from
> the network.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Mon, May 30, 2022 at 6:02 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
> jorge.raba...@nokia.com> wrote:
>
> I concur with Sasha.
>
> We’ve been gone through a significant effort to unify the service
> signaling by using EVPN. If we are missing anything in EVPN VPWS compared
> to T-LDP based PWs, I would rather look at extending EVPN VPWS (if needed).
> If not an option, it would good to discuss at least why EVPN VPWS is not an
> option.
>
>
>
> Thanks,
>
> Jorge
>
>
>
>
>
> *From: *Pals  on behalf of Alexander Vainshtein <
> alexander.vainsht...@rbbn.com>
> *Date: *Monday, May 30, 2022 at 10:58 AM
> *To: *Stewart Bryant , Andrew Alston - IETF
> , mpls-chairs <
> mpls-cha...@ietf.org>
> *Cc: *SPRING WG , p...@ietf.org ,
> bess@ietf.org 
> *Subject: *Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
>
> Stewart, Andrew and all,
>
> ++ Bess WG.
>
> I fully agree that using (targeted) LDP for setup of Martini PWs in an
> SR-based environment is quite problematic for the operators.
>
>
>
> One alternative is transition to setup of PWs using MP BGP based on the
> EVPN-VPWS 

[bess] IETF 114 time slot update

[Gyan Mishra]

Hi Mankamana and chairs

One additional draft added below.

I have already requested a 10 minute time slot for the following drafts:

IPv6-Only PE design - updates on development work on this draft

https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/

IPV6 Only PE design  All SAFI - Introduction

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/

IPv4 Only PE design  - Introduction

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design/

*Additional draft added*

IPv4 Only PE design ALL SAFI - Introduction

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/


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

Re: [bess] FW: WG adoption call for draft-chen-idr-bier-te-path-04.txt (6/22/2022 to 7/6/2022

[Gyan Mishra]

I support WG Adoption.

This draft provides an appropriate BGP mechanism using a new AFI / SAFI and
TEA for a BGP controller to distribute BIER information to instantiate the
BIER TE path.

This a BGP centralized controller (SDN) mechanism to instantiate a BIER TE
path.

There is a another draft that provides a similar solution using PCECC
centralized SDN controller extension  to instantiate the BIER TE  path.

https://datatracker.ietf.org/doc/html/draft-chen-pce-controller-bier-te-03

Both solutions integrate well into the BIER TE architecture and provides
operator flexibility of using PCEP or BGP controller.

I agree that this BGP Controller based BIER TE mechanism would integrate
well into the BIER TE architecture.

BIER MVPN draft below provides a new BIER PTA tunnel ID addition to RFC
6513 & 6514 MVPN procedures.

https://datatracker.ietf.org/doc/html/draft-ietf-bier-mvpn

This draft is providing a centralized BGP controller based solution versus
a distributed solution, however I believe it could be applicable to a
distributed solution X-PMSI P-TREE instantiation of MVPN with the new BIER
PTA above draft which could use this drafts BGP mechanism in a distributed
fashion to instantiate the BIER TE path for the new BIER  PTA.

As most operators are moving towards If they have not already done so
towards a centralized SDN model versus a distributed or hybrid model, I
believe this draft will be highly valuable for operators deployment of
BIER-TE in an automated fashion.

Kind Regards

Gyan


On Wed, Jun 22, 2022 at 12:17 PM Susan Hares  wrote:

> Bess WG:
>
>
>
> IDR has begun an adoption call for draft-chen-idr-bier-te-path-04.txt.
>
> since this document specifies BGP mechanisms
>
> (an NLRI and additions to the BGP TEA), the adoption call
>
> Is going on in IDR.
>
>
>
> We welcome your comments on this draft on the IDR thread:
>
> (click below to go directly to the mail thread online)
>
> https://mailarchive.ietf.org/arch/msg/idr/tKgu_S5_32_l5YzWfO8481hpRRY/
>
>
>
> The IDR Chairs would appreciate feedback on
>
> how this interacts with existing multicast VPNs specifications
>
> existing (specified in the bess WG  or other WGs).
>
>
>
> Another avenue of input is to provide feedback directly to the
>
> bess chairs.   The IDR Chairs will be checking with the bess chairs
>
> prior to finalizing the adoption of this attribute.
>
>
>
> Cheers,
>
> Sue Hares
>
> (IDR co-chair, document shepherd)
>
>
>
>
>
> *From:* Susan Hares
> *Sent:* Wednesday, June 22, 2022 12:05 PM
> *To:* i...@ietf.org
> *Subject:* WG adoption call for draft-chen-idr-bier-te-path-04.txt
> (6/22/2022 to 7/6/2022
>
>
>
> This begins a 2 week Adoption call (6/22/2022 to 7/6/2022)
>
> for draft-chen-idr-bier-te-path-04.txt
>
> (https://datatracker.ietf.org/doc/draft-chen-idr-bier-te-path/).
>
>
>
> This draft provides extensions to BGP to distribute BIER
>
> (bit replication traffic/tree) data via BGP using a
>
> new NLRI (AFI = IPv4 or IPv6, new SAFI) and
>
> new options for the Tunnel Encapsulation Attribute (TEA).
>
> The NLRI includes an RD + Bier Domain tunnel identifier.
>
>
>
> In your comments, please consider if this draft:
>
>
>
> 1) Does this draft specify appropriate BGP mechanisms for
>
> a controller to distribute bier information?
>
>
>
> 2) Does this mechanism correctly integrates into
>
> a) the BIER architecture (draft-ietf-bier-te-arch) and
>
> b) Multicast VPNs (BESS)?
>
>
>
> 3) Will this technology aid the deployment of
>
> Bier multicast forwarding in operational networks?
>
>
>
> Cheers, Sue
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-redundant-mcast-source

[Gyan Mishra]

Dear WG

I support publication.

This draft is a very important draft for operators in the case of
redundancy with multicast sources and ensuring that the receivers don’t get
the duplicate packets using the procedures defined in the draft.

It is common to have multiple servers sending the same multicast flow as
well as multicast source redundantly connected to FHR and duplicate stream
and PIM assert pruning redundant stream.

Multicast redundancy is also commonly setup at application layer with a
pecking order and not all active simultaneously in a primary with N backup
servers.

I would like to mention that source redundancy can be done at the
application layer which is common with multicast streaming technologies.

Thanks

Gyan

On Wed, May 18, 2022 at 3:23 AM  wrote:

> Hello WG,
>
>
>
>
>
> This email starts a two weeks Working Group Last Call on 
> draft-ietf-bess-evpn-redundant-mcast-source
>
>  [1].
>
>
>
>
>
>
>
> This poll runs until * the 1th of June *.
>
>
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
>
> this Document, to ensure that IPR has been disclosed in compliance with IETF
>
> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>  If you are listed as an Author or a Contributor of this Document please
>
> respond to this email and indicate whether or not you are aware of any
>
> relevant undisclosed IPR. The Document won't progress without answers from
>
> all the Authors and Contributors.
>
>
>
> There is currently no IPR disclosed.
>
>
>
>
>
> If you are not listed as an Author or a Contributor, then please explicitly
>
> respond only if you are aware of any IPR that has not yet been disclosed in
>
> conformance with IETF rules.
>
>
>
>
>
> We are also polling for any existing implementation as per [2].
>
>
>
>
>
>
>
> Thank you,
>
>  Stephane & Matthew
>
>
>
>
>
> [1]
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/
>
>  [2]
>
>
>
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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] IETF 114 time slot

[Gyan Mishra]

Hi Mankamana and chairs

I will be attending in person in Philadelphia.

I would like to request a 10 minute time slot for the following drafts:

IPv6-Only PE design - updates on development work on this draft

https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/

IPV6 Only PE design  All SAFI - Introduction

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/

IPv4 Only PE design  - Introduction

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design/

Thank you

Gyan
-- 

<http://www.verizon.com/>

*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

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Gyan Mishra]

Hi Jeffrey

Thank you very much for the detailed descriptions on all the questions as
it really helped me understand the Multicast controller based solution.

This is a solid solution and I support the original draft as well as now
the SR P2MP related specification being ported into the combined draft.

One last comment related to the PE-CE.

So this original MVPN PE-CE draft referenced by the BGP Multicast draft
adapts MVPN to be used for the PE-CE link only and now with the BGP
Multicast draft with MCAST-TREE SAFI the joins are carried in BGP updates
 using S-PMSI / Leaf AD routes applying the same MVPN -TREE signaling that
has worked well for service providers to now be applied to customer CE
networks eliminating PIM soft state tree building protocols completely from
the network as well as applies to Service Providers mLDP, alternative to
use BGP Multicast alternative.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-pe-ce-01


So with the Controller draft, the focus is on applying new
Transport/Service controllers service provider core networks P-TREE
underlay or overlay using
the MCAST-TREE SAFI. So the controller draft applies as well to Service
Provider networks as well as customer CE networks.  I think as the solution
applies to both networks, however the controller in the SP network would
not be provisioning the customer network multicast anything past the PE-CE
demark, unless it was a SP managed customer network.  As the solution
applies to both customer and provider networks with both networks having
their own separate controller is what I would envision being deployed.  I
think in the draft it would be good to add clarity on that topic.


Many Thanks!!

Gyan

On Thu, May 26, 2022 at 5:34 PM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi Gyan,
>
>
>
> Please see zzh4> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Saturday, May 21, 2022 2:05 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Pleas see Gyan4>
>
>
>
> Kind Regards
>
>
>
> On Fri, May 20, 2022 at 10:59 AM Jeffrey (Zhaohui) Zhang <
> zzh...@juniper.net> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh3> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, May 12, 2022 11:29 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Responses in-line Gyan3>
>
>
>
> On Thu, May 5, 2022 at 9:43 AM Jeffrey (Zhaohui) Zhang 
> wrote:
>
> Hi Gyan,
>
>
>
> Gyan2> What is the advantage of using TEA encoding as opposed to existing
> PTA RFC 6513 & RFC 6514 MVPN signaling?
>
>
>
> This is about using procedures in draft-ietf-bess-bgp-multicast-controller
> to set up (s,g) forwarding state in a VRF, as an alternative to BGP-MVPN.
>
>  Gyan3> Ack.  I think a drawing of service and transport controller would
> be good and how that plays into the operator deployment.  Would there  be a
> corresponding draft in PCE WG for stateful PCE instantiation of the BGP
> based Trees by the controller?
>
> Zzh3> Will add a drawing in the next revision.
>
> Gyan4> Perfect!
>
> Zzh3> https://datatracker.ietf.org/doc/draft-li-pce-multicast/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-pce-multicast/__;!!NEt6yMaO-gk!Aj1Wmaxo7RsCY0Usz61SzT2jK1vae9WsofYzKp7bylIfQCAbkh9P59QWFarRUQlKeX8QM8yJPR9eAcvIjIriTA$>
> is the PCE counter part.
>
>
>
> Gyan4> Perfect!
>
> As described in
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-2
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09*section-2__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW4Fl3rldQ$>,
> instead of ingress/egress PE figuring out the (s,g) state based on BGP-MVPN
> signaling and PIM signaling (for local OIFs to CEs), they simply take
> instructions from a control on what tunnel branches and which local OIFs to
> use – as if an operator is configuring them statically. This allows the

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[Gyan Mishra]

Other options for operators migrating to SR for Multicast P-Tree which is
still being developed by vendors is BIER which is stateless.

BGP Multicast Controller is a new solution which is being developed which
uses TEA RFC 9012 for signaling encoding alternative to MVPN procedures
defined in RFC 6513 and 6514  for P2P Tree PTA encoding.  This is based on
BGP MCAST TREE SAFI defined in BGP Multicast draft. This draft provides a
more general solution and as well supports both mLDP inband and out of band
signaling as well as non mLDP based  SR use cases.

BIER RFC 8296 & RFC 8279

BGP Multicast

https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00


BGP Multicast Controller

https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1



Kind Regards

Gyan

On Mon, May 30, 2022 at 9:56 AM Gyan Mishra  wrote:

> I agree with Saha and Jorge as I stated in my response that the
> directional choice for use cases VPLS  E-Line, E-LAN, E-Tree signaling is
> to transition off LDP to BGP based signaling processing using EVPN for any
> L2 VPN use cases when migrating to Segment Routing both SR-MPLS and SRv6.
>
> As I mentioned in my initial response, part of the transition in the
> migration is to be able to use RFC 7473 Controlling State Advertisements of
> Non Negotiated LDP Applications, which provides a vendor knob to turn off
> LDP advertisements for unicast and selectively only allow on a per
> application basis for both L2 VPN  customers using T-DP for signaling and
> MVPN PTA application PTA mLDP P2MP and MP2MP.
>
> This knob allows the ability to create a slimmed down profile of LDP so
> it’s no longer used for Unicast application flows once all unicast is
> migrated to Segment Routing and selectively allows the per application SAC
> capabilities know to keep the applications requiring LDP to continue to use
> until the application has migrated off LDP.
>
> For multicast solutions operators have the option of TREE SID which uses
> the Replication SID in SR P2MP policy which has been implemented by most
> vendors.
>
> RFC 7473 SAC knob
> https://datatracker.ietf.org/doc/html/rfc7473
>
>
> Once all applications are migrated off LDP, LDP can be safely removed from
> the network.
>
> Thanks
>
> Gyan
>
> On Mon, May 30, 2022 at 6:02 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
> jorge.raba...@nokia.com> wrote:
>
>> I concur with Sasha.
>>
>> We’ve been gone through a significant effort to unify the service
>> signaling by using EVPN. If we are missing anything in EVPN VPWS compared
>> to T-LDP based PWs, I would rather look at extending EVPN VPWS (if needed).
>> If not an option, it would good to discuss at least why EVPN VPWS is not an
>> option.
>>
>>
>>
>> Thanks,
>>
>> Jorge
>>
>>
>>
>>
>>
>> *From: *Pals  on behalf of Alexander Vainshtein <
>> alexander.vainsht...@rbbn.com>
>> *Date: *Monday, May 30, 2022 at 10:58 AM
>> *To: *Stewart Bryant , Andrew Alston - IETF
>> , mpls-chairs <
>> mpls-cha...@ietf.org>
>> *Cc: *SPRING WG , p...@ietf.org ,
>> bess@ietf.org 
>> *Subject: *Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
>>
>> Stewart, Andrew and all,
>>
>> ++ Bess WG.
>>
>> I fully agree that using (targeted) LDP for setup of Martini PWs in an
>> SR-based environment is quite problematic for the operators.
>>
>>
>>
>> One alternative is transition to setup of PWs using MP BGP based on the
>> EVPN-VPWS mechanisms (RFC 8214
>> <https://datatracker.ietf.org/doc/html/rfc8214>).
>>
>>
>>
>> These mechanisms probably require some extension to support PWs that
>> carry non-Ethernet customer traffic as well as support of some features
>> that can be signaled via LDP for Ethernet PWs but cannot be signaled today
>> with EVPN-VPWS (e.g., FCS retention – RFC 4720
>> <https://datatracker.ietf.org/doc/html/rfc4720>).
>>
>>
>>
>> My guess is that, once the basic EVPN-VPWS signaling is supported,
>> migration of LDP-signaled PWs to EVPN-VPWS would be simple enough.
>>
>>
>>
>> This work, if approved, would require intensive cooperation between PALS
>> WG and BESS WG.
>>
>>
>>
>> My 2c,
>>
>> Sasha
>>
>>
>>
>> Office: +972-39266302
>>
>> Cell:  +972-549266302
>>
>> Email:   alexander.vainsht...@rbbn.com
>>
>>
>>
>> *From:* Pals  *On Behalf Of *Stewart Bryant
>> *Sent:* Monday, May 30, 2022 11:10 AM
>> *To:* Andrew Alston - IETF ;
>> p...@ietf.org; mp

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[Gyan Mishra]

oblem, because typically you don’t want to run LDP in an SR
> context.  This means that standard martini pseudowires no longer function.
> This gets even more complicated when you want to do martini based
> pseudowires over an IPv6 only network, particularly considering the lack of
> widespread support for LDP6.
>
>
>
> This is also relevant in cases where networks wish to run SR-MPLS in the
> absence of SRv6 for whatever reason.
>
>
>
> So, my question to the working group is this:
>
>
>
> Is it worth looking at creating a form of LDP light – both compatible with
> IPv4 and IPv6 – that simply exists to setup and tear down the service
> labels for point to point services.  A form of targeted LDP without all the
> other complexities involved in LDP – that could potentially run at a lower
> preference than LDP itself (so if LDP is there, use it, if not use this)
>
>
>
> Before I start drafting though, I would like to hear from the working
> group if there are others who feel that this is worth doing and, call this
> a call for expressions of interest in those who may be willing to work
> towards something like this.  Happy to take emails on list or off list and
> see if we can find a solution.
>
>
>
> Looking forward to hearing from you all
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> ___
> spring mailing list
> spr...@ietf.org
>
> https://clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> ___
> Pals mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pals
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Enhancing lsp ping (in extension to draft-ietf-bess-evpn-lsp-ping)

[Gyan Mishra]

Excellent!

Thank you

Gyan

On Fri, May 20, 2022 at 1:27 PM Dikshit, Saumya 
wrote:

> Thanks Gyan. I will add you in the next version in a weeks time, as on
> road till then.
>
> Yes, 2 out of 3 requirements are equally applicable to mpls underlay. I
> think i have mentioned it in few places in the doc, else we can add a
> section to call it out.
>
> Regards,
> Saumya.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------
> *From:* Gyan Mishra 
> *Sent:* Friday, 20 May 2022, 19:58
> *To:* Dikshit, Saumya 
> *Cc:* BESS ; Greg Mirsky ; Parag
> Jain (paragj) ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org <
> draft-ietf-bess-evpn-lsp-p...@ietf.org>
> *Subject:* Re: Enhancing lsp ping (in extension to
> draft-ietf-bess-evpn-lsp-ping)
>
> Hi Saumya
>
> I reviewed the draft and the bullet points requirements in your earlier
> email and the draft looks good and I would be happy to collaborate on this
> effort.
>
> I agree this LSP ping extension will help with troubleshooting CP-DP
> issues that are extremely  difficult to resolve in NVO environments.
>
> Is the primary focus for DC NVO encapsulation environments and secondarily
> for MPLS underlay environments?
>
> Kind Regards
>
> Gyan
>
> On Thu, May 19, 2022 at 4:53 AM Dikshit, Saumya 
> wrote:
>
>> Hello All,
>>
>>
>>
>> We have published a new draft
>> https://datatracker.ietf.org/doc/draft-saum-evpn-lsp-ping-extension/
>>
>> The intention is to deal with the requirements mentioned in the email
>> chain below.
>>
>> This is the outcome of comments which I had made while reviewing “
>> draft-ietf-bess-evpn-lsp-ping”
>>
>> and consensus was that it can be dealt in a separate document.
>>
>>
>>
>> Please provide your comments and help evolving it further.
>>
>>
>>
>> Regards,
>>
>> Saumya.
>>
>>
>>
>> *From:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Dikshit,
>> Saumya
>> *Sent:* Monday, October 25, 2021 8:23 PM
>> *To:* Greg Mirsky 
>> *Cc:* Parag Jain (paragj) ;
>> draft-ietf-bess-evpn-lsp-p...@ietf.org; Gyan Mishra <
>> hayabusa...@gmail.com>; BESS 
>> *Subject:* [bess] Enhancing lsp ping (in extension to
>> draft-ietf-bess-evpn-lsp-ping)
>>
>>
>>
>> [Changing the subject line]
>>
>> Summarizing the requirements:
>>
>> 1.  Allow wild-card/don’t-care values for attributes carried in the
>> sub-TLVs as it will surely help when all details are not available. To draw
>> parallels I see it equivalent to querying for an (potential) NLRI in a
>> BGP-EVPN RIB via a management interface, where in all parameters hard to
>> gather.  The permutation & combinations can be listed down in detail, in
>> course of discussion.
>>
>> 2. Test the reachability to tenant-VRF VRF_X (with EVPN mapped EVI)
>> configured on the remote PE, PE1. VRF_X has *no active IP/IPv6 interface
>> configured* and its sole usage is to *obtain the leaked (via IVRL)
>> routes* from other VRFs (non-EVPN) and PE1 publishes this to other peers
>> via EVPN control plane. Till the first prefix (learnt ) route is published
>> (Route Type 5) by PE1 for the EVI (mapped to VRF_X), the tunnels will not
>> be provisioned on other PEs. Hence an lsp-ping to validate the
>> configuration of VRF_X on remote PE should help here.
>>
>> 3.   To choose between a mode, where the CP-DP consistency check can be
>> relaxed only to perform a DP lookup. The modes can be
>>
>>   - CP-DP Consistency Check mode
>>
>>   - DP only check
>>
>> Please feel free to add. If this can be generalized for any solution
>> (EVPN, L3VPN, L2VPN->VPLS/VPWS) provisioned over MPLS fabric.
>>
>> Thanks
>>
>> Saumya.
>>
>>
>>
>>
>>
>> *From:* Dikshit, Saumya
>> *Sent:* Monday, October 18, 2021 9:28 AM
>> *To:* Greg Mirsky 
>> *Cc:* Gyan Mishra ; Parag Jain (paragj) <
>> paragj=40cisco@dmarc.ietf.org>; BESS ;
>> draft-ietf-bess-evpn-lsp-p...@ietf.org
>> *Subject:* RE: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>>
>>
>>
>> Hi Greg, Parag, Gyan, et al.
>>
>>
>>
>> Let me start a fresh email with an apt subject line, collating all
>> bullets from earlier exchanges.
>>
>>
>>
>> Thanks
>>
>> Saumya.
>>
>>
>>
>> *From:* Greg Mirsky [mailto:gregimir...@gmail.com ]
>>
>> *Sent:* Friday, October 15, 20

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Gyan Mishra]

Hi Jeffrey

Pleas see Gyan4>

Kind Regards

On Fri, May 20, 2022 at 10:59 AM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi Gyan,
>
>
>
> Please see zzh3> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, May 12, 2022 11:29 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Responses in-line Gyan3>
>
>
>
> On Thu, May 5, 2022 at 9:43 AM Jeffrey (Zhaohui) Zhang 
> wrote:
>
> Hi Gyan,
>
>
>
> Gyan2> What is the advantage of using TEA encoding as opposed to existing
> PTA RFC 6513 & RFC 6514 MVPN signaling?
>
>
>
> This is about using procedures in draft-ietf-bess-bgp-multicast-controller
> to set up (s,g) forwarding state in a VRF, as an alternative to BGP-MVPN.
>
>  Gyan3> Ack.  I think a drawing of service and transport controller would
> be good and how that plays into the operator deployment.  Would there  be a
> corresponding draft in PCE WG for stateful PCE instantiation of the BGP
> based Trees by the controller?
>
> Zzh3> Will add a drawing in the next revision.
>
Gyan4> Perfect!

> Zzh3> https://datatracker.ietf.org/doc/draft-li-pce-multicast/ is the PCE
> counter part.
>

Gyan4> Perfect!

> As described in
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-2
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09*section-2__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW4Fl3rldQ$>,
> instead of ingress/egress PE figuring out the (s,g) state based on BGP-MVPN
> signaling and PIM signaling (for local OIFs to CEs), they simply take
> instructions from a control on what tunnel branches and which local OIFs to
> use – as if an operator is configuring them statically. This allows the PEs
> to be very dumb and simple.
>
Gyan4> Understood.  Makes sense.


>  Gyan3>  So this is simplified MVPN signaling state paired down from RFC
> 6514 using same RR or eBGP mesh peering single or multi hop using
> MCAST-TREE SAFI new route types defined in BGP Multicast section 2 carrying
> the s,g hard state in BGP eliminating soft state, and extends the TEA
> encoding defined in BGP Multicast to as well SR use cases.
>
> Zzh3> There was no soft state in RFC 6514 anyway.
>
 Gyan> BGP MVPN P-Tree signaling is hard state with separation of
control plane and data plane as compare to PIM ASM, SSM tree building soft
state.

> The key is that instead of PEs figuring out (s,g) forwarding state based
> on MVPN routes, they simply take instructions from the controller. Dumb but
> simple routers with omniscient/omnipotent controllers.
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00#section-2.1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00*section-2.1__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW6NPliK9w$>
>
>  Gyan4>  As mentioned above a drawing would be most helpful as the
> transport controller now  sits attached to the forwarding plane with P-Tree
> signaling relaying instructions to the ingress/egress PEs to build the
> P-Tree forwarding state.  So instead of the standard ingress/egress PE MVPN
> state machine signaling, now the controller is in the mix intercepting the
> P-Tree signaling in-line receiving the MCAST-TREE Leaf-AD route and
> advertises the MCAST-TREE replication state route to setup the c-multicast
> from ingress to egress similar to MVPN Auto discovery PMSI-I/S - Leaf AD
> exchange to build the inclusive / selective tree. So the PEs are dumb down
> in that there is no Ingres/egress PE signaling, however there is still
> P-TREE signaling to the controller. So if the P-TREE is not part of an SR
> policy thus no BSID then the replication branches are encoded in the TEA or
> otherwise in the BSID which would have the P2MP SID list in the policy
> which when the BSID is popped by the ingress PE is pushed onto the label
> stack. So for the mLDP case (non SR) a PTA would be attached to the
> P-Tunnel on ingress PE with TEA encoding the replication branches would the
> replication branches be over the provider core not the PE-CE interfaces.
> We are talking about the Ingres PE replication branches to the egress PEs
> so why would th

Re: [bess] Enhancing lsp ping (in extension to draft-ietf-bess-evpn-lsp-ping)

[Gyan Mishra]

Hi Saumya

I reviewed the draft and the bullet points requirements in your earlier
email and the draft looks good and I would be happy to collaborate on this
effort.

I agree this LSP ping extension will help with troubleshooting CP-DP issues
that are extremely  difficult to resolve in NVO environments.

Is the primary focus for DC NVO encapsulation environments and secondarily
for MPLS underlay environments?

Kind Regards

Gyan

On Thu, May 19, 2022 at 4:53 AM Dikshit, Saumya 
wrote:

> Hello All,
>
>
>
> We have published a new draft
> https://datatracker.ietf.org/doc/draft-saum-evpn-lsp-ping-extension/
>
> The intention is to deal with the requirements mentioned in the email
> chain below.
>
> This is the outcome of comments which I had made while reviewing “
> draft-ietf-bess-evpn-lsp-ping”
>
> and consensus was that it can be dealt in a separate document.
>
>
>
> Please provide your comments and help evolving it further.
>
>
>
> Regards,
>
> Saumya.
>
>
>
> *From:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Dikshit, Saumya
> *Sent:* Monday, October 25, 2021 8:23 PM
> *To:* Greg Mirsky 
> *Cc:* Parag Jain (paragj) ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org; Gyan Mishra ;
> BESS 
> *Subject:* [bess] Enhancing lsp ping (in extension to
> draft-ietf-bess-evpn-lsp-ping)
>
>
>
> [Changing the subject line]
>
> Summarizing the requirements:
>
> 1.  Allow wild-card/don’t-care values for attributes carried in the
> sub-TLVs as it will surely help when all details are not available. To draw
> parallels I see it equivalent to querying for an (potential) NLRI in a
> BGP-EVPN RIB via a management interface, where in all parameters hard to
> gather.  The permutation & combinations can be listed down in detail, in
> course of discussion.
>
> 2. Test the reachability to tenant-VRF VRF_X (with EVPN mapped EVI)
> configured on the remote PE, PE1. VRF_X has *no active IP/IPv6 interface
> configured* and its sole usage is to *obtain the leaked (via IVRL) routes*
> from other VRFs (non-EVPN) and PE1 publishes this to other peers via EVPN
> control plane. Till the first prefix (learnt ) route is published (Route
> Type 5) by PE1 for the EVI (mapped to VRF_X), the tunnels will not be
> provisioned on other PEs. Hence an lsp-ping to validate the configuration
> of VRF_X on remote PE should help here.
>
> 3.   To choose between a mode, where the CP-DP consistency check can be
> relaxed only to perform a DP lookup. The modes can be
>
>   - CP-DP Consistency Check mode
>
>   - DP only check
>
> Please feel free to add. If this can be generalized for any solution
> (EVPN, L3VPN, L2VPN->VPLS/VPWS) provisioned over MPLS fabric.
>
> Thanks
>
> Saumya.
>
>
>
>
>
> *From:* Dikshit, Saumya
> *Sent:* Monday, October 18, 2021 9:28 AM
> *To:* Greg Mirsky 
> *Cc:* Gyan Mishra ; Parag Jain (paragj) <
> paragj=40cisco@dmarc.ietf.org>; BESS ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org
> *Subject:* RE: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Greg, Parag, Gyan, et al.
>
>
>
> Let me start a fresh email with an apt subject line, collating all bullets
> from earlier exchanges.
>
>
>
> Thanks
>
> Saumya.
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com ]
>
> *Sent:* Friday, October 15, 2021 8:34 AM
> *To:* Dikshit, Saumya 
> *Cc:* Gyan Mishra ; Parag Jain (paragj) <
> paragj=40cisco@dmarc.ietf.org>; BESS ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org
> *Subject:* Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Saumya,
>
> you've brought up several good cases that we can solve using the EVPN LSP
> Ping. Let's start with them as the problem statements. Then we discuss how
> to solve them.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Oct 14, 2021 at 3:31 AM Dikshit, Saumya 
> wrote:
>
> Thanks Gyan,Parag.
>
> Please suggest, how do we trigger the discussion.
>
> I can a Spin-out a rev-0 for a new draft. Let me know your thoughts.
>
>
>
> Regards,
>
> Saumya.
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* Wednesday, October 13, 2021 8:41 PM
> *To:* Parag Jain (paragj) 
> *Cc:* BESS ; Dikshit, Saumya ;
> Greg Mirsky ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org
> *Subject:* Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
>
>
> Hi Saumya & Greg
>
>
>
> I would be happy to work on collaboration of this new draft as I can
> provide an operational POV on criticality on CP - DP consistency check
> validation for network

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Gyan Mishra]

ew being added or are we just reiterating section 2.4.4 of
SR policy draft.  If nothing is changing and we are using the same sub TLV
in SR policy section 2.4.4 maybe state that is the case.  So all the other
sub TLV listed in section 3 are all new sub TLV that would update SR policy
draft TEA encoding of sub TLVs, correct?  As the SR policy draft is the
base draft for SR policy, here with this draft we are extending the SR
policy TEA encoding with all the additional TLVs listed.

Section 3.1.7 Backup Tunnel Sub TLV

Could this apply to unicast P2P tunnel  and not just multicast P2MP tunnel
 for backup tunnel for live-live protection?

Section 3.4.2 BGP Community container

SR policy draft does not use BGP Wide communities for encoding.

So this would be something new that we would be encoding the SR P2MP policy
using BGP Wide Community new optional atoms TLV.

Could this also apply to unicast SR P2P policy as well?

What is the benefit of encoding the SR P2MP policy  in wide community
containers versus encoding as defined in SR policy draft?

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17

Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, April 28, 2022 12:19 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Please see Gyan2>
>
>
>
> On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang <
> zzh...@juniper.net> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh2> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Friday, April 8, 2022 8:48 PM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Please see Gyan>
>
>
>
>
>
> On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang 
> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh> below for my view.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Tuesday, March 29, 2022 10:31 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Dear authors
>
>
>
> Can you describe in more detail the relationship and interaction between
> the two SR P2MP variants below:
>
>
>
> Defines new SAFI for SR P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>
>
>
>
> zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess)
> defines a SAFI and different route types of that SAFI to setup replication
> state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP
> purposes.
>
> Zzh2> Correction – the MCAST-TREE SAFI is defined in
> draft-ietf-bess-bgp-multicast.
>
>
>
>Gyan> Ack
>
> Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to
> as draft-hb) defines a different SAFI and route types for the same SR-P2MP
> purposes.
>
>  Gyan> The adoption call draft is aligned with SR-TE policy as P2MP
> extension for simplicity for operators which I agree makes sense.
>
> Does this draft utilize all the drafts below Tree sid / Replication sid
> and SR P2MP MVPN procedures for auto discovery etc.
>
>
>
> Zzh> Both drafts are for realizing the two tree-sid drafts mentioned
> below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>  Gyan> Ack
>
> Zzh> As I mentioned before, both draft-bess and draft-hb have its own
> considerations. The biggest difference is how the replication information
> is encoded in the Tunnel Encapsulation Attribute (TEA).
>
>
>
> Gyan> Ack
>
> Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accep

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Gyan Mishra]

Hi Jeffrey

Please see Gyan2>

On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi Gyan,
>
>
>
> Please see zzh2> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Friday, April 8, 2022 8:48 PM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Please see Gyan>
>
>
>
>
>
> On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang 
> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh> below for my view.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Tuesday, March 29, 2022 10:31 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Dear authors
>
>
>
> Can you describe in more detail the relationship and interaction between
> the two SR P2MP variants below:
>
>
>
> Defines new SAFI for SR P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>
>
>
>
> zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess)
> defines a SAFI and different route types of that SAFI to setup replication
> state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP
> purposes.
>
> Zzh2> Correction – the MCAST-TREE SAFI is defined in
> draft-ietf-bess-bgp-multicast.
>
>
>
>Gyan> Ack
>
> Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to
> as draft-hb) defines a different SAFI and route types for the same SR-P2MP
> purposes.
>
>  Gyan> The adoption call draft is aligned with SR-TE policy as P2MP
> extension for simplicity for operators which I agree makes sense.
>
> Does this draft utilize all the drafts below Tree sid / Replication sid
> and SR P2MP MVPN procedures for auto discovery etc.
>
>
>
> Zzh> Both drafts are for realizing the two tree-sid drafts mentioned
> below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>  Gyan> Ack
>
> Zzh> As I mentioned before, both draft-bess and draft-hb have its own
> considerations. The biggest difference is how the replication information
> is encoded in the Tunnel Encapsulation Attribute (TEA).
>
>
>
> Gyan> Ack
>
> Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both
> ways of encoding replication information in the TEA, but I believe we
> should share SAFI and route types between the two drafts – only the TEA
> would be different.
>
>
>
> Gyan> Both the BESS and IDR adoption draft are vastly different solutions
> that have very different goals I don’t see any reason or need to have
> similarities as far as TEA or SAFI encodings or usage.  The BGP controller
> draft has a very wide scope, but also is more of an alternative approach as
> it introduces new extensibility idea of utilizing TEA and wide communities
> encoding to make the solution RFC 6513 and 6514 MVPN signaling
> independent.  That is a drastic change for scalability for operations
> traditional use of multicast X-PMSI P-Tree  leveraging the separation of
> control plane from forwarding plane with RR using traditional MVPN
> procedures.  As the ideas from the BESS draft as it builds on the BGP
> Multicast draft is to eliminate soft state tree building protocols and with
> the move towards hard state, thus the signaling paradigm change from
> traditional MVPM procedures to alternate TEA and wide community encoding.
> Am I reading that correctly as the goals of the BESS draft?
>
>
>
> Zzh2> Not really 😊
>
>  Gyan> Ok
>
> The BESS document also mentions that the solution can be used for underlay
> and overlay trees as replacement for MVPN signaling.  For underlay trees
> are you referring to GTM?  I have many more questions about the BESS draft
> and will ask in a new thread.
>
>
>
> Zzh2> draft-ietf-bess-bgp-multicast-controller was initially intended to
> build traditiona

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Gyan Mishra]

Hi Jeffrey

Please see Gyan>


On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi Gyan,
>
>
>
> Please see zzh> below for my view.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra 
> *Sent:* Tuesday, March 29, 2022 10:31 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com>; Susan Hares ; i...@ietf.org;
> p...@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Dear authors
>
>
>
> Can you describe in more detail the relationship and interaction between
> the two SR P2MP variants below:
>
>
>
> Defines new SAFI for SR P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>
>
>
>
> zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess)
> defines a SAFI and different route types of that SAFI to setup replication
> state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP
> purposes.
>

   Gyan> Ack

> Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to
> as draft-hb) defines a different SAFI and route types for the same SR-P2MP
> purposes.
>
>  Gyan> The adoption call draft is aligned with SR-TE policy as P2MP
> extension for simplicity for operators which I agree makes sense.
>
> Does this draft utilize all the drafts below Tree sid / Replication sid
> and SR P2MP MVPN procedures for auto discovery etc.
>
>
>
> Zzh> Both drafts are for realizing the two tree-sid drafts mentioned
> below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>  Gyan> Ack
>
> Zzh> As I mentioned before, both draft-bess and draft-hb have its own
> considerations. The biggest difference is how the replication information
> is encoded in the Tunnel Encapsulation Attribute (TEA).
>

Gyan> Ack

> Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both
> ways of encoding replication information in the TEA, but I believe we
> should share SAFI and route types between the two drafts – only the TEA
> would be different.
>

Gyan> Both the BESS and IDR adoption draft are vastly different
solutions that have very different goals I don’t see any reason or need to
have similarities as far as TEA or SAFI encodings or usage.  The BGP
controller draft has a very wide scope, but also is more of an alternative
approach as it introduces new extensibility idea of utilizing TEA and wide
communities encoding to make the solution RFC 6513 and 6514 MVPN signaling
independent.  That is a drastic change for scalability for operations
traditional use of multicast X-PMSI P-Tree  leveraging the separation of
control plane from forwarding plane with RR using traditional MVPN
procedures.  As the ideas from the BESS draft as it builds on the BGP
Multicast draft is to eliminate soft state tree building protocols and with
the move towards hard state, thus the signaling paradigm change from
traditional MVPM procedures to alternate TEA and wide community encoding.
Am I reading that correctly as the goals of the BESS draft?  The BESS
document also mentions that the solution can be used for underlay and
overlay trees as replacement for MVPN signaling.  For underlay trees are
you referring to GTM?  I have many more questions about the BESS draft and
will ask in a new thread.

> Zzh> Jeffrey
>
>
>
> Defines Tree SID stitching of replication SID SR policy P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3gdi0hAB$>
>
>
>
> Replication SID
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3smIMNzh$>
>
>
>
> Defines new SR P2MP PTA using MVPN procedures
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3g-W3jH0$>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
&

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Gyan Mishra]

> If you just wish to respond to the IDR list,
>
> you may respond to this email on the adoption call.
>
>
>
> Cheers, Sue
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org ] *On
> Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 9:55 AM
> *To:* i...@ietf.org; p...@ietf.org; bess@ietf.org
> *Subject:* [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
>
>
>
> This begins a 2 week WG adoption call for:
>
> draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)
>
>
>
> You can obtain the draft at:
>
> https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>
>
>
>
> In your comments for this call please consider:
>
>
>
> Zzh> I want to point out that
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$>
> is another way to do the same. I also explained in
> https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$>
> why it was in the bess WG.
>
> Zzh> In addition, the bess draft supports **other** multicast trees (IP,
> mLDP besides SR-P2MP) using a consistent way.
>
>
>
> 1)  Does this technology support the SR P2MP features
>
> that distributes candidate paths which connect
>
> a multicast distribution tree (tree to leaves).
>
>
>
> Zzh> It is one way to use BGP to support that. The bess draft specifies
> another way.
>
>
>
> 2) Is the technology correctly specified for the
>
> NLRI (AFI/SAFI) and the tunnel encapsulation attribute
>
> additions (sections 2 and 3)?
>
>
>
> Zzh> The specified SAFI and tunnel encapsulation attribute additions are
> one way for the BGP signaling for SR-P2MP. The bess draft specifies another
> way.
>
>
>
> 3) Does the P2MP policy operation (section 4)
>
> provide enough information for those implementing this
>
> technology and those deploying the technology?
>
>
>
> 4) Do you think this multicast technology is a good
>
> Place to start for P2MP policy advertisement via BGP?
>
>
>
> Zzh> Both ways are good place to start. We just need to figure out how to
> proceed with the two proposals.
>
>
>
> 5) Do you think this SR P2MP policies should not be advertised
>
> via BGP?
>
>
>
> Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to
> discuss the two ways and figure out how to proceed. The authors have
> discussed before though we have not reached consensus.
>
> Zzh> Thanks!
>
> Zzh> Jeffrey
>
>
>
> Cheers, Susan Hares
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi Ketan

Responses in-line



On Thu, Mar 17, 2022 at 1:15 PM Ketan Talaulikar 
wrote:

> Hi Gyan,
>
> Please check inline below for responses.
>
>
> On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra  wrote:
>
>>
>> Hi Ketan
>>
>> I reviewed the updated security considerations section and the update
>> looks good.  As well section 10.3 Data plane considerations and read again
>> the referenced documents security considerations section of RFC 8402, RFC
>> 8986, RFC 8754 and RFC 8996.  All looks very good.
>>
>> One question I had was that if operators only advertises the SRv6 summary
>> block B:N::/48 to the internet, the summarization route would not contain
>> the embedded BGP Prefix SID attribute encoding of L2 and L3 Service SID in
>> the FUNCT field of the SRv6 SID.
>>
>> If you agree with what I have stated , then that would limit the exposure
>> drastically related to service SID leakage to the internet.
>>
>
> KT> I agree. However, an even better approach is simply not even
> advertising the reachability for the SRv6 summary block on the Internet.
> This way, it becomes challenging for someone on the Internet to send
> packets to any SRv6 Locators/SIDs belonging to the provider. Also, as
> discussed in RFC8986, the allocation of SRv6 Block from the ULA space is
> another technique to mitigate this.
>
>
Gyan> Can we add that in the considerations section as I think that
will help with John and Warrens security concerns with sid leakage.

>
>> The security exposure is related to only the inter-as peering lateral,
>> provider or RS peering and not customer peering as the SRv6 source node
>> encapsulates customer traffic into payload of outer IPv6 header.  So I
>> think customer  PE-CE edge peering would not be a security issue.
>>
>> Also another thought is that within an SRv6 domain as next hop self is
>> used internally on any inter-as lateral, provider or RS ties which is done
>> on both ends of the peering between operators, does the SRv6 B:N::/48
>> underlay block even need to be advertised externally.
>>
>
> KT> It doesn't and should not be advertised externally.
>

   Gyan> Excellent.  I think explicit verbiage to block externally would be
good.

>
>
>> As the BGP overlay is what holds the internet table and that is all that
>> needs transitivity for internet route reachability.  That would further
>> reduce the exposure of data plane service sid encoding in SRv6 SID leaking
>> to the internet.
>>
>
> KT> Correct.
>
>
>>
>> As far as SRv6 service capabilities draft below, my thoughts are as any
>> parallel multi transport that exists would only be done within the confines
>> of a domain within the same operators Administrative domain and not between
>> providers which would also be limited during a transition from brown field
>> MPLS or SR-MPLS to a parallel Green field SRv6 transport.  As this use case
>> is all within the same domain, careful design is on the onus of the
>> operator as relates to SRv6 to MPLS BGP overlay interoperability for SAFI
>> 128.  So I don’t see this as a major issue for operators as all the careful
>> considerations will be taken for that interoperability as well as there are
>> many underlying solutions for SRv6 to MPLS or SR-MPLS interoperability.
>>
>> This is more of an interoperability issue use case that could be
>> considered orthogonal to this draft that only exists within an operators
>> network during migration.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02
>>
>
> KT> Agree that this topic is orthogonal but is also somewhat complex and
> we (WG) need to continue work on this separate from this base document.
>

   Gyan> Understood.

Thanks

>
> Thanks,
> Ketan
>
>
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Mar 5, 2022 at 4:40 AM Ketan Talaulikar 
>> wrote:
>>
>>> Hi John,
>>>
>>> We've just posted an update to the draft to address the comments raised
>>> and to clarify the security considerations.
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12
>>>
>>> Thanks,
>>> Ketan
>>>
>>>
>>> On Thu, Feb 24, 2022 at 3:42 PM Robert Raszuk  wrote:
>>>
>>>> Hi John,
>>>>
>>>> You have highlighted below a very important point. It was discussed
>>>> among co-authors, but perhaps not sufficiently during the BESS process as
>>>> the issue is real

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Gyan Mishra]

; It’s not my preference to get into the minutiae of this argument as part
>>> of this discuss. However, I’d like to ask: was this consideration something
>>> the WG discussed? I looked for discussion of
>>> draft-lz-bess-srv6-service-capability in the archives and didn’t find much —
>>>
>>> - When an earlier version was posted to the list it resulted only in
>>> discussion between the original author, Liu Yao, and Eduard Metz, who
>>> became co-author, but there wasn’t any discussion I saw of the actual issue
>>> that the draft identified, but rather refinement of the mitigation it
>>> proposes (which I don’t want to discuss in this note).
>>> - There was an agenda slot request for the draft at IETF-111. It was on
>>> the agenda in the “if time allows” section. I assume time did NOT allow
>>> because I don’t see mention of it in the minutes. (I did find the slides,
>>> slides 3 and 4 summarize the critique,
>>> https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-srv6-service-capability-00
>>> ).
>>>
>>> But of course, the issue raised might have been discussed by the WG in a
>>> different thread, that doesn’t match a search for
>>> draft-lz-bess-srv6-service-capability. If so, I’d appreciate a pointer to
>>> it.
>>>
>>> If there wasn’t any discussion in the WG of the authors’ critique, I
>>> think it deserves to be discussed a bit as part of this thread. In
>>> particular, does the “this is the same as the trick EVPN does in RFC 8365”
>>> reply apply equally? Probably it does, although that might boil down to
>>> “gosh, we should have caught this when publishing 8365, shouldn’t we?”
>>>
>>> Even if the outcome of the discussion is that the limitation was
>>> discussed by the WG/isn’t a big deal because reasons/maybe it’s a big deal
>>> but we’ll fix it in a followup… as I mentioned earlier, covering it in the
>>> Security Considerations seems worthwhile.
>>>
>>> Thanks,
>>>
>>> —John
>>
>> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi Robert

Agreed.  A new SAFI for VPN and even MVPN application service encoding with
multiple transports adds quite lot of complexity.

The P2P one hop nature of MP Reach has been a Day 1 issue that has been
problematic to troubleshoot and that would be great if you have a solution
that does a dynamic capabilities discovery and push maybe a Pub/Sub model
would work.

The security implications of SRv6 transport encoding of what normally would
be in MPLS shim and with the label stack is automatically limited to the
MPLS domain.  However  with SRV6 BGP prefix SID attribute encoding of VPN
label into the ARG field of the SRV6 SID is a definite security
consideration which was identified in RFC 8402 to take the best practices
of securing the edges.

I think with Ketan update of the verbiage in the security considerations
should highlight to operators that this issue exists and to carefully
protect against the leakage.

Kind Regards

Gyan

On Tue, Mar 8, 2022 at 7:04 AM Robert Raszuk  wrote:

> Dear Yao,
>
> The issue is not related to support or no support of a new feature
> although that is also not well addressed in current BGP-4 specification.
> The question is about coexistence of multiple transports and
> service encoding for the same application.
>
> I have a separate proposal on this, but did not post it before the cut off
> date. So expect more on this after IETF in Vienna.
>
> Best,
> R.
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 8, 2022 at 5:00 AM  wrote:
>
>> Hi Robert,
>>
>> Thanks for sharing your detailed consideration on BGP capability and new
>> NLRI.
>> A few comments about the BGP capability solution. Please see inline [YAO].
>>
>>
>> ==
>>
>> In BGP protocol any new service deployment using existing AFI/SAFI is not
>> easy. Especially when you are modifying content of MP_REACH or MP_UNREACH
>> NLRI attributes. Main reason being is that using capabilities only goes
>> one
>> hop. In full mesh it all works perfect, but the moment you put RR in
>> between BGP speakers things are getting ugly as capabilities are not
>> traversing BGP nodes. /* Even in full mesh mixing transports for the same
>> service is a serious challenge for routers when say multihomes sites are
>> advertised from different PEs with different transport options */.
>>
>> [YAO] As you mentioned, in the scenario multihomes sites are advertised
>> from different PEs with different transport options without RR, e.g, CE1
>> are connected to PE1 and PE2, PE1 supports MPLS VPN while PE2 support SRv6
>> VPN, PE3 is the peer of PE1 and PE2, imagine PE3 supports both
>> capabilities,  I don't think this brings much difference between the
>> configuration approach and BGP capability approach.
>> If BGP capability is introduced, PE3 will receive both MPLS VPN and BGP
>> VPN routes, how to process them is based on user's requirement,e.g,
>> choosing one fixed type of routes, using the lastest routes, ECMP and so on.
>> If configuration approach is used, how to configure is based user's
>> requirement as well. Before configuration on PE1 and PE2, one should first
>> decide whether PE3 wants to receive only one type of route or to receive
>> both routes. And if PE3 receive both routes, the processing rule also
>> should be considered.
>> In a word, in scenario like this, the consideration on user's requirement
>> is similar in both approach.
>>
>> Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily
>> sends a new format of the UPDATE messages. Well as today we also do not
>> have a notion of conditional capabilities (only send when received from
>> all) so if some of the RR peers do not support it you end up in partial
>> service. One can argue that in this case the only deterministic model is
>> to
>> push the configuration from the management station and control partial
>> deployment of the new service from mgmt layer.
>>
>> [YAO] By saying "RR peers", do you mean that in the scenario that
>> there're multiple RRs, and they're peers of each other, if some of the RRs
>> don't support the new BGP capability, the SRv6 service routes will not be
>> sent to them thus result in losing part of the routes?
>> If this is the case, I don't think it's a serious problem. No matter what
>> new BGP capability one wants to introduce in this scenario, RRs are always
>> required to support it if we want to get it right.
>> If "RR peers" means other PEs, it is the expected result that PEs don't
>> suppo

Re: [bess] Please send me slot request for IETF 113 (BESS is only remote )

[Gyan Mishra]

Hi Mankamana

I would like to request a 10 minute time slot for both drafts below:

This draft we will be discussing name change to IPv6-Only PE design and
updates as well as changing from BCP to Standards Track as to the design
and paradigm shift for all PE-CE edge and inter-as PE-PE peering framework
which impacts IXP POPs worldwide related to IPv4 address depletion issues.

https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/

Also discuss how the draft below is an extension to the above draft and is
all inclusive of all AFI/SAFI single IPv6-Only PE design extensibility
framework and would be also Standards Track.

Also discuss the R&D testing and implementation being done by vendors
Cisco, Juniper, Nokia, Arista and Huawei and the additional testing being
incorporated given the “all safi” draft below.

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-all-safi-ipv6nh/



Kind Regards

Gyan

On Fri, Feb 18, 2022 at 10:22 AM Mankamana Mishra (mankamis)  wrote:

> All,
>
> Please send me slot request for IETF 113. Please note BESS session would
> be only remote since none of the chairs are able to travel in person this
> time.
>
>
>
>
>
> Mankamana
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

[Gyan Mishra]

Hi Jorge

I agree that having the classification of all IP tunnel that convey
Ethernet Payload not limited to RFC 8365 as NVO tunnels so all inclusive of
MPLSoGRE, MPLSoUDP, VXLAN, VXLAN-GPE, GENEVE, NVGRE

So now you would have 2 categories the NVO category above and the transport
category which would include SRv6, MPLS and SR-MPLS.

Kind Regards

Gyan

On Wed, Feb 16, 2022 at 11:12 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
jorge.raba...@nokia.com> wrote:

> Hi Gyan,
>
>
>
> Thank you for your feedback and support.
>
>
>
> The document attempts to address all tunnels that can be used in EVPN
> Multi-homing PEs. In that respect, we should probably do a better job
> defining what those tunnels are.
>
> The division at the moment is: non-IP MPLS, NVO tunnels, SRv6.
>
>- Where NVO tunnels are, in general, IP tunnels that can convey an
>Ethernet payload – that includes the ones in RFC8365, but not limited to
>the ones in RFC8365.
>
>
>
> In that sense, we can classify MPLSoGRE, MPLSoUDP, VXLAN, VXLAN-GPE, etc
> all as NVO tunnels.
>
>
>
> If you agree with the above, we can make the necessary edits to make the
> text consistent with that, as part of this WGLC.
>
>
>
> Thanks!
>
> Jorge
>
>
>
> *From: *Gyan Mishra 
> *Date: *Tuesday, February 15, 2022 at 8:37 PM
> *To: *Rabadan, Jorge (Nokia - US/Sunnyvale) 
> *Cc: *Anoop Ghanwani , BESS ,
> bess-cha...@ietf.org ,
> draft-ietf-bess-evpn-mh-split-hori...@ietf.org <
> draft-ietf-bess-evpn-mh-split-hori...@ietf.org>, slitkows.i...@gmail.com <
> slitkows.i...@gmail.com>
> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-mh-split-horizon
>
>
>
> Hi Jorge & Authors
>
>
>
> I support publication of this document and have a few comments  thatT I
> think will help clarify and improve the document.
>
>
>
> The specification is clear on the solution with two new flags to indicate
> SHT type ESI or Local Bias for NVO use cases.
>
>
>
> Table 1 lists different tunnel encapsulations.
>
>
>
> What I did notice is that VXLAN GPE is not included which should be.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe
>
>
>
> Also I noticed that RFC 7510 MPLSoUDP is included and that is an NVO
> tunnel and is not listed in RFC 8365 which does have VXLAN GPE.
>
>
>
> IANA codepoints table
>
>
>
> ValueName
>
>-
>
>8VXLAN Encapsulation
>
>9NVGRE Encapsulation
>
>10   MPLS Encapsulation
>
>11   MPLS in GRE Encapsulation
>
>12   VXLAN GPE Encapsulation
>
>
>
> RFC 7510 MPLSoUDP is a not an NVO tunnel and is used for special use cases
> for UDP based ECMP or LAG.
>
>
>
>
>
> As well MPLS  listed is  transport technology and not NVO tunnels which
> MPLS based EVPN for NG L2 VPN RFC 7432 utilizes ESI label natively by
> default for PE-CE AC MPLS based underlay and is not an an NVO overlay.
>
>
>
> As well SRv6  listed is a transport technology  and not NVO tunnels which
> uses MPLS based EVPN equivalent SRv6 L2 service SID TLV is encoded in BGP
> Prefix SID attribute per SRv6 BGP based services draft and utilizes ESI
> label natively by default for PE-CE AC MPLS based underlay and is not an an
> NVO overlay.
>
>
>
> MPLS and SRv6 should be in a separate table maybe as it’s not an an NVO
> tunnel or maybe mention that it’s a transport and can take advantage of SHT
> flag.
>
>
>
> I agree that SRv6 and MPLS transports should be included so they can take
> advantage of the SHT flag.
>
>
>
> The verbiage MPLS based NVO tunnel is clear and that would be in the NVO
> tunnel table be MPLSoGRE RFC 4023 and all other NVO tunnels are Non MPLS
> based.
>
>
>
> Many Thanks
>
>
>
> Gyan
>
>
>
> On Thu, Feb 10, 2022 at 4:10 PM Gyan Mishra  wrote:
>
>
>
> I support publication.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
> jorge.raba...@nokia.com> wrote:
>
> Thank you Anoop. We will fix those in the next version.
>
> Jorge
>
>
>
> *From: *Anoop Ghanwani 
> *Date: *Saturday, February 5, 2022 at 12:19 AM
> *To: *slitkows.i...@gmail.com 
> *Cc: *BESS , draft-ietf-bess-evpn-mh-split-hori...@ietf.org
> , bess-cha...@ietf.org <
> bess-cha...@ietf.org>
> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-mh-split-horizon
>
> I support the publication of the draft as an RFC.
>
>
>

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

[Gyan Mishra]

Hi Jorge & Authors

I support publication of this document and have a few comments  that I
think will help clarify and improve the document.

The specification is clear on the solution with two new flags to indicate
SHT type ESI or Local Bias for NVO use cases.

Table 1 lists different tunnel encapsulations.

What I did notice is that VXLAN GPE is not included which should be.

https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe

Also I noticed that RFC 7510 MPLSoUDP is included and that is an NVO tunnel
and is not listed in RFC 8365 which does have VXLAN GPE.

IANA codepoints table

ValueName
   -
   8VXLAN Encapsulation
   9NVGRE Encapsulation
   10   MPLS Encapsulation
   11   MPLS in GRE Encapsulation
   12   VXLAN GPE Encapsulation


RFC 7510 MPLSoUDP is a not an NVO tunnel and is used for special use cases
for UDP based ECMP or LAG.


As well MPLS  listed is  transport technology and not NVO tunnels which
MPLS based EVPN for NG L2 VPN RFC 7432 utilizes ESI label natively by
default for PE-CE AC MPLS based underlay and is not an an NVO overlay.

As well SRv6  listed is a transport technology  and not NVO tunnels which
uses MPLS based EVPN equivalent SRv6 L2 service SID TLV is encoded in BGP
Prefix SID attribute per SRv6 BGP based services draft and utilizes ESI
label natively by default for PE-CE AC MPLS based underlay and is not an an
NVO overlay.

MPLS and SRv6 should be in a separate table maybe as it’s not an an NVO
tunnel or maybe mention that it’s a transport and can take advantage of SHT
flag.

I agree that SRv6 and MPLS transports should be included so they can take
advantage of the SHT flag.

The verbiage MPLS based NVO tunnel is clear and that would be in the NVO
tunnel table be MPLSoGRE RFC 4023 and all other NVO tunnels are Non MPLS
based.

Many Thanks

Gyan

On Thu, Feb 10, 2022 at 4:10 PM Gyan Mishra  wrote:

>
> I support publication.
>
> Thanks
>
> Gyan
>
> On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
> jorge.raba...@nokia.com> wrote:
>
>> Thank you Anoop. We will fix those in the next version.
>>
>> Jorge
>>
>>
>>
>> *From: *Anoop Ghanwani 
>> *Date: *Saturday, February 5, 2022 at 12:19 AM
>> *To: *slitkows.i...@gmail.com 
>> *Cc: *BESS ,
>> draft-ietf-bess-evpn-mh-split-hori...@ietf.org <
>> draft-ietf-bess-evpn-mh-split-hori...@ietf.org>, bess-cha...@ietf.org <
>> bess-cha...@ietf.org>
>> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
>> draft-ietf-bess-evpn-mh-split-horizon
>>
>> I support the publication of the draft as an RFC.
>>
>>
>>
>> Below are some minor editorial comments.
>>
>>
>>
>> Anoop
>>
>>
>>
>> ==
>>
>>
>>
>> Multiple sections
>>
>>
>>
>> Probably better to replace all uses of Ethernet Segment with ES rather
>> than use them at random.
>>
>>
>>
>> Section 1
>>
>>
>>
>> Expand first use of "SID".
>>
>>
>> will keeo following
>> ->
>> will keep following
>>
>>
>>
>> Section 2.2
>>
>>
>> A value of 01
>>indicates the intend to use
>> ->
>> A value of 01
>>indicates the intent to use
>>
>>
>> A value of 10 indicates the intend to
>>use
>> ->
>> A value of 10 indicates the intent to
>>use
>>
>>
>>
>> On Wed, Jan 26, 2022 at 1:50 AM  wrote:
>>
>> Hello Working Group,
>>
>>
>>
>> This email starts a two weeks Working Group Last Call on
>> draft-ietf-bess-evpn-mh-split-horizon [1].
>>
>>
>>
>> This poll runs until *the 9th of Feb*.
>>
>>
>>
>> We are also polling for knowledge of any undisclosed IPR that applies to
>> this document, to ensure that IPR has been disclosed in compliance with
>> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>
>> If you are listed as an Author or a Contributor of this document please
>> respond to this email and indicate whether or not you are aware of any
>> relevant undisclosed IPR. The Document won't progress without answers from
>> all the Authors and Contributors.
>>
>>
>>
>> There is no IPR currently disclosed.
>>
>>
>>
>> If you are not listed as an Author or a Contributor, then please
>> explicitly respond only if you are aware of any IPR that has not yet been
>> disclosed in conformance with IETF rules.
>>
>>
>>
>> We are also polling for any existing implementation 

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

there could be
>> a situation where customer networks are exposed in any way externally -
>> leaving alone that to even get at the transport level to the customer
>> facing PE is also filtered and never allowed from outside. But this is out
>> of scope of this document as here the focus is not on underlay but overlay.
>>
>>
>>
>> Now when I re-read this I see why there is a little piece perhaps
>> misleading. The draft makes a claim that it is applicable to RFC8950 which
>> defines use of NHv6 with both unicast and VPN AFs. That needs to be made
>> clear that it is applicable to the latter only. If other co-authors believe
>> this is applicable to the former your DISCUSS section would indeed be
>> valid.
>>
>>
>>
>> Many thx,
>>
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Feb 12, 2022 at 12:05 AM Warren Kumari via Datatracker <
>> nore...@ietf.org> wrote:
>>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-bess-srv6-services-10: 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/blog/handling-iesg-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-srv6-services/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> The Security Considerations section says: "The service flows between PE
>> routers
>> using SRv6 SIDs advertised via BGP are expected to be limited within the
>> trusted SR domain (e.g., within a single AS or between multiple ASes
>> within a
>> single provider network).  Precaution should be taken to ensure that the
>> BGP
>> service information (including associated SRv6 SID) advertised via BGP
>> sessions
>> are limited to peers within this trusted SR domain." This is related to
>> (from
>> RFC8402): "Therefore, by default, the explicit routing information MUST
>> NOT be
>> leaked through the boundaries of the administered domain."
>>
>> However, we all know that BGP leaks happen -- and when they do, the SID’s
>> contained in the leak will be logged by various systems and hence
>> available to
>> the public into perpetuity.
>>
>> While the document states that border filtering should protect against
>> traffic
>> injection, this does not cover the case of internal compromise. Sure,
>> there is
>> the argument that once there is an internally compromised system, all
>> bets are
>> off -- but with this, an attacker that knows the SIDs in e.g inject
>> traffic
>> into a VPN. This seems to me to significantly expand the attack surface to
>> include the customer's networks too.
>>
>> Not only does an operator have to ensure that BGP leaks never occur, they
>> have
>> to then ensure that at no point can there be any filter lapses at any
>> border
>> node, and be able to guarantee the security of every device, server and
>> machine
>> within the domain in order for a secure posture to be maintained. Simply
>> saying
>> that precautions should be taken to make sure that route leak don't
>> occur, when
>> the consequences of doing so are a: severe and b: hard to recover from
>> seems to
>> not really cover it. In addition, it seems that the blast radius from a
>> missing
>> ACL seems much larger if it allows injections.
>>
>>
>> --
>> COMMENT:
>> --
>>
>> I'm still reviewing the document, but wanted to get an initial ballot in,
>> so
>> that we could start discussing it. Hopefully someone can help my
>> understand how
>> this doesn't expand the consequences of a BGP leak.
>>
>> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi Robert

I am not saying MPLS is sent in SAFI 1.

Let me try to explain.

In the use case we are discussing in section 5.3 and 5.4  is when there is
no VPN overlay as the PE-CE AC sits in the global routing table native BGP
unlabeled prefixes and the label stack is just a single label deep with the
topmost transport label.  In that scenario 5.4 is IPv6 unicast SAFI 1 NLRI
is carried over an IPv6 core transport label LSP.

In the MPLS analogy use case of global table routing  there is no bottom of
stack service label as is required for L3 VPN where we have a label as we
have an VPN overlay present. So the BGP routes are carried in the BGP RIB
natively in the global routing table unlabeled.  So that is what we are
talking about for the 5.4 use case now with SRv6 no VPN label and so NO
SRv6 L3 service TLV encoded in BGP prefix SID attribute.  The MPLS label
stack L3 VPN service label in SRv6 scenario in FUNCT field is now not
present with SAFI 1 IPV6 Unicast “Global IPv6 over IPv6 core”.

In section 5.1 and 5.2 BGP-LU SAFI 4 is required
because the SRv6 L3 Service TLV for L3 VPN overlay service route must
encoded in BGP prefix SID as it must be sent as labeled.

So in section 5.3 Global IPv4 over SRv6 core is similar to a 6PE RFC 4798
scenario analogy where the IPv6 prefixes are carried over an IPv4 core with
IPv4 signaled LSP with additional bottom of stack label as IPV6 prefixes
are labeled with BGP-LU SAFI 4  2/4 and must be sent labeled due to PHP
requirement as stated in RFC 4798.

So we have in section 5.3 the same scenario as 6PE but now over SRv6 using
RFC 8950 IPv6 next hop encoding to carry the BGP LU SAFI 4 labeled IPv4
prefixes.

So in 5.3 that section would need to be updated to state that BGP-LU
labeled IPv4 prefixes is necessary with encoded SRv6 L3 service TLV in BGP
prefix SID attribute so the IPv4 prefixes can be sent as labeled prefixes
over SRv6 core.

Upon exiting the SRv6 domain at the egress PE the outer IPv6 header is
removed that contains the SRv6 programming endpoint behavior semantics with
native payload forwarded by the PE to the CE similar to MPLS label
disposition at egress PE exiting the domain.

So here no issue with filtering as once you exit the domain the SRv6
forwarding plane semantics are stripped from the packet.

Hopefully this clarifies.

Many Thanks,

Gyan

On Sun, Feb 13, 2022 at 7:48 AM Robert Raszuk  wrote:

> Gyan,
>
> MPLS is never sent in SAFI 1.
>
> Thx,
> R.
>
> On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra  wrote:
>
>> Hi Robert
>>
>> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:
>>
>>> Gyan,
>>>
>>> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
>>>> encoding.  In this case using GRT transport underlay layer now carry’s the
>>>> customer routes and that is what Warren and Andrew concern is as far as BGP
>>>> leaks.
>>>>
>>>
>>> I would have the same concern so would VPN customers. No one is selling
>>> L2 or L3 VPN service to them distributing their reachability in the global
>>> routing table. They can do that all by themselves and there is lot's of
>>> really solid tools or products to do that already without being locked to a
>>> single telco.
>>>
>>
>> Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
>> as SAFI 128, so in my opinion both should be supported by SRV6 as operators
>> look to use SRv6 for a variety of use cases. That’s my point as there
>> should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
>> support.  Global Internet routing would not be the best use case for SAFI 1
>> GRT due to the attack vector - agreed, but enterprise networks with
>> internal customers where there is a trust level is a huge use case.
>>
>>>
>>> So when GRT is used the same edge filtering protection mechanisms used
>>>> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>>>>
>>>
>>> Not possible. It is not about filtering ... it is all about using
>>> globally routable SAFI vs private SAFIs to distribute customer's
>>> reachability, IMO that should still be OTT only.
>>>
>>
>> Gyan> As SRv6 source node is requirement to encapsulation with IPv6
>> outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path
>> steering the security issue brought up related to 5.3 and 5.4 is not an
>> issue requiring filtering per RFC 8402.  So routable and private SAFI
>> scenario would be the same now due to encapsulation overlay for both.  Do
>> you agree ?
>>
>>>
>>> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
>>>> tighten up verbia

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi Robert

On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:

> Gyan,
>
> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
>> encoding.  In this case using GRT transport underlay layer now carry’s the
>> customer routes and that is what Warren and Andrew concern is as far as BGP
>> leaks.
>>
>
> I would have the same concern so would VPN customers. No one is selling L2
> or L3 VPN service to them distributing their reachability in the global
> routing table. They can do that all by themselves and there is lot's of
> really solid tools or products to do that already without being locked to a
> single telco.
>

Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
as SAFI 128, so in my opinion both should be supported by SRV6 as operators
look to use SRv6 for a variety of use cases. That’s my point as there
should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
support.  Global Internet routing would not be the best use case for SAFI 1
GRT due to the attack vector - agreed, but enterprise networks with
internal customers where there is a trust level is a huge use case.

>
> So when GRT is used the same edge filtering protection mechanisms used
>> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>>
>
> Not possible. It is not about filtering ... it is all about using globally
> routable SAFI vs private SAFIs to distribute customer's reachability, IMO
> that should still be OTT only.
>

Gyan> As SRv6 source node is requirement to encapsulation with IPv6
outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path
steering the security issue brought up related to 5.3 and 5.4 is not an
issue requiring filtering per RFC 8402.  So routable and private SAFI
scenario would be the same now due to encapsulation overlay for both.  Do
you agree ?

>
> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
>> tighten up verbiage as far securing the domain.
>>
>
> BGP filtering or policy is in hands of many people. As has been proven you
> can not tighten them strong enough not to leak. The only natural way to
> tighten them is to use different plane to distribute private information
> what in this context means at least different BGP SAFI.
>
> So no - I do not agree with your observations.
>

   Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide
complete parity with MPLS to support both SAFI 1 and 128. There  are plenty
of use cases for SAFI 1 and it should be supported with SRv6.

>
> However I am for providing overlay reachability over global IPv6 Internet
> to interconnect customer sites. But routing within those sites should not
> be traversing Internet routers and using SAFI 1.
>
> Rgs,
> Robert.
>
> --

<http://www.verizon.com/>

*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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi Andrew

On Sat, Feb 12, 2022 at 9:41 PM Gyan Mishra  wrote:

> Hi Andrew,
>
> On Sat, Feb 12, 2022 at 5:13 PM Andrew - IETF 
> wrote:
>
>> Hi Gyan,
>>
>>
>>
>> A few clarifications on your clarifications – see responses inline:
>>
>> RFC8402 Section 8.2 explicitly prohibits sending SRv6 traffic beyond the
>> borders of a domain and over the general internet.  Making use of traffic
>> destined for an address within the SRGB of another network isn’t permitted
>> as per:
>>
>>  Gyan> The purpose of the domain boundary filters is to protect the SRv6
>> nodes within the “underlay” by filtering external traffic at the boundary
>> edges any traffic destined to any IPv6 destination address within the SRGB
>> or SRLB which would be underlay node connected interfaces IGP routable not
>> in BGP. This is done for any internet or intranet MPLS domain today to
>> secure the domain trust boundary.
>>
>> Andrew> Can I presume when referring to the SRGB/SRLB here you are
>> referring to the function part of the address or function+argument portion
>> of the SID’s?
>>
>> Gyan> Yes
>
>> I point out that the difference between SRv6 and MPLS/SR-MPLS is that you
>> cannot “Route” towards a label – you can route towards an IPv6 address.
>>
>>Gyan> Understood
>
>> If my assumptions are correct on the above – there seems to be an
>> assumption here that there is differentiation between the locator and the
>> function+argument parts of the SID – and these things are advertised
>> separately and then some how assembled.
>>
>>Gyan> That is all described in detail by this SRv6 BGP based
> service overlay draft.  See the introduction which states the egress PE
> signals the SRv6 service SID L3 service SID for BE service with BGP overlay
> service route or for SRV6-TR the egress PE colors the overlay service route
> with BGP tunnel encapsulation attribute color extended community SR-TE
> candidate path steering.  So nothing is advertised separately and the
> overlay egress PE signaling for SRv6-BE or SRv6-TE is how the SRv6 L3
> service SID is FUNCT field is encoded with L3 vpn route equivalence to MPLS
> label stack VPN label.
>
>> Except – I know of no draft text that says that, nor have I ever seen
>> that behavior in the wild.  If my assumptions are accurate and that is what
>> you are saying, can you point me to the text that defines this reassembly.
>>
>>
>
>> As regards the BGP – it goes further still:
>>
>> 
>>
>>
>>
>>  Gyan> This is not a BGP related just IGP underlay related.  BGP prefix
>> sid attribute is used to encode SRv6 L3 service TLVs within the SR domain
>> basically mapping the VPN and GRT BGP AFI/SAFI into the Function field of
>> SRv6 SID equivalent to MPLS VPN service label bottom of stack.  However
>> this is only within the SRv6 domain and once the packet leaves the SRv6
>> domain it’s native BGP AFI/SAFI encoding and not in SRv6 SID.  So even
>> though SRv6 SID contains the BGP service label encoding it is not BGP
>> overlay encoding that needs to be secured providing transitivity.
>>
>> Andrew> Again, I’m pretty unsure that I’m fully understanding what you
>> are saying here.  You seem to be saying that once a SID – including its
>> function/locator leave the domain – they cease to be SID’s and are just
>> normal addresses – and only become SID’s by dint of the fact that they are
>> inside the domain.  This would imply that a destination on the internet –
>> suddenly transmutes to something else when it crosses the domain boundary.
>> I would this is an unclear argument that seems to assume behavior not
>> stated in this document, or other SRv6 documents that I have read – and I’m
>> not sure that I agree with this assertion (if I am interpreting you
>> correctly).  I am drawing my interpretations here from the fact that you
>> are bringing up the IGP – and seem to be implying that a locator is
>> announced and some how combined with IGP information, and there is some
>> kinda split / reassembly of the destination.
>>
>>   Gyan> A good way to help describe what I am saying is that the BGP
> AFI/SAFI 1/128 is identical between MPLS/SR-MPLS and SRv6.  What is
> different is the data plane encoding where in MPLS the L3 VPN service label
> is encoded in the Bottom of Stack, where with SRv6  L3 VPN label equivalent
> is encoded in the SRv6 SID Function field.  When a packet egresses exits an
> MPLS domain the  PE performs label disposition POP of the label stack and
> similarly with SRv6

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

rt of the underlay.  The underlay is not routable reachable from outside
> the domain and even in MPLS TTL propagation is disabled to hide the
> visibility.  One big difference between MPLS and SRv6 is that the SR source
> node encapsulates the PE-CE AC payload in IPv6 outer header for both VPN
> overlay and GRT traffic so they are both treated the same where MPLS with
> GRT the customer traffic is natively routed and no overlay encapsulation.
> However in both cases of course we have a BGP overlay RIB which carry the
> internet or intranet table and that is transitory traffic and is not
> filtered at the trust boundary.
>
> So the trust boundary filtering is primary goal is to protect the underlay
> nodes and not interfere with the transitory BGP routing reachability.
>
>
>
> Andrew> However, if all assumptions I have made in the above are correct,
> and we are back to border filtering, that still leaves the question of the
> fact that the SID’s are exposed (albeit as addresses) – which still leads
> to the problem of the fact that this seems to rely on perfect bgp filtering
> in combination with perfect border filtering, and a failure in either that
> could have catastrophic consequences.
>
>
 Gyan> As explained above no SRv6 SIDs are exposed.

> Thanks
>
>
>
> Andrew
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Saturday, February 12, 2022 10:18 PM
> *To:* Robert Raszuk 
> *Cc:* Andrew - IETF ; BESS ;
> Bocci, Matthew (Nokia - GB) ; The IESG <
> i...@ietf.org>; Warren Kumari ; bess-cha...@ietf.org;
> draft-ietf-bess-srv6-servi...@ietf.org
> *Subject:* Re: [bess] Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
>
>
> Hi Robert / All
>
>
>
> For service providers and enterprises using GRT or VRF to carry the
> internet or intra internet  routing table using MPLS today or SR-MPLS that
> would like to use SRv6 to provide the same service.
>
>
>
> Section.  5.1 and 5.2 cover the VPN case in which the customer traffic is
> in VRF overlay and the SRv6 transport layer is a closed domain.
>
>
>
> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
> encoding.  In this case using GRT transport underlay layer now carry’s the
> customer routes and that is what Warren and Andrew concern is as far as BGP
> leaks.
>
>
>
> So when GRT is used the same edge filtering protection mechanisms used
> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>
>
>
> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
> tighten up verbiage as far securing the domain.
>
>
>
> As far as the SRv6 domain is concerned even with GRT the domain is still
> closed at the PE ingress and egress points which is where the concern is
> for BGP leaks.  The BGP Prefix SID encoding the SRv6 L3 service TLVs would,
> the encoding would only be present in the SRv6 SID Function field within
> the closed domain, and once you exit the SRv6 domain at the ingress or
> egress endpoints the SRv6 L3 service TLVs would now be carried natively in
> BGP and not in the SRv6 BGP prefix SID encoding.
>
>
>
>When an egress PE is enabled for BGP Services over SRv6 data-plane,
>
>it signals one or more SRv6 Service SIDs enclosed in SRv6 Service
>
>TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
>
>defined in [RFC4760 <https://datatracker.ietf.org/doc/html/rfc4760>] 
> [RFC4659 <https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950 
> <https://datatracker.ietf.org/doc/html/rfc8950>] [RFC7432 
> <https://datatracker.ietf.org/doc/html/rfc7432>] [RFC4364 
> <https://datatracker.ietf.org/doc/html/rfc4364>]
>
>[RFC9136 <https://datatracker.ietf.org/doc/html/rfc9136>] where applicable 
> as described in Section 5 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services#section-5>
>  and Section 6 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services#section-6>.
>
>
>
> So as far as SRv6 SID leaking there would not be any leaking outside the
> SRv6 domain.
>
>
>
> However as the GRT carry internet or intranet BGP RIB the SP AS is of
> course transitive so entire table is propagated.  That’s not a leak.
>
>
>
> I think we just need to maybe tighten up the verbiage on securing the PE
> edges of the SRv6 domain.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Sat, Feb 12, 2022 at 1:37 PM Robert Raszuk  wrote:
>
> Hi Andrew,
>
>
>
> When I read Warren's note Iooked at this text from section 2 which says:
>
>
>
> - 

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi Andrew

Responses in-line

On Sat, Feb 12, 2022 at 2:42 PM Andrew - IETF 
wrote:

> Gyan,
>
>
>
> However what you say then raises additional concerns.
>
>
>
> RFC8402 Section 8.2 explicitly prohibits sending SRv6 traffic beyond the
> borders of a domain and over the general internet.  Making use of traffic
> destined for an address within the SRGB of another network isn’t permitted
> as per:
>
>  Gyan> The purpose of the domain boundary filters is to protect the SRv6
> nodes within the “underlay” by filtering external traffic at the boundary
> edges any traffic destined to any IPv6 destination address within the SRGB
> or SRLB which would be underlay node connected interfaces IGP routable not
> in BGP. This is done for any internet or intranet MPLS domain today to
> secure the domain trust boundary.
>
>SR domain boundary routers MUST filter any external traffic destined
>
>to an address within the SRGB of the trusted domain or the SRLB of
>
>the specific boundary router.  External traffic is any traffic
>
>received from an interface connected to a node outside the domain of
>
>trust.
>
>
>
> As regards the BGP – it goes further still:
>
>  Gyan> This is not a BGP related just IGP underlay related.  BGP prefix
> sid attribute is used to encode SRv6 L3 service TLVs within the SR domain
> basically mapping the VPN and GRT BGP AFI/SAFI into the Function field of
> SRv6 SID equivalent to MPLS VPN service label bottom of stack.  However
> this is only within the SRv6 domain and once the packet leaves the SRv6
> domain it’s native BGP AFI/SAFI encoding and not in SRv6 SID.  So even
> though SRv6 SID contains the BGP service label encoding it is not BGP
> overlay encoding that needs to be secured providing transitivity.
>
>From a network-protection standpoint, there is an assumed trust model
>
>such that any node adding an SRH to the packet is assumed to be
>
>allowed to do so.  Therefore, by default, the explicit routing
>
>information MUST NOT be leaked through the boundaries of the
>
>administered domain.
>
> Gyan> SR provides a means of stateless traffic steering in the underlay
> framework using IGP extension to provide the SID distribution  for both
> SR-MPLS and SRv6.  The SID distribution is done via the IGP extensions as
> part of the underlay.  The underlay is not routable reachable from outside
> the domain and even in MPLS TTL propagation is disabled to hide the
> visibility.  One big difference between MPLS and SRv6 is that the SR source
> node encapsulates the PE-CE AC payload in IPv6 outer header for both VPN
> overlay and GRT traffic so they are both treated the same where MPLS with
> GRT the customer traffic is natively routed and no overlay encapsulation.
> However in both cases of course we have a BGP overlay RIB which carry the
> internet or intranet table and that is transitory traffic and is not
> filtered at the trust boundary.
>
So the trust boundary filtering is primary goal is to protect the underlay
> nodes and not interfere with the transitory BGP routing reachability.
>
> Now, I may be misunderstanding here – but – if at any point the
> announcements lead to traffic flowing towards a SID from outside the
> administered domain – that violates 8402.  If the SID’s are in BGP prefix’s
> that are transitive and find their way onto the general internet – that
> also violates 8402.
>
>  Gyan> As long as  the infrastructure  filters are applied at the trust
> boundary protection of the underlay SRv6 nodes there is no issue and that
> verbiage just needs to be clear in this draft following *RFC 8402.*
>
> Now, this could be a misunderstanding on my part – so I’d welcome
> clarification if I am incorrect in what I am seeing here – which may also
> lead to text which is clearer (as a note, I ran this past several operators
> who had very similar readings to what I had – so – if it’s a matter of
> misunderstanding, we really do need to find a way to clarify it, if its not
> a misunderstanding, then we need to find a way to rectify it for security
> purposes and to bring it in-line with RFC8402.
>
>  Gyan> Understood.  We can update the verbiage to make it crystal clear.
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Saturday, February 12, 2022 10:18 PM
> *To:* Robert Raszuk 
> *Cc:* Andrew - IETF ; BESS ;
> Bocci, Matthew (Nokia - GB) ; The IESG <
> i...@ietf.org>; Warren Kumari ; bess-cha...@ietf.org;
> draft-ietf-bess-srv6-servi...@ietf.org
> *Subject:* Re: [bess] Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
>
>
> Hi R

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

 information MUST
>> NOT be
>> leaked through the boundaries of the administered domain."
>>
>> However, we all know that BGP leaks happen -- and when they do, the SID’s
>> contained in the leak will be logged by various systems and hence
>> available to
>> the public into perpetuity.
>>
>> While the document states that border filtering should protect against
>> traffic
>> injection, this does not cover the case of internal compromise. Sure,
>> there is
>> the argument that once there is an internally compromised system, all
>> bets are
>> off -- but with this, an attacker that knows the SIDs in e.g inject
>> traffic
>> into a VPN. This seems to me to significantly expand the attack surface to
>> include the customer's networks too.
>>
>> Not only does an operator have to ensure that BGP leaks never occur, they
>> have
>> to then ensure that at no point can there be any filter lapses at any
>> border
>> node, and be able to guarantee the security of every device, server and
>> machine
>> within the domain in order for a secure posture to be maintained. Simply
>> saying
>> that precautions should be taken to make sure that route leak don't
>> occur, when
>> the consequences of doing so are a: severe and b: hard to recover from
>> seems to
>> not really cover it. In addition, it seems that the blast radius from a
>> missing
>> ACL seems much larger if it allows injections.
>>
>>
>> --
>> COMMENT:
>> --
>>
>> I'm still reviewing the document, but wanted to get an initial ballot in,
>> so
>> that we could start discussing it. Hopefully someone can help my
>> understand how
>> this doesn't expand the consequences of a BGP leak.
>>
>>
>> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

[Gyan Mishra]

I support publication.

Thanks

Gyan

On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
jorge.raba...@nokia.com> wrote:

> Thank you Anoop. We will fix those in the next version.
>
> Jorge
>
>
>
> *From: *Anoop Ghanwani 
> *Date: *Saturday, February 5, 2022 at 12:19 AM
> *To: *slitkows.i...@gmail.com 
> *Cc: *BESS , draft-ietf-bess-evpn-mh-split-hori...@ietf.org
> , bess-cha...@ietf.org <
> bess-cha...@ietf.org>
> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-mh-split-horizon
>
> I support the publication of the draft as an RFC.
>
>
>
> Below are some minor editorial comments.
>
>
>
> Anoop
>
>
>
> ==
>
>
>
> Multiple sections
>
>
>
> Probably better to replace all uses of Ethernet Segment with ES rather
> than use them at random.
>
>
>
> Section 1
>
>
>
> Expand first use of "SID".
>
>
> will keeo following
> ->
> will keep following
>
>
>
> Section 2.2
>
>
> A value of 01
>indicates the intend to use
> ->
> A value of 01
>indicates the intent to use
>
>
> A value of 10 indicates the intend to
>use
> ->
> A value of 10 indicates the intent to
>use
>
>
>
> On Wed, Jan 26, 2022 at 1:50 AM  wrote:
>
> Hello Working Group,
>
>
>
> This email starts a two weeks Working Group Last Call on
> draft-ietf-bess-evpn-mh-split-horizon [1].
>
>
>
> This poll runs until *the 9th of Feb*.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> There is no IPR currently disclosed.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> We are also polling for any existing implementation as per [2].
>
>
>
> Thank you,
>
> Stephane & Matthew
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/
>
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
> ___
> 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
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Gyan Mishra]

I support publication.

Thanks

Gyan
On Tue, Feb 1, 2022 at 2:14 PM Patrice Brissette (pbrisset)  wrote:

> I support publication and am not aware of undisclosed IPR.
>
>
>
> Implementation has been shipped on Cisco IOS-XR.
>
> Regards,
>
> Patrice Brissette, Principal Engineer
>
> Cisco Systems
>
>
>
> *http://e-vpn.io <http://e-vpn.io>*
>
> *http://go2.cisco.com/evpn <http://go2.cisco.com/evpn>*
>
>
>
>
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" 
>
>
> *Date: *Monday, January 31, 2022 at 08:58
> *To: *"draft-ietf-bess-evpn-fast-df-recov...@ietf.org" <
> draft-ietf-bess-evpn-fast-df-recov...@ietf.org>, "bess@ietf.org" <
> bess@ietf.org>
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *WGLC, IPR and Implementation Poll for
> draft-ietf-bess-evpn-fast-df-recovery-03
> *Resent-From: *
> *Resent-To: *Patrice Brissette , ,
> , , Ali Sajassi <
> saja...@cisco.com>
> *Resent-Date: *Monday, January 31, 2022 at 08:58
>
>
>
> Hi WG,
>
>
>
> This email starts a two-week Working Group Last Call on 
> draft-ietf-bess-evpn-fast-df-recovery-03
> [1].
>
>
>
> This poll runs until Monday 14th February 2022.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
> There is currently no IPR disclosed.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> We are also polling for any existing implementation as per [2]. Please
> indicate if you are aware of any implementations.
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
> [1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF
> Election
> <https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

[Gyan Mishra]

Hi Saumya

Once you have the Rev-0, send a summary of the context of the gap the draft
will solve and solicit feedback from the WG.

Kind Regards

Gyan

On Thu, Oct 14, 2021 at 6:31 AM Dikshit, Saumya 
wrote:

> Thanks Gyan,Parag.
>
> Please suggest, how do we trigger the discussion.
>
> I can a Spin-out a rev-0 for a new draft. Let me know your thoughts.
>
>
>
> Regards,
>
> Saumya.
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* Wednesday, October 13, 2021 8:41 PM
> *To:* Parag Jain (paragj) 
> *Cc:* BESS ; Dikshit, Saumya ;
> Greg Mirsky ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org
> *Subject:* Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
>
>
> Hi Saumya & Greg
>
>
>
> I would be happy to work on collaboration of this new draft as I can
> provide an operational POV on criticality on CP - DP consistency check
> validation for network operators in an NVO environment.
>
>
>
> There are  production scenarios with timing of state machine events with
> CP-DP that may have false positive or negative with LSP ping in NVO
> environment where an issue may still exists with consistency and out of
> sync situations due to the timing of events.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
> TA
>
> On Wed, Oct 13, 2021 at 8:20 AM Parag Jain (paragj)  40cisco@dmarc.ietf.org> wrote:
>
> Hi Saumya
>
>
>
> Thank you agreeing to progressing draft-ietf-bess-evpn-lsp-ping in the
> current state.
>
>
>
> Thank you Saumya and Greg for closing on this.
>
>
>
> I’ll be happy to participate in the new proposal discussions.
>
>
>
> regards
>
> Parag
>
>
>
> *From: *"Dikshit, Saumya" 
> *Date: *Wednesday, October 13, 2021 at 12:10 AM
> *To: *Greg Mirsky , BESS 
> *Cc: *"draft-ietf-bess-evpn-lsp-p...@ietf.org" <
> draft-ietf-bess-evpn-lsp-p...@ietf.org>, "Parag Jain (paragj)" <
> par...@cisco.com>
> *Subject: *RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Greg,
>
>
>
> Thank you for acknowledging.
>
> I agree that a new extension draft should be written to include below
> proposals.
>
>
>
> +1 on progressing with current state of this draft
> draft-ietf-bess-evpn-lsp-ping
>
>
>
> Thanks
>
> Saumya.
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Tuesday, October 12, 2021 9:39 PM
> *To:* Dikshit, Saumya ; BESS 
> *Cc:* draft-ietf-bess-evpn-lsp-p...@ietf.org; Parag Jain (paragj) <
> par...@cisco.com>
> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Saumya,
>
> thank you for sharing your ideas about extending EVNP LSP Ping
> functionality. These are interesting and useful proposals that, in my
> opinion, further extend the basic functionality of EVNP LSP Ping as defined
> in the draft. I'll be happy to discuss and work with you and others on a
> new document to introduce new extensions. In the meantime, progressing the
> current version of the EVPN LSP Ping document with the "classic" 8209-style
> scope is extremely important for network operators that need standard-based
> OAM tools in their toolboxes.
>
> What is your opinion?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Sep 14, 2021 at 7:24 AM Dikshit, Saumya 
> wrote:
>
> Multicasting it to authors of the draft, if the below use cases and
> (potential) solution can be made as part of this draft.
>
>
>
> Thanks
>
> Saumya.
>
>
>
>
>
>
>
> *From:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Dikshit, Saumya
> *Sent:* Monday, September 13, 2021 7:31 PM
> *To:* Greg Mirsky 
> *Cc:* draft-ietf-bess-evpn-lsp-p...@ietf.org; bess-cha...@ietf.org; Parag
> Jain (paragj) ; bess@ietf.org
> *Subject:* Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Thank you Greg.
>
>
>
> +1 on this drafts compliance to RFC8209.
>
>
>
> There are couple of requirements spelled out in the email below,
> summarizing it here as well:
>
> 1.   Allow wild-card/don’t-care values for attributes carried in the
> sub-TLVs as it will surely help when all details are not available. To draw
> parallels I see it equivalent to querying for an (potential) NLRI in a
> BGP-EVPN RIB via a management interface, where in all parameters hard to
> gather.
>
> 2. Test the reachability to tenant-VRF VRF_X (with EVPN mapped EVI)
> configured on the remote PE, PE1. VRF_X has *no active IP/IPv6 interface
> configured* and its sole usage is to *obtain the leaked (via IVRL) routes*
&g

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

[Gyan Mishra]

ion.
> Consistency-check will require lot of compute (might need a complete path
> calculation of BGP-EVPN), to indicate the consistency. Good to know if
> there are reference implementations optimizing this already.
>
> This is one more reason to use wild card.
>
>
>
>1. Parameters such as RD, shall not make it to the DP and their
>presence is restricted to the NLRI (entries/tables) in the protocol RIB.
>
>
>1. In case the RIB specific parameters need validation, then on
>   receive side processing of ping, should run it through the RIB and FIB 
> both
>   ?
>
> Paragj> yes.
>
>1. In case it’s just the dataplane validation (which I can gather from
>   this draft), then RIB validation is not required and RD’s  can carry 
> “don’t
>   care”.
>
>
>1. If a need be, to perform “reachability-check to a tenant vrf (EVI)
>on remote NVE”, for which no route has been published yet ?
>
> Paragj> only vrf-existence is not checked by lsp ping.
>
> [SD] That’s a good solution to have. I have mentioned the use-case in
> below email.
>
> I propose that we leverage the existing “EVPN IP Prefix Sub-TLV”, with
> appropriate values (may be wild-card/don’t care) to realize this.
>
>
>
> Paragj2> EVPN IP Prefix sub-tlv is for verifying ip prefix in a vrf. I am
> not sure it should/can be applied to the use case you  mention.
>
> [SD2] My take was to re-use tlvs/info carried in lsp-ping as already
> defined in this draft. If not agreeable to authors and group members, it
> will be good to define a new tlv (or otherwise) via an ancillary draft if
> needed. I can do that if, authors of this draft feel that it’s a misfit in
> this document. Since the label encoding can implicitly map to the VRF/EVI
> on the target, a sub-tlv indicating an EVI-check (either L2 or L3) can help
> the cause..
>
>
>
> Thanks
>
> Parag
>
>
>
>
>
> as I mentioned in #2 of below email
>
>1. Is it possible to achieve that with lsp-ping check with existing
>   sub-TLVs without “wild-card/don’t-care”
>
>
>
> Thanks
>
> Saumya.
>
>
>
> *From:* Parag Jain (paragj) [mailto:par...@cisco.com ]
> *Sent:* Tuesday, September 7, 2021 11:56 PM
> *To:* Dikshit, Saumya ;
> draft-ietf-bess-evpn-lsp-p...@ietf.org; bess@ietf.org
> *Cc:* bess-cha...@ietf.org
> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Saumya
>
>
>
> The remote PE router processing the lsp ping packet, does consistency
> checks between data plane and control plane. RD, ESI fields along with
> other fields defined in the sub-tlvs are used for that purpose.
> Wildcard/don’t care values for these fields will defeat the purpose of
> DP-CP consistency checks.
>
>
>
> Thanks
>
> Parag
>
>
>
> *From: *"Dikshit, Saumya" 
> *Date: *Thursday, September 2, 2021 at 1:42 PM
> *To: *"draft-ietf-bess-evpn-lsp-p...@ietf.org" <
> draft-ietf-bess-evpn-lsp-p...@ietf.org>, "bess@ietf.org" 
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *Query/comments on draft-ietf-bess-evpn-lsp-ping-05
> *Resent-From: *
> *Resent-To: *, , <
> gregimir...@gmail.com>, , 
> *Resent-Date: *Thursday, September 2, 2021 at 1:42 PM
>
>
>
> [sending the queries in a different email with changed subject line]
>
>
>
> Hello Authors of draft-ietf-bess-evpn-lsp-ping draft,
>
>
>
> I have following queries regarding this draft:
>
>
>
> >>>> Do we intend-to-use/call-out-usage-of “wild-card/don’t-care” values
> for attributes carried in the sub-TLVs ?
>
> For example, If the admin intends  to check the reachability to host
> (MAC_X/IP_X) published (in route-type-2)  by remote PE.
>
> The remote PE learnt it locally over ESI_X against Vlan X (mapped to
> BD_XYZ).
>
> Is it possible, that the “EVPN MAC sub-tlv”  can carry the “Route 
> Distinguisher” and “Ethernet Segment Identifier” as don’t care.
>
>
>
> >>>> Another caseto handle would be test the reachability to tenant-VRF
> VRF_X (with EVPN mapped EVI) configured on the remote PE, PE1.
>
> VRF_X has no active IP/IPv6 interface configured and its sole usage is to
> obtain the leaked (via IVRL) routes from other VRFs (non-EVPN) and PE1
> published this to other peers via EVPN control plane. Till the first prefix
> (learnt ) route is published (Route Type 5) by PE1 for the EVI (mapped to
> VRF_X), the tunnels will not be provisioned on other PEs.
>
> In order to test the reachability to VRF_X (on PE1) from another PEs,
> let’s say, PE2 or a centralized-controller (which can emulate/supports
> MPLS),
>
> It may need to carry all/subset-of attributes with “don’t-care/wild-card” in 
> “*EVPN IP Prefix Sub-TLV”.  *
>
>
>
>
>
> Please let know your thoughts on above.
>
>
>
> Thanks
>
> Saumya.
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09

[Gyan Mishra]

 follows.


   + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
  attribute with the Tunnel Type set to Ingress Replication, then
  the Leaf A-D route MUST carry the PMSI Tunnel attribute with the
  Tunnel Type set to Ingress Replication.  The Tunnel Identifier
  MUST carry a routable address of the PE/ASBR.  The PMSI Tunnel
  attribute MUST carry a downstream-assigned MPLS label that is used
  to demultiplex the MVPN traffic received over a unicast tunnel by
  the PE/ASBR.

+ The PE/ASBR constructs an IP-based Route Target Extended Community
  by placing the IP address carried in the Next Hop of the received
  Inter-AS I-PMSI A-D route in the Global Administrator field of the
  Community, with the Local Administrator field of this Community
  set to 0 and setting the Extended Communities attribute of the
  Leaf A-D route to that Community.



Do you plan to have a future draft that  adds this EVPN IR optimization to
MPLS underlay?

Responses in-line

Kind Regards

Gyan

On Wed, Oct 6, 2021 at 8:58 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi Gyan,
>
>
>
> Thank you very much for review the document!
>
> I’m adding comments along your comments with [jorge].
>
>
>
> Please check them out.
>
>
>
> Thanks again,
>
> Jorge
>
>
>
> *From: *Gyan Mishra via Datatracker 
> *Date: *Saturday, October 2, 2021 at 8:09 PM
> *To: *gen-...@ietf.org 
> *Cc: *bess@ietf.org ,
> draft-ietf-bess-evpn-optimized-ir@ietf.org <
> draft-ietf-bess-evpn-optimized-ir@ietf.org>, last-c...@ietf.org <
> last-c...@ietf.org>
> *Subject: *Genart last call review of draft-ietf-bess-evpn-optimized-ir-09
>
> Reviewer: Gyan Mishra
> Review result: Ready with Issues
>
> 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
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-bess-evpn-optimized-ir-??
> Reviewer: Gyan Mishra
> Review Date: 2021-10-02
> IETF LC End Date: 2021-09-07
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> I am the GEN-ART reviewer for this draft and am reviewing the draft as a
> BESS
> WG member familiar with the EVPN technology and issues that exist with IR
> and
> understand the need for the IR optimized solution for BUM replication.
> This
> draft clearly defines the problem to be solved with IR BUM replication &
> the
> proposed EVPN Optimized IR Solution which is technically sound.  My
> comments,
> considerations & recommendations are related re-writing of some of the
> technical verbiage to help improve the draft. The draft is well written &
> clearly describes the problem with EVPN IR PTA and how the Optimized IR
> solution with AR replication RT-11 can be used to provide an optimized
> Selective P-Tree so all PEs do not have to receive the BUM as exists today
> with
> RT-3 I-PMSI. This draft provides a EVPN procedure optimization for IR PTA
> R-3
> X-PMSI that utilizes a new RT-11 Leaf A-D  that was introduced in Jeffrey
> Zhang’s EVPN BUM Procedure update “draft
> draft-ietf-bess-evpn-bum-procedure-updates-10” that utilizes the RFC 6513
> Leaf-AD route to create a new Selective tree Leaf A-D Route for optimized
> EVPN
> BUM procedures for inter-as segmentation for any PTA P-Tree being
> instantiated
> including IR.
>   Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf
>   tracking purpose.
>
> Leaf A-D concept from RFC 6514 Leaf A-D route for Multicast in  VPLS RFC
> 7117
> Section 8.3 bottom of page 33 &  optimized selective & inclusive P-Tree
> X-PMSI
> tunnels with or without inter-as segmentation and “draft
> draft-ietf-bess-evpn-bum-procedure-updates-10” P-Tree Multicast both
> specifications uses RFC 7524 Section 4 Inter-Area P2MP Segmented Next hop
> extended community  (S-NH-EC) utilized for tunnel segmentation for seamless
> MPLS MVPN Multicast setting of “Leaf information required” L  flag in PTA
> now
> used in EVPN BUM procedures updates in draft “draft
> draft-ietf-bess-evpn-bum-procedure-updates-10” Section 6.3 and now also
> used in
> EVPN IR Optimizations draft for Assisted Replication function  in RT-11
> (S-NH-EC) with caveat that S-NH-EC is not used is changed from RFC 7524
> which
> should be reflected in the verbiage.
>
> RFC 7524 S-NH-EC Section 4
> 4.  Inter-Area P2MP Segmented Next-Hop Extended Community
>
>This document defines a new Transitive IPv4-Ad

[bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09

[Gyan Mishra via Datatracker]

Reviewer: Gyan Mishra
Review result: Ready with Issues

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-optimized-ir-??
Reviewer: Gyan Mishra
Review Date: 2021-10-02
IETF LC End Date: 2021-09-07
IESG Telechat date: Not scheduled for a telechat

Summary:
I am the GEN-ART reviewer for this draft and am reviewing the draft as a BESS
WG member familiar with the EVPN technology and issues that exist with IR and
understand the need for the IR optimized solution for BUM replication.   This
draft clearly defines the problem to be solved with IR BUM replication & the
proposed EVPN Optimized IR Solution which is technically sound.  My comments,
considerations & recommendations are related re-writing of some of the
technical verbiage to help improve the draft. The draft is well written &
clearly describes the problem with EVPN IR PTA and how the Optimized IR
solution with AR replication RT-11 can be used to provide an optimized
Selective P-Tree so all PEs do not have to receive the BUM as exists today with
RT-3 I-PMSI. This draft provides a EVPN procedure optimization for IR PTA R-3
X-PMSI that utilizes a new RT-11 Leaf A-D  that was introduced in Jeffrey
Zhang’s EVPN BUM Procedure update “draft
draft-ietf-bess-evpn-bum-procedure-updates-10” that utilizes the RFC 6513
Leaf-AD route to create a new Selective tree Leaf A-D Route for optimized EVPN
BUM procedures for inter-as segmentation for any PTA P-Tree being instantiated
including IR.
  Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf
  tracking purpose.

Leaf A-D concept from RFC 6514 Leaf A-D route for Multicast in  VPLS RFC 7117
Section 8.3 bottom of page 33 &  optimized selective & inclusive P-Tree X-PMSI
tunnels with or without inter-as segmentation and “draft
draft-ietf-bess-evpn-bum-procedure-updates-10” P-Tree Multicast both
specifications uses RFC 7524 Section 4 Inter-Area P2MP Segmented Next hop
extended community  (S-NH-EC) utilized for tunnel segmentation for seamless
MPLS MVPN Multicast setting of “Leaf information required” L  flag in PTA now
used in EVPN BUM procedures updates in draft “draft
draft-ietf-bess-evpn-bum-procedure-updates-10” Section 6.3 and now also used in
EVPN IR Optimizations draft for Assisted Replication function  in RT-11 
(S-NH-EC) with caveat that S-NH-EC is not used is changed from RFC 7524 which
should be reflected in the verbiage.

RFC 7524 S-NH-EC Section 4
4.  Inter-Area P2MP Segmented Next-Hop Extended Community

   This document defines a new Transitive IPv4-Address-Specific Extended
   Community Sub-Type: "Inter-Area P2MP Next-Hop".  This document also
   defines a new BGP Transitive IPv6-Address-Specific Extended Community
   Sub-Type: "Inter-Area P2MP Next-Hop".

   A PE, an ABR, or an ASBR constructs the Inter-Area P2MP Segmented
   Next-Hop Extended Community as follows:

   -  The Global Administrator field MUST be set to an IP address of the
  PE, ABR, or ASBR that originates or advertises the route carrying
  the P2MP Next-Hop Extended Community.  For example this address
  may be the loopback address or the PE, ABR, or ASBR that
  advertises the route.

   -  The Local Administrator field MUST be set to 0.

  If the Global Administrator field is an IPv4 address, the
  IPv4-Address-Specific Extended Community is used; if the Global
  Administrator field is an IPv6 address, the IPv6-Address-Specific
  Extended Community is used.

  The detailed usage of these Extended Communities is described in
  the following sections.

Excerpt from RFC 7524 Section 6.3 also verbiage used in the BUM procedure
update Section 6.3 as well as this EVPN IR optimization draft Section 4 page 9:
6.3.  Use of S-NH-EC

   [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
   to change the BGP next hop when they re-advertise I/S-PMSI A-D routes
   to downstream areas.  That is only to be consistent with the MVPN
   Inter-AS I-PMSI A-D routes, whose next hop must not be changed when
   they're re-advertised by the segmenting ABRs for reasons specific to
   MVPN.  For EVPN, it is perfectly fine to change the next hop when
   RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S-
   NH-EC.  As a result, this document specifies that RBRs change the BGP
   next hop when they re-advertise I/S-PMSI A-D routes and do not use S-
   NH-EC.  If a downstream PE/RBR needs to originate Leaf A-D routes, it
   constructs an IP-based Route Target Extended Community by placing the
   IP address carried in the Next Hop of the received I/S-PMSI A-D route
   in the Global Administrator field of the Community, with the

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Gyan Mishra]

I support WG adoption of this draft.

This draft provides a valuable solution to ECMP 50/50 load balancing issues
in a eBGP only Data Center RFC 7938 NVO3 CLOS architecture, to avoid link
saturation towards leaf nodes as well as possible use case for end to end
seamless MPLS and UCMP weighted load balancing.

It looks like the draft is missing IANA section.

Can we add a section on implementations as we discussed on ML a few months
ago?

Kind Regards

Gyan


On Thu, Sep 9, 2021 at 2:23 PM Mankamana Mishra (mankamis)  wrote:

> Support adoption.
>
>
>
> *From: *BESS  on behalf of Bocci, Matthew (Nokia -
> GB) 
>
>
> *Date: *Tuesday, September 7, 2021 at 5:42 AM
> *To: *bess@ietf.org 
> *Cc: *draft-mohanty-bess-ebgp-...@ietf.org <
> draft-mohanty-bess-ebgp-...@ietf.org>
> *Subject: *[bess] WG adoption poll and IPR poll for
> draft-mohanty-bess-ebgp-dmz-03 [1].
>
> Hello,
>
>
>
> This email begins a two-week WG adoption poll for
> draft-mohanty-bess-ebgp-dmz-03 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on September 21st 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Implementation poll for draft-ietf-bess-evpn-lsp-ping-05

[Gyan Mishra]

 the on-line Internet-Drafts
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : LSP-Ping Mechanisms for EVPN and PBB-EVPN
> Authors : Parag Jain
>   Samer Salam
>   Ali Sajassi
>   Sami Boutros
>   Greg Mirsky
>  Filename: draft-ietf-bess-evpn-lsp-ping-05.txt
>  Pages   : 15
>  Date: 2021-06-14
>
> Abstract:
>LSP-Ping is a widely deployed Operation, Administration, and
>Maintenance (OAM) mechanism in MPLS networks.  This document
>describes mechanisms for detecting data-plane failures using LSP
> Ping
>in MPLS based EVPN and PBB-EVPN networks.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/__;!!NEt6yMaO-gk!RoQdN1xrngG7wEPSC6AqHesQtzGvBMP82cosyeO0PYZjTGA5JLyFmli4CFZvJAM$>
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-05
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-05__;!!NEt6yMaO-gk!RoQdN1xrngG7wEPSC6AqHesQtzGvBMP82cosyeO0PYZjTGA5JLyFmli4RLT2-5Q$>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-lsp-ping-05
> <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-lsp-ping-05__;!!NEt6yMaO-gk!RoQdN1xrngG7wEPSC6AqHesQtzGvBMP82cosyeO0PYZjTGA5JLyFmli44UwE5yg$>
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> <https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!RoQdN1xrngG7wEPSC6AqHesQtzGvBMP82cosyeO0PYZjTGA5JLyFmli4trDqUTY$>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!RoQdN1xrngG7wEPSC6AqHesQtzGvBMP82cosyeO0PYZjTGA5JLyFmli4YoTqkAc$>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Gyan Mishra]

...@ans.net; Shraddha Hegde ;
> bess@ietf.org; Srihari Sangli 
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Could Authors respond to this ?
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Rajesh M 
> *Sent:* Monday, July 19, 2021 7:28 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Ketan Talaulikar (ketant) <
> ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) <
> cfils...@cisco.com>; rob...@raszuk.net; bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org; Srihari Sangli 
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All,
>
>
>
> For best effort service, flex algo – Resolve SRv6 Service SID for
> forwarding.
>
> For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.
>
>
>
> There is no unification here, it’s better to unify.
>
> Any other solution is OK.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) 
>
> *Sent:* Monday, July 19, 2021 7:17 PM
> *To:* Rajesh M ; Rajesh M <
> mrajesh=40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) <
> ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) <
> cfils...@cisco.com>; rob...@raszuk.net; bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org; Srihari Sangli 
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Rajesh,
>
>
>
> The draft is written so that the next-hop address MAY be covered by the
> locator, but there are cases in which the next-hop address is not part of
> the locator prefix, and there are implementations already allowing that, so
> I don’t agree the document should mandate what you are suggesting.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Rajesh M 
> *Date: *Monday, July 19, 2021 at 3:24 PM
> *To: *Rajesh M , Ketan Talaulikar
> (ketant) , gdawra.i...@gmail.com ,
> Clarence Filsfils (cfilsfil) , rob...@raszuk.net <
> rob...@raszuk.net>, bruno.decra...@orange.com ,
> Rabadan, Jorge (Nokia - US/Mountain View) 
> *Cc: *spr...@ietf.org , b...@ans.net ,
> Shraddha Hegde , bess@ietf.org ,
> Srihari Sangli 
> *Subject: *RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
> Hi Authors,
>
>
>
> Please respond.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring  *On Behalf Of *Rajesh M
> *Sent:* Thursday, July 15, 2021 4:36 PM
> *To:* Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com;
> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net;
> bruno.decra...@orange.com; jorge.raba...@nokia.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org
> *Subject:* [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All,
>
>
>
> As per this draft, this is how resolution must work.
>
>
>
> 1)For Non Intent service Route:
>
> if BGP next hop is not reachable return.
>
> Resolve SRv6 Service SID for forwarding.
>
>
>
> 2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR
> Policy):
>
> BGP next hop is not reachable return.
>
> Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if
> successfully resolves then return.
>
> Resolve BGP next hop for forwarding (in case above is not success).
>
>
>
>
>
> *Using Service SID (overlay),for resolution is definitely not recommended.*
>
>
>
> *Instead in case of srv6, we always resolve on BGP nexthop. This will be
> in line with BGP legacy.*
>
> *In case of best effort/flex algo we must mandate user to set
> corresponding locator as BGP nexthop for srv6 routes.*
>
> *I think this is a reasonable mandate.*
>
>
>
> Thanks
>
> Rajesh
>
>
>
> Juniper Business Use Only
> ___
> spring mailing list
> spr...@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] NVO3 VXLAN Source port entropy

[Gyan Mishra]

Perfect!  Looking forward to it!

Kind Regards

Gyan

On Wed, Jul 14, 2021 at 11:01 PM Jeff Tantsura 
wrote:

> I’m planning to have a presentation in RTGWG that would explain RTO based
> header changes/ aka self healing fabie   (flow label in v6/ overlay
> transport layer source port in v4, in linux kernel since 2016), stay tuned.
> This is mostly relevant to DC domain and while host based still a very
> important improvement.
>
> Cheers,
> Jeff
>
> On Jul 14, 2021, at 18:21, Gyan Mishra  wrote:
>
> 
>
> All
>
> I think I figured out how “source port entropy” works and provides
> “better” load balancing then traditional IGP & EGP based ECMP underlay
> algorithms that
> are subject to polarization.
>
> So normally w/o source port entropy vxlan feature the overlay NVE Anycast
> vtep tunnel as a tunnel source and destination so as it’s a single source /
> destination IP for the vtep tunnel termination, so that would get pinned to
> a single path similar to L2 VPN service label, single source / destination
> PE to PE single path.  So just as with L2 VPN you have the FAT PW which now
> you read into the payload and extract the src/dest flows and can now load
> balance the flows over Ethernet bundles.
>
> Similarly with VXLAN “source port entropy” per RFC 7348  the L2/L3/L4
> headers 5-tuple hash is used to generate the outer header udp source port
> which is used as the input key to the hashing function.  So one of the
> major advantages of VXLAN is now traffic can be much more uniformly evenly
> load balanced now with 5-tuple info over L3 ECMP path as compare to
> traditional IPv4 flow based per session source / destination hash load
> balancing.
>
> The vxlan 5-tuple hash input key to hash function is also very similar
> analogous to IPv6 flow label RFC 6437 5-tuple header hash input key to hash
> function stateless mode flow label uniform load balancing.
>
>
> Kind Regards
>
> Gyan
> On Wed, Jul 14, 2021 at 6:11 PM Gyan Mishra  wrote:
>
>>
>> Dear BESS Experts
>>
>> ?? On NVO3 VXLAN overlay encapsulation
>>
>> My understanding of VXLAN source port entropy is to provide uniform load
>> balancing similar to RFC 6437 IPv6 flow label uniform stateful load
>> balancing, in NVO3 VXLAN context, using header 5-tuple L2/L3/L4 hash and
>> generating source port input key to hash function for per packet per flow
>>  uniform load balancing as achieved with EVPN ECMP pr weighted UCMP MHD
>> MLAG PE-CE AC.
>>
>> The problem with L3 ECMP and weighed UCMP is the Day 1 well known TCP
>> polarization of flows where high bandwidth flows are not evenly distributed
>> between L3 paths.
>>
>> So the question is does source port entropy provide per RFC 7348 excerpt
>> below provide per packet per flow load balancing or flow based where all
>> packets that are part of the same flow get hashed to the same path.
>>
>> Outer UDP Header:  This is the outer UDP header with a source port
>>   provided by the VTEP and the destination port being a well-known
>>   UDP port.
>>
>>   -  Destination Port: IANA has assigned the value 4789 for the
>>  VXLAN UDP port, and this value SHOULD be used by default as the
>>  destination UDP port.  Some early implementations of VXLAN have
>>  used other values for the destination port.  To enable
>>  interoperability with these implementations, the destination
>>  port SHOULD be configurable.
>>
>>   -  Source Port:  It is recommended that the UDP source port number
>>  be calculated using a hash of fields from the inner packet --
>>  one example being a hash of the inner Ethernet frame's headers.
>>  This is to enable a level of entropy for the ECMP/load-
>>  balancing of the VM-to-VM traffic across the VXLAN overlay.
>>  When calculating the UDP source port number in this manner, it
>>  is RECOMMENDED that the value be in the dynamic/private port
>>  range 49152-65535 [RFC6335 
>> <https://datatracker.ietf.org/doc/html/rfc6335>].
>>
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>>
>>
>> *M 301 502-1347*
>>
>> --
>
> <http://www.verizon.com/>
>
> *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
>
> --

<http://www.verizon.com/>

*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

Re: [bess] NVO3 VXLAN Source port entropy

[Gyan Mishra]

All

I think I figured out how “source port entropy” works and provides “better”
load balancing then traditional IGP & EGP based ECMP underlay algorithms
that
are subject to polarization.

So normally w/o source port entropy vxlan feature the overlay NVE Anycast
vtep tunnel as a tunnel source and destination so as it’s a single source /
destination IP for the vtep tunnel termination, so that would get pinned to
a single path similar to L2 VPN service label, single source / destination
PE to PE single path.  So just as with L2 VPN you have the FAT PW which now
you read into the payload and extract the src/dest flows and can now load
balance the flows over Ethernet bundles.

Similarly with VXLAN “source port entropy” per RFC 7348  the L2/L3/L4
headers 5-tuple hash is used to generate the outer header udp source port
which is used as the input key to the hashing function.  So one of the
major advantages of VXLAN is now traffic can be much more uniformly evenly
load balanced now with 5-tuple info over L3 ECMP path as compare to
traditional IPv4 flow based per session source / destination hash load
balancing.

The vxlan 5-tuple hash input key to hash function is also very similar
analogous to IPv6 flow label RFC 6437 5-tuple header hash input key to hash
function stateless mode flow label uniform load balancing.


Kind Regards

Gyan
On Wed, Jul 14, 2021 at 6:11 PM Gyan Mishra  wrote:

>
> Dear BESS Experts
>
> ?? On NVO3 VXLAN overlay encapsulation
>
> My understanding of VXLAN source port entropy is to provide uniform load
> balancing similar to RFC 6437 IPv6 flow label uniform stateful load
> balancing, in NVO3 VXLAN context, using header 5-tuple L2/L3/L4 hash and
> generating source port input key to hash function for per packet per flow
>  uniform load balancing as achieved with EVPN ECMP pr weighted UCMP MHD
> MLAG PE-CE AC.
>
> The problem with L3 ECMP and weighed UCMP is the Day 1 well known TCP
> polarization of flows where high bandwidth flows are not evenly distributed
> between L3 paths.
>
> So the question is does source port entropy provide per RFC 7348 excerpt
> below provide per packet per flow load balancing or flow based where all
> packets that are part of the same flow get hashed to the same path.
>
> Outer UDP Header:  This is the outer UDP header with a source port
>   provided by the VTEP and the destination port being a well-known
>   UDP port.
>
>   -  Destination Port: IANA has assigned the value 4789 for the
>  VXLAN UDP port, and this value SHOULD be used by default as the
>  destination UDP port.  Some early implementations of VXLAN have
>  used other values for the destination port.  To enable
>  interoperability with these implementations, the destination
>  port SHOULD be configurable.
>
>   -  Source Port:  It is recommended that the UDP source port number
>  be calculated using a hash of fields from the inner packet --
>  one example being a hash of the inner Ethernet frame's headers.
>  This is to enable a level of entropy for the ECMP/load-
>  balancing of the VM-to-VM traffic across the VXLAN overlay.
>  When calculating the UDP source port number in this manner, it
>  is RECOMMENDED that the value be in the dynamic/private port
>  range 49152-65535 [RFC6335 
> <https://datatracker.ietf.org/doc/html/rfc6335>].
>
>
>
> Kind Regards
>
> Gyan
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*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] NVO3 VXLAN Source port entropy

[Gyan Mishra]

Dear BESS Experts

?? On NVO3 VXLAN overlay encapsulation

My understanding of VXLAN source port entropy is to provide uniform load
balancing similar to RFC 6437 IPv6 flow label uniform stateful load
balancing, in NVO3 VXLAN context, using header 5-tuple L2/L3/L4 hash and
generating source port input key to hash function for per packet per flow
 uniform load balancing as achieved with EVPN ECMP pr weighted UCMP MHD
MLAG PE-CE AC.

The problem with L3 ECMP and weighed UCMP is the Day 1 well known TCP
polarization of flows where high bandwidth flows are not evenly distributed
between L3 paths.

So the question is does source port entropy provide per RFC 7348 excerpt
below provide per packet per flow load balancing or flow based where all
packets that are part of the same flow get hashed to the same path.

Outer UDP Header:  This is the outer UDP header with a source port
  provided by the VTEP and the destination port being a well-known
  UDP port.

  -  Destination Port: IANA has assigned the value 4789 for the
 VXLAN UDP port, and this value SHOULD be used by default as the
 destination UDP port.  Some early implementations of VXLAN have
 used other values for the destination port.  To enable
 interoperability with these implementations, the destination
 port SHOULD be configurable.

  -  Source Port:  It is recommended that the UDP source port number
 be calculated using a hash of fields from the inner packet --
 one example being a hash of the inner Ethernet frame's headers.
 This is to enable a level of entropy for the ECMP/load-
 balancing of the VM-to-VM traffic across the VXLAN overlay.
 When calculating the UDP source port number in this manner, it
 is RECOMMENDED that the value be in the dynamic/private port
 range 49152-65535 [RFC6335
<https://datatracker.ietf.org/doc/html/rfc6335>].



Kind Regards

Gyan


-- 

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Satya

Welcome.

As Jeff and Arie pointed out the distinct difference between the dmz link
bandwidth extended community and cumulative link bandwidth is that the
original link bandwidth extended community is non transitive and only
supports 2 octet AS, where the cumulative link bandwidth is an aggregation
of link bandwidths updated at every hop in the fabric and regenerated at
the AS boundary border node.

That would be great to add an addendum with each of the vendor
implementations.

Kind Regards

Gyan

On Wed, Jul 7, 2021 at 6:52 PM Satya Mohanty (satyamoh) 
wrote:

> Gyan,
>
>
>
> Thanks for your interest. Sorry for replying late on this.
>
> Thanks Arie and Jeff for your clarifications.
>
>
>
> We have not changed the definition of the Link Bandwidth Ext. Community
> (0x4004) or it definition as non-transitive.
>
> As Arie mentioned previously, we are actually originating it at the AS
> boundary.
>
>
>
> BTW, the cumulative link-bandwidth feature first went in XR in 6.1.1. We
> can incorporate that in the addendum as well get the similar information
> from other vendors.
>
>
>
> Thanks,
>
> --Satya
>
>
>
> *From: *Gyan Mishra 
> *Date: *Saturday, July 3, 2021 at 8:34 AM
> *To: *Jeff Tantsura 
>
> *Cc: *Arie Vayner , Robert Raszuk ,
> "Satya Mohanty (satyamoh)" , "UTTARO, JAMES" <
> ju1...@att.com>, "bess@ietf.org" 
> *Subject: *Re: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
>
>
> Thanks Jeff for the clarification.
>
>
>
> Thanks
>
>
>
> Gyan
>
> On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura 
> wrote:
>
> Gyan,
>
>
>
> you are mixing use of BW community as such with cumulative propagation
> (the theme of the draft).
>
> The original community is defined in "Non-Transitive Two-Octet AS-Specific
> Extended Community Sub-Types" IANA section and that has to be changed to
> allow eBGP use cases.
>
> Aggregation is a very useful feature when the prefix with the
> community attached is traversing the fabric and is being regenerated and
> potentially transformed at every hop traversed.
>
>
>
> The alternative with add-path and potentially path explosion (not to talk
> about operational complexity of add-path and bugs in the implementations)
> is a rather unattractive solution for DC fabrics.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra  wrote:
>
> Hi Satya
>
>
>
> For EBGP DCs with multi-stage clos I understand this can be used, however
> with Cisco & Juniper & Nokia & Arista  and maybe other vendor
> implementations seem to combine the non transitive link bw extended
> community and transitive cumulative link bw extended community into a
> single feature that works for UCMP intra AS and inter AS.  Please confirm.
>
>
>
> These two drafts seem to be combined by implementations into a single UCMP
> feature for both eBGP and iBGP.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
>
>
>
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>
>
>
> Cisco:
>
>
>
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html
>
>
>
>
> https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853
>
>
>
> Juniper:
>
>
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html
>
>
>
> Nokia:
>
>
>
>
> https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html
>
>
>
>
>
> Arista:
>
>
>
> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) <
> satya...@cisco.com> wrote:
>
> Hi Jim,
>
>
>
> No, they do not.
>
>
>
> This draft under discussion is a way to aggregate the link bandwidth in
> EBGP DCs and advertise it upstream.
>
> It works well in multi-stage clos topology fabrics.
>
> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
> node of each stage (unless the sink).
>
>
>
> The draft you are mentioning,
> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
> really a way to communicate the link-bandwidth across EBGP boundaries.
>
> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
> unc

Re: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02

[Gyan Mishra]

;>
>>
>>
>> - Layer2 attributes -> Layer-2 attributes.
>>
>>
>>
>> Section 4.2/4.3
>>
>>
>>
>> I got a bit confused here.  The draft discusses Modulo, HRW.  Do we
>> essentially end up with a single active link, but just that which link is
>> chosen is dependent on the algorithm?  If so, what is the benefit of doing
>> so?  I can see why multiple algorithms are of value when we are doing
>> VLAN-based load balancing to multiple active links.
>>
>>
>>
>> Section 5
>>
>>
>>
>> - "Bundle-Ethernet" -> "LAG"
>>
>>
>>
>> Section 5.1
>>
>>
>>
>> - "per ES routes for fast convergence" -> "per ES route for fast
>> convergence"
>>
>>
>>
>> Section 5.2
>>
>>
>>
>> - "per EVI routes" -> "per EVI route"
>>
>>
>>
>> Section 7
>>
>>
>>
>> - spurious 'g'.
>>
>>
>>
>> - missing period under the second sub-bullet of point 'f'.
>>
>>
>>
>>
>>
>> On Mon, May 31, 2021 at 12:31 AM  wrote:
>>
>> Hello WG,
>>
>>
>>
>>
>>
>> This email starts a two weeks Working Group Last Call on
>>
>> draft-ietf-bess-evpn-mh-pa-02 [1].
>>
>>
>>
>>
>>
>> This poll runs until * the 7th of June *.
>>
>>
>>
>>
>>
>> We are also polling for knowledge of any undisclosed IPR that applies to
>>
>> this Document, to ensure that IPR has been disclosed in compliance with IETF
>>
>> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>
>>
>>
>> If you are listed as an Author or a Contributor of this Document please
>>
>> respond to this email and indicate whether or not you are aware of any
>>
>> relevant undisclosed IPR. The Document won't progress without answers from
>>
>> all the Authors and Contributors.
>>
>>
>>
>> There is currently no IPR disclosed.
>>
>>
>>
>>
>>
>> If you are not listed as an Author or a Contributor, then please explicitly
>>
>> respond only if you are aware of any IPR that has not yet been disclosed in
>>
>> conformance with IETF rules.
>>
>>
>>
>>
>>
>> We are also polling for any existing implementation as per [2].
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Stephane & Matthew
>>
>>
>>
>>
>>
>> [1]
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-pa/
>>
>>
>>
>> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>>
>>
>>
>> ___
>> 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
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Thanks Jeff for the clarification.

Thanks

Gyan
On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura 
wrote:

> Gyan,
>
> you are mixing use of BW community as such with cumulative propagation
> (the theme of the draft).
> The original community is defined in "Non-Transitive Two-Octet AS-Specific
> Extended Community Sub-Types" IANA section and that has to be changed to
> allow eBGP use cases.
> Aggregation is a very useful feature when the prefix with the
> community attached is traversing the fabric and is being regenerated and
> potentially transformed at every hop traversed.
>
> The alternative with add-path and potentially path explosion (not to talk
> about operational complexity of add-path and bugs in the implementations)
> is a rather unattractive solution for DC fabrics.
>
> Cheers,
> Jeff
>
> On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra  wrote:
>
>> Hi Satya
>>
>> For EBGP DCs with multi-stage clos I understand this can be used, however
>> with Cisco & Juniper & Nokia & Arista  and maybe other vendor
>> implementations seem to combine the non transitive link bw extended
>> community and transitive cumulative link bw extended community into a
>> single feature that works for UCMP intra AS and inter AS.  Please confirm.
>>
>> These two drafts seem to be combined by implementations into a single
>> UCMP feature for both eBGP and iBGP.
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
>>
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>
>> Cisco:
>>
>>
>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html
>>
>>
>> https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853
>>
>> Juniper:
>>
>>
>> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html
>>
>> Nokia:
>>
>>
>> https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html
>>
>>
>> Arista:
>>
>> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) <
>> satya...@cisco.com> wrote:
>>
>>> Hi Jim,
>>>
>>>
>>>
>>> No, they do not.
>>>
>>>
>>>
>>> This draft under discussion is a way to aggregate the link bandwidth in
>>> EBGP DCs and advertise it upstream.
>>>
>>> It works well in multi-stage clos topology fabrics.
>>>
>>> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
>>> node of each stage (unless the sink).
>>>
>>>
>>>
>>> The draft you are mentioning,
>>> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
>>> really a way to communicate the link-bandwidth across EBGP boundaries.
>>>
>>> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
>>> unchanged) although it also applies to Option B deployments (next-hop-self).
>>>
>>> There is no notion of aggregating bandwidth here.
>>>
>>>
>>>
>>> HTH.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>>
>>>
>>>
>>>
>>>
>>> *From: *"UTTARO, JAMES" 
>>> *Date: *Wednesday, May 26, 2021 at 5:38 AM
>>> *To: *Gyan Mishra , Robert Raszuk <
>>> rob...@raszuk.net>
>>> *Cc: *Jeff Tantsura , Arie Vayner <
>>> ar...@vayner.net>, "bess@ietf.org" , "Satya Mohanty
>>> (satyamoh)" 
>>> *Subject: *RE: [bess] Request discussion on Cumulative Link Bandwidth
>>> Draft
>>>
>>>
>>>
>>> *Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing
>>> address the same field of use? *
>>>
>>>
>>>
>>> *Thanks,*
>>>
>>> *  Jim Uttaro *
>>>
>>>
>>>
>>> *From:* BESS  *On Behalf Of * Gyan Mishra
>>> *Sent:* Wednesday, May 26, 2021 12:57 AM
>>> *To:* Robert Raszuk 
>>> *Cc:* Jeff Tantsura ; Arie Vayner <
>>> ar...@vayner.net>; bess@ietf.org; Satya Mohanty (satyamoh) >> 40cisco@dmarc.ietf.org>
>>> *Subject:* Re: [bess] Req

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Satya

For EBGP DCs with multi-stage clos I understand this can be used, however
with Cisco & Juniper & Nokia & Arista  and maybe other vendor
implementations seem to combine the non transitive link bw extended
community and transitive cumulative link bw extended community into a
single feature that works for UCMP intra AS and inter AS.  Please confirm.

These two drafts seem to be combined by implementations into a single UCMP
feature for both eBGP and iBGP.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03

Cisco:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html

https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853

Juniper:

https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html

Nokia:

https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html


Arista:

https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621

Kind Regards

Gyan

On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) 
wrote:

> Hi Jim,
>
>
>
> No, they do not.
>
>
>
> This draft under discussion is a way to aggregate the link bandwidth in
> EBGP DCs and advertise it upstream.
>
> It works well in multi-stage clos topology fabrics.
>
> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
> node of each stage (unless the sink).
>
>
>
> The draft you are mentioning,
> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
> really a way to communicate the link-bandwidth across EBGP boundaries.
>
> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
> unchanged) although it also applies to Option B deployments (next-hop-self).
>
> There is no notion of aggregating bandwidth here.
>
>
>
> HTH.
>
>
>
> Best Regards,
>
> --Satya
>
>
>
>
>
> *From: *"UTTARO, JAMES" 
> *Date: *Wednesday, May 26, 2021 at 5:38 AM
> *To: *Gyan Mishra , Robert Raszuk <
> rob...@raszuk.net>
> *Cc: *Jeff Tantsura , Arie Vayner <
> ar...@vayner.net>, "bess@ietf.org" , "Satya Mohanty
> (satyamoh)" 
> *Subject: *RE: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
> *Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing
> address the same field of use? *
>
>
>
> *Thanks,*
>
> *  Jim Uttaro *
>
>
>
> *From:* BESS  *On Behalf Of * Gyan Mishra
> *Sent:* Wednesday, May 26, 2021 12:57 AM
> *To:* Robert Raszuk 
> *Cc:* Jeff Tantsura ; Arie Vayner <
> ar...@vayner.net>; bess@ietf.org; Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
> Across the DC space in general most providers use NVO3 and vxlan source
> port entropy L2/L3/L4 hash which provides per packet uniform 50/50 load
> balancing at the L2 VNI overlay layer, which translates into underlay load
> balancing of flows and thus no polarization.
>
>
>
> Across the DC space speaking from an operators perspective as under the
> floor fiber is not at a premium compare to 100G facilities costs the net
> addition of bandwidth can be done fairly quickly so you are ahead of the
> congestion curve and can be proactive versus reactively upgrading bandwidth
> piecemeal here and there ad hoc.
>
>
>
> There still maybe cases that still arise as even if you have the fiber
> infrastructure available, it’s not easy to upgrade and flash every link
> simultaneously in the DC in one or multiple maintenance windows, so you
> could still be left with some uneven bandwidth across the DC that could
> utilize this feature.
>
>
>
> DC comes into play for PE-CE “wan links”as well  use case for unequal cost
> load balancing use of the cumulative link bandwidth community regenerated.
>
>
>
>
>
> I think the use case where both the iBGP P core P-P links  or eBGP PE - PE
> inter-as are all wan links where link upgrades tend to not get done in
> unison uniformly, and in those cases both iBGP link bandwidth community can
> be heavily utilized as well as eBGP cumulative regenerated link bandwidth
> community for unequal cost  load balancing.  Across the core as well it is
> hard to flash all links even under floor fiber to the same bandwidth all at
> once you are left with the requirement for unequal coat load balancing.
>
>
>
> As operators upgrade their DC as well as core infrastructure to IPv6
> forwardi

Re: [bess] Please send slot request for IETF 111

[Gyan Mishra]

Hi Mankamana

I would like request a 10 minute slot.

https://datatracker.ietf.org/doc/draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh/01/


Thank you

Gyan

On Thu, Jun 24, 2021 at 10:39 AM Mankamana Mishra (mankamis)  wrote:

> All,
>
> Please send me slot request for IETF 111. Please do not change the
> subject, last IETF I had missed few reply due to subject change ☺
>
>
>
> Mankamana
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] WG POLL: Moving forward draft-ietf-bess-evpn-fast-df-recovery by dropping "Handshake" option

[Gyan Mishra]

I support the simple and robust time synchronization one-way signaling
solution over the 2-way overly complex handshake solution.

The time sync solution seems very flexible and limits exposure to loops and
duplicates during the switchover.

>From a implementation perspective I don’t think most vendors would want to
implement both and if they pick one or the other to implement that could be
a problem, so I think a decision should be made from an interoperability
standpoint on one of the solutions and remove the other.

I agree to remove the handshake option from the draft if we have WG
consensus.

Kind Regards

Gyan

On Mon, Jun 7, 2021 at 1:24 PM Mankamana Mishra (mankamis)  wrote:

> Support, it would be good to progress with simplified version of document.
> And we can later consider if its worth considering other solution .
>
>
>
> *From: *"slitkows.i...@gmail.com" 
>
>
> *Date: *Friday, June 4, 2021 at 2:19 AM
> *To: *'BESS' 
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *WG POLL: Moving forward draft-ietf-bess-evpn-fast-df-recovery
> by dropping "Handshake" option
> *Resent-From: *
> *Resent-To: *, , <
> matthew.bo...@nokia.com>
> *Resent-Date: *Friday, June 4, 2021 at 2:19 AM
>
>
>
> Hi WG,
>
>
>
> Just as a reminder, draft-ietf-bess-evpn-fast-df-recovery currently
> proposes two options: 1) use time synchronization, 2) Use handshake.
>
>
>
> We have issues moving forward the draft because of some controversy on the
> handshake option while the time sync option seems to have implementations.
>
>
>
> It seems that the authors/co-authors agreed to progress the document by
> removing the handshake option, leaving the “time sync” as the core of the
> document.
>
>
>
> As the document is a WG document, we (chairs) need to confirm that there
> is no objection from the WG progressing the document in such a way.
>
>
>
> Please provide your feedback.
>
>
>
> We are opening a poll starting today and ending on  18th June  to
> gather feedbacks.
>
>
>
> Thanks,
>
>
>
> Stephane
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/
>
>
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-02.txt

[Gyan Mishra]

+1

Kind Regards

Gyan
On Sat, Jun 5, 2021 at 6:31 PM Jeff Tantsura 
wrote:

> Dear authors,
>
> Gven the current state of the draft, it should be a Standards Track
> document.
>
> Thanks!
>
> Cheers,
> Jeff
> On Jun 5, 2021, 1:35 PM -0700, internet-dra...@ietf.org, wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title : EVPN control plane for Geneve
> Authors : Sami Boutros
> Ali Sajassi
> John Drake
> Jorge Rabadan
> Sam Aldrin
> Filename : draft-ietf-bess-evpn-geneve-02.txt
> Pages : 10
> Date : 2021-06-05
>
> Abstract:
> This document describes how Ethernet VPN (EVPN) control plane can be
> used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
> Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
> solutions.
>
> EVPN control plane can also be used by Network Virtualization Edges
> (NVEs) to express Geneve tunnel option TLV(s) supported in the
> transmission and/or reception of Geneve encapsulated data packets.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-geneve-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 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
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

t;> 3 and 4 for the use cases.
>>>
>>>
>>>
>>> This feature has multiple-vendor implementations and has been deployed
>>> by several customers in their networks.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>> ___
>>> 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
>>
> --

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Robert

Very good point on millions of mice flows that can take advantage of
unequal cost lb,  versus a small number of elephant flows.

Good point on further granularity with  TE bandwidth management .

Gyan

On Tue, May 25, 2021 at 2:06 PM Robert Raszuk  wrote:

> Gyan,
>
> It is always helpful to an assessment into right scale.
>
> Yes if you take few flows perhaps even a few big ones may suffer from
> polarization. But the feature here is about hashing millions of micro
> flows. With that in mind polarization effects are insignificant at
> decent operational scale.
>
> I support this draft.
>
> Cheers,
> Robert
>
> PS. Also keep in mind that for handling elephant flows there are bunch of
> TE like solutions in place which can be used which in turn give you very
> fine control.
>
> On Tue, May 25, 2021 at 9:23 AM Gyan Mishra  wrote:
>
>>
>> Hi Satya
>>
>> I read the draft and have a few questions.
>>
>> IPv4 does not support per flow per packet load balancing as all packets
>> belonging to the same flow must hash to the same path to prevent out of
>> order packets and thus is subject to polarization of flows as high
>> bandwidth flows may hash to the same path and low bandwidth flows as well
>> to the same path resulting in very uneven load balancing.  Do to this issue
>> it does not make either iBGP or eBGP can really benefit from link bandwidth
>> extended community weight based load sharing.
>>
>> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header
>> hash generated 20 byte key input to hash function results in uniform 50/50
>> load balancing over EGP or IGP ECMP paths.
>>
>> I think it maybe a good idea to reference the IPv4 polarization issue
>> with flow based load balancing and that only with IPv6 flow label can true
>> 50/50 uniform load balancing be achieved.
>>
>> I noticed that the normative draft referenced was adopted but has not
>> progressed.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>>
>> Has the draft been implemented by Cisco or any other vendors ?
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> On behalf of all the authors, we request a discussion of the draft
>>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>>  and subsequent WG adoption.
>>>
>>> This draft extends the usage of the DMZ link bandwidth to scenarios
>>> where the cumulative link bandwidth needs to be advertised to a BGP
>>> speaker.
>>>
>>> Additionally, there is provision to send the link bandwidth extended
>>> community to EBGP speakers via configurable knobs. Please refer to section
>>> 3 and 4 for the use cases.
>>>
>>>
>>>
>>> This feature has multiple-vendor implementations and has been deployed
>>> by several customers in their networks.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *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
>>
> --

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Arie

Thanks for responding on the polarization question and I agree it can
enhance ECMP capability and maybe even counter or reduce effects of
polarization.

Thanks

Gyan

On Tue, May 25, 2021 at 1:26 PM Arie Vayner  wrote:

> The flow polarization or elephant flow issues are well known industry
> items and they apply to both equal and unequal cost multi-path approaches.
>
> The objective of this proposal is to enhance ECMP, and enable unequal cost
> multi-pathing, which is very useful when a service is offered by a
> multitude of endpoints, which may or may not have the same capacity.
> This solution has been implemented in production, and offers a real option
> for traffic load management.
>
> Tnx
> Arie
>
> On Tue, May 25, 2021 at 9:48 AM Jakob Heitz (jheitz)  40cisco@dmarc.ietf.org> wrote:
>
>> The link bandwidth community has been implemented by Cisco and deployed by
>>
>> our customers for several years.
>>
>> Polarization of flows in multipath is a well known problem, but it hasn't
>> deterred
>>
>> people from using it.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* BESS  *On Behalf Of * Gyan Mishra
>> *Sent:* Tuesday, May 25, 2021 12:24 AM
>> *To:* Satya Mohanty (satyamoh) 
>> *Cc:* bess@ietf.org
>> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
>> Draft
>>
>>
>>
>>
>>
>> Hi Satya
>>
>>
>>
>> I read the draft and have a few questions.
>>
>>
>>
>> IPv4 does not support per flow per packet load balancing as all packets
>> belonging to the same flow must hash to the same path to prevent out of
>> order packets and thus is subject to polarization of flows as high
>> bandwidth flows may hash to the same path and low bandwidth flows as well
>> to the same path resulting in very uneven load balancing.  Do to this issue
>> it does not make either iBGP or eBGP can really benefit from link bandwidth
>> extended community weight based load sharing.
>>
>>
>>
>> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header
>> hash generated 20 byte key input to hash function results in uniform 50/50
>> load balancing over EGP or IGP ECMP paths.
>>
>>
>>
>> I think it maybe a good idea to reference the IPv4 polarization issue
>> with flow based load balancing and that only with IPv6 flow label can true
>> 50/50 uniform load balancing be achieved.
>>
>>
>>
>> I noticed that the normative draft referenced was adopted but has not
>> progressed.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>>
>>
>>
>> Has the draft been implemented by Cisco or any other vendors ?
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Gyan
>>
>>
>>
>>
>>
>> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org> wrote:
>>
>> Hi all,
>>
>>
>>
>> On behalf of all the authors, we request a discussion of the draft
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>  and subsequent WG adoption.
>>
>> This draft extends the usage of the DMZ link bandwidth to scenarios where
>> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>
>> Additionally, there is provision to send the link bandwidth extended
>> community to EBGP speakers via configurable knobs. Please refer to section
>> 3 and 4 for the use cases.
>>
>>
>>
>> This feature has multiple-vendor implementations and has been deployed by
>> several customers in their networks.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>> *M 301 502-1347 <(301)%20502-1347>*
>>
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> --

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

That’s great  news that Cisco had implemented and customers have deployed
for years!

I see it’s supported in IOS and XR

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/bgp-link-bandwidth.html

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5000/bgp/65x/b-bgp-cg-ncs5000-65x/b-bgp-cg-ncs5000-65x_chapter_010.html


Thanks!!

Gyan


On Tue, May 25, 2021 at 12:48 PM Jakob Heitz (jheitz) 
wrote:

> The link bandwidth community has been implemented by Cisco and deployed by
>
> our customers for several years.
>
> Polarization of flows in multipath is a well known problem, but it hasn't
> deterred
>
> people from using it.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* BESS  *On Behalf Of * Gyan Mishra
> *Sent:* Tuesday, May 25, 2021 12:24 AM
> *To:* Satya Mohanty (satyamoh) 
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
>
>
> Hi Satya
>
>
>
> I read the draft and have a few questions.
>
>
>
> IPv4 does not support per flow per packet load balancing as all packets
> belonging to the same flow must hash to the same path to prevent out of
> order packets and thus is subject to polarization of flows as high
> bandwidth flows may hash to the same path and low bandwidth flows as well
> to the same path resulting in very uneven load balancing.  Do to this issue
> it does not make either iBGP or eBGP can really benefit from link bandwidth
> extended community weight based load sharing.
>
>
>
> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash
> generated 20 byte key input to hash function results in uniform 50/50 load
> balancing over EGP or IGP ECMP paths.
>
>
>
> I think it maybe a good idea to reference the IPv4 polarization issue with
> flow based load balancing and that only with IPv6 flow label can true 50/50
> uniform load balancing be achieved.
>
>
>
> I noticed that the normative draft referenced was adopted but has not
> progressed.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>
>
>
> Has the draft been implemented by Cisco or any other vendors ?
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org> wrote:
>
> Hi all,
>
>
>
> On behalf of all the authors, we request a discussion of the draft
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and
> subsequent WG adoption.
>
> This draft extends the usage of the DMZ link bandwidth to scenarios where
> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>
> Additionally, there is provision to send the link bandwidth extended
> community to EBGP speakers via configurable knobs. Please refer to section
> 3 and 4 for the use cases.
>
>
>
> This feature has multiple-vendor implementations and has been deployed by
> several customers in their networks.
>
>
>
> Best Regards,
>
> --Satya
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Satya

I read the draft and have a few questions.

IPv4 does not support per flow per packet load balancing as all packets
belonging to the same flow must hash to the same path to prevent out of
order packets and thus is subject to polarization of flows as high
bandwidth flows may hash to the same path and low bandwidth flows as well
to the same path resulting in very uneven load balancing.  Do to this issue
it does not make either iBGP or eBGP can really benefit from link bandwidth
extended community weight based load sharing.

IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash
generated 20 byte key input to hash function results in uniform 50/50 load
balancing over EGP or IGP ECMP paths.

I think it maybe a good idea to reference the IPv4 polarization issue with
flow based load balancing and that only with IPv6 flow label can true 50/50
uniform load balancing be achieved.

I noticed that the normative draft referenced was adopted but has not
progressed.

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/

Has the draft been implemented by Cisco or any other vendors ?

Kind Regards

Gyan


On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh)  wrote:

> Hi all,
>
>
>
> On behalf of all the authors, we request a discussion of the draft
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and
> subsequent WG adoption.
>
> This draft extends the usage of the DMZ link bandwidth to scenarios where
> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>
> Additionally, there is provision to send the link bandwidth extended
> community to EBGP speakers via configurable knobs. Please refer to section
> 3 and 4 for the use cases.
>
>
>
> This feature has multiple-vendor implementations and has been deployed by
> several customers in their networks.
>
>
>
> Best Regards,
>
> --Satya
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Gyan Mishra]

Sorry, attached.

Thanks

Gyan

On Wed, May 19, 2021 at 5:03 AM Adrian Farrel  wrote:

> Hi Gyan,
>
> Thanks for the work.
>
> > Attached is a txt version -gsm update of version 10
>
> No attachment received.
>
> Best,
> Adrian
>
>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*



BESS Working Group A. Farrel
Internet-DraftOld Dog Consulting
Intended status: Standards TrackJ. Drake
Expires: October 17, 2021   E. Rosen
Juniper Networks
K. Patel
Arrcus, Inc.
L. Jalil
 Verizon
  April 15, 2021


   Gateway Auto-Discovery and Route Advertisement for Segment Routing
 Enabled Domain Interconnection
 draft-ietf-bess-datacenter-gateway-10

Abstract

   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a protocol mechanism that can be used within a
   data center, and also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site, it needs to
   know the complete set of gateway routers at the remote data center,
   the points of connection from those gateways to the backbone network,
   and the connectivity across the backbone network.

   Segment Routing may also be operated in other sites, such as access
   networks.  Those sites also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the underlay transport 
routes for internal
   prefixes at the site to which it provides access,
   and also to advertise on behalf of each other, all the gateways within the 
site to the same
   Segment Routing domain.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.





Farrel, et al.  Expires October 17, 2021[Page 1]

Internet-Draft   SR DC Gateways   April 2021


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 17, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   3.  SR Domain Gateway Auto-Discovery  . . . . . . . . . . . . . .   5
   4.  Relationship to BGP Link State and Egress Peer Engineering  .   7
   5.  Advertising an SR Domain Route Externally . . . . . . . . . .   7
   6.  Encapsulation . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
 9.1.  Relationship to Route Tar

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Gyan Mishra]

Dear Authors,

Attached is a txt version -gsm update of version 10 that contains a first
cut at what I think would be appropriate  RFC 2119 SHOULD / MUST
language for a specification.  I also made some editorial updates to make
the specification clear to the reader.  In this thread and on the call we
had we talked about changing the ingress & egress domain to ingress &
egress site which I made that change as well.  Using the word "domain"
really makes it confusing as
to which domain is being referred  so the change to "site" really helps
readability.

Few more questions & thoughts  related to the draft for the authors to help
in finalizing the draft for publication below:

GW failover: (John Scudder)
GW's will need a local iBGP session for failover.  In the scenario where
one GW is disconnected from the backbone the draft clearly states that the
advertisement of the GW is withdrawn, when the active set of GWs changes
each externally advertised route will be re-advertised with the new tunnel
encapsulation attribute union which reflects the current set of active
GWs.
In the case of inconsistent routing within the site GW1 can reach GW2, GW1
cannot reach S2. Low probability but entirely possible.  Maybe a note in
the draft on this scenario may make things worse with blackhole to GW2.

Section 5 - RFC 9012 Tunnel encapsulation attribute BGP Prefix-sid
limitations (Alvaro Retana)
SR end to end or at a minimum within an SR domain may not be general use
case and maybe limited due to BGP prefix sid sub-tlv can only be used for
IPv4/IPv6 labeled unicast AFI/SAFI 1/4 2/4.
We may want to comment in section 5 that use of SR maybe limited and not a
general use case.  Also does this limitation impact the use of SRv6?

Additional thoughts for the authors.

Does the draft require SR in the backbone or can RSVP-TE be used?

If RSVP-TE can be used, maybe a different name for the identifier should be
used and not SR domain identifier.

Section 3 - Is the SR domain identifier value the RT that is attached to
the GW auto discovery route?

RFC 4360 is mentioned in section 3 as normative reference, however RFC 5668
4 byte extended community should also be mentioned as normative.

We may want to mention this bleed over of GW routes due to
mis-configuration in section 8 - security considerations

   Note that if a GW is (mis)configured with a different SR domain

   identifier from the other GWs to the same domain then it will not be

   auto-discovered by the other GWs (and will not auto-discover the

   other GWs).  This would result in a GW for another site

   receiving only the Tunnel Encapsulation attribute included in the BGP

   best route; i.e., the Tunnel Encapsulation attribute of the
   (mis)configured GW or that of the other GWs.

As there may be significant propagation delays with convergence for
re-advertisement as the set of active GWs change in cases where the number
of AS's is very large over the public internet, maybe that should be
mentioned.

Kind Regards

Gyan



On Tue, May 18, 2021 at 4:49 PM John E Drake  wrote:

> Excellent, thanks so much for your help on this.
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: Gyan Mishra 
> > Sent: Tuesday, May 18, 2021 4:28 PM
> > To: Lars Eggert 
> > Cc: General Area Review Team ; bess@ietf.org;
> draft-ietf-
> > bess-datacenter-gateway@ietf.org; last-c...@ietf.org
> > Subject: Re: [Last-Call] Genart last call review of
> draft-ietf-bess-datacenter-
> > gateway-10
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Lars’s  & DC Gateway authors
> >
> > I will be responding back today to the Gen-Art original email I sent
> with final
> > comments and hope the final comments will help improve the document.
> >
> > I will also address the comments from John Scudder related to GW
> failover as
> > well as Alvaro’s comments related to tunnel encapsulation attribute BGP
> prefix
> > sid Sub-TLV limitations.  Also will add new text recommendations related
> to RFC
> > 2119 MUST / SHOULD language to help improve the document.
> >
> >
> > Thank you
> >
> > Gyan
> > On Tue, May 18, 2021 at 3:31 AM Lars Eggert  wrote:
> >
> > > Gyan, thank you for your review and thank you all for the following
> > > discussion. I have entered a No Objection ballot for this document
> > > based on the current status of the discussion.
> > >
> > > Lars
> > >
> > >
> > > > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker
> > > > 
> > > wrote:
> > > >
> > > > Reviewer: Gyan Mishra
> > > > Review result: Not Ready
> > > >
&

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Gyan Mishra]

Hi Lars’s  & DC Gateway authors

I will be responding back today to the Gen-Art original email I sent with
final comments and hope the final comments will help improve the document.

I will also address the comments from John Scudder related to GW
failover as well as Alvaro’s comments related to tunnel encapsulation
attribute BGP prefix sid Sub-TLV limitations.  Also will add new text
recommendations related to RFC 2119 MUST / SHOULD language to help improve
the document.


Thank you

Gyan
On Tue, May 18, 2021 at 3:31 AM Lars Eggert  wrote:

> Gyan, thank you for your review and thank you all for the following
> discussion. I have entered a No Objection ballot for this document based on
> the current status of the discussion.
>
> Lars
>
>
> > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker 
> wrote:
> >
> > Reviewer: Gyan Mishra
> > Review result: Not 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
> >
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-bess-datacenter-gateway-??
> > Reviewer: Gyan Mishra
> > Review Date: 2021-04-28
> > IETF LC End Date: 2021-04-29
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >   This document defines a mechanism using the BGP Tunnel Encapsulation
> >   attribute to allow each gateway router to advertise the routes to the
> >   prefixes in the Segment Routing domains to which it provides access,
> >   and also to advertise on behalf of each other gateway to the same
> >   Segment Routing domain.
> >
> > This draft needs to provide some more clarity as far as the use case and
> where
> > this would as well as how it would be used and implemented.  From
> reading the
> > specification it appears there are some technical gaps that exist. There
> are
> > some major issues with this draft. I don’t think this draft is ready yet.
> >
> > Major issues:
> >
> > Abstract comments:
> > It is mentioned that the use of Segment Routing within the Data Center.
> Is
> > that a requirement for this specification to work as this is mentioned
> > throughout the draft?  Technically I would think the concept of the
> discovery
> > of the gateways is feasible without the requirement of SR within the Data
> > Center.
> >
> > The concept of load balancing is a bigger issue brought up in this draft
> as the
> > problem statement and what this draft is trying to solve which I will
> address
> > in the introduction comments.
> >
> > Introduction comments:
> > In the introduction the use case is expanded much further to any
> functional
> > edge AS verbiage below.
> >
> > OLD
> >
> >   “SR may also be operated in other domains, such as access networks.
> >   Those domains also need to be connected across backbone networks
> >   through gateways.  For illustrative purposes, consider the Ingress
> >   and Egress SR Domains shown in Figure 1 as separate ASes.  The
> >   various ASes that provide connectivity between the Ingress and Egress
> >   Domains could each be constructed differently and use different
> >   technologies such as IP, MPLS with global table routing native BGP to
> >   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN”
> >
> > This paragraph expands the use case to any ingress or egress stub domain
> Data
> > Center, Access or any.  If that is the case should the draft name change
> to
> > maybe a “stub edge domain services discovery”.  As this draft can be
> used for
> > any I would not preclude any use case and make the GW discovery open to
> be used
> > for any service GW edge function and change the draft name to something
> more
> > appropriate.
> >
> > This paragraph also states for illustrative purposes which is fine but
> then it
> > expands the overlay/underlay use cases. I believe this use case can only
> be
> > used for any technology that has an overlay/underlay which would
> preclude any
> > use case with just an underlay global table routing such as what is
> mentioned
> > “IP, MPLS with global table routing native BGP to the edge.  The IP or
> global
> > table routing would be an issue as this specification requires setting a
> RT and
> > an export/import RT policy for the discover of routes advertised by the
> GW

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

[Gyan Mishra]

Chiming in.  Some history.

Due  to the complexities of ASM requirement for MSDP / RP for inter domain
multicast, IPv6 for simplicity as well as lessons learned with the
complexity of ASM was designed to support SSM only for inter domain
multicast.  Thus an MSDP extension was purposely never created for IPv6.


RFC 8815  came out last year  officially deprecating ASM / MSDP for inter
domain multicast with SSM replacement for inter domain multicast.

https://datatracker.ietf.org/doc/html/rfc8815

There is a big push worldwide for operators as well as customers to migrate
off ASM to SSM for OPEX savings.

Gyan

On Mon, May 17, 2021 at 6:11 PM Eric Vyncke (evyncke)  wrote:

> Alvaro
>
> Thank you for the added piece of information. I am clearing my DISCUSS
> tomorrow (past midnight here).
>
> Regards
>
> -éric
>
> -Original Message-
> From: iesg  on behalf of Alvaro Retana <
> aretana.i...@gmail.com>
> Date: Monday, 17 May 2021 at 23:34
> To: Éric Vyncke via Datatracker , Eric Vyncke <
> evyn...@cisco.com>, The IESG 
> Cc: Matthew Bocci , "Mankamana Mishra
> (mankamis)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "
> draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" <
> draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org>, "bess@ietf.org" <
> bess@ietf.org>
> Subject: Re: [bess] Éric Vyncke's Discuss on
> draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)
>
> Éric:
>
> Hi!
>
> MSDP (from 2003) is an IPv4-only protocol.
>
> Also, take a look at rfc4611/BCP121 (MSDP Deployment Scenarios) which
> mentions other IPv6 alternatives which makes any extension of MSDP
> unnecessary.
>
>
> Alvaro.
>
>
> On May 17, 2021 at 2:10:13 AM, Éric Vyncke wrote:
>
> > == DISCUSS ==
> > While I am an expert neither in multicast not in VPN, I wonder why
> this
> > document is only about IPv4 and not a single word is written about
> IPv6.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

tations exist for
>the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
>message for one of the address families for which [RFC8669] has a
>defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760]
>    [RFC8277].  If included in a BGP UPDATE for any other address family,
>it MUST be ignored.
>
> IOW, even though the overall mechanism could not be SR-specific, the
> SR solution can't be implemented in a general way (without more
> consideration).
>
> Alvaro.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Adrian

In the introduction it mentions the following backbone transport:

   The various ASes that provide connectivity between the Ingress and Egress
   Domains could each be constructed differently and use different
   technologies such as IP, MPLS with global table routing native BGP to
   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.


  In the draft it talks about SR steering

  however can RSVP be used in the backbone transport .


I think to clarify we should mention the MUST for the data plane
requirements for the backbone transport.


On the call last week we confirmed  that the ingress and egress
domains now called “sites” not domains do not have to be SR enabled.


Kind Regards


Gyan


On Mon, May 17, 2021 at 5:04 PM Gyan Mishra  wrote:

> Hi John
>
> I agree with your comments that the scenario I mentioned is covered in
> Section 3 and agree as well on the RFC 2119 keyword usage scrub.
>
> In-line
>
> On Mon, May 17, 2021 at 3:55 PM John Scudder  wrote:
>
>> Hi Gyan,
>>
>> > On May 17, 2021, at 1:50 PM, Gyan Mishra  wrote:
>> >
>> > So if GW2 connection to external was down but GW1 still has its
>> connection to external.  GW2 would auto discover GW1 over iBGP and GW2
>> would advertise both GW1 and GW2 as reachable gateways.  However GW2 has
>> its external peer down.  So if GW1 continues to advertised GW2 as we stated
>> GW1 will auto discover  GW2 over iBGP.
>>
>> Isn’t this scenario covered? From §3:
>>
>>If a gateway becomes disconnected from the backbone network, or if
>>the SR domain operator decides to terminate the gateway's activity,
>>it withdraws the advertisements described above.  This means that
>>remote gateways at other sites will stop seeing advertisements from
>>this gateway.
>
>
>Gyan> Yes.  Agreed.  I wanted to draw some more attention to this to
> the authors on the withdrawal that it’s critical and agreed a MUST.
>
>>
>>
>> So when GW2’s external peering goes down, GW2 withdraws its auto
>> discovery route, and therefore GW1 re-advertises its routes externally
>> without GW2 listed in the tunnel attribute.
>>
>
>
>
>
>> I will say that reviewing the above-quoted text — which seems tailor-made
>> for a “MUST withdraw” — made me notice that the draft makes only sporadic
>> and desultory use of RFC2119 keywords. In fact there are so few used, that
>> it seems like it might be better to scrub those two SHOULD and two MUST out
>> and remove the 2119 citation.
>
>
> Gyan> Agreed.  I will parse the draft for RFC 2119 keyword  placement  in
> my final GEN-ART review update
>
>>
>>
>> —John
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi John

I agree with your comments that the scenario I mentioned is covered in
Section 3 and agree as well on the RFC 2119 keyword usage scrub.

In-line

On Mon, May 17, 2021 at 3:55 PM John Scudder  wrote:

> Hi Gyan,
>
> > On May 17, 2021, at 1:50 PM, Gyan Mishra  wrote:
> >
> > So if GW2 connection to external was down but GW1 still has its
> connection to external.  GW2 would auto discover GW1 over iBGP and GW2
> would advertise both GW1 and GW2 as reachable gateways.  However GW2 has
> its external peer down.  So if GW1 continues to advertised GW2 as we stated
> GW1 will auto discover  GW2 over iBGP.
>
> Isn’t this scenario covered? From §3:
>
>If a gateway becomes disconnected from the backbone network, or if
>the SR domain operator decides to terminate the gateway's activity,
>it withdraws the advertisements described above.  This means that
>remote gateways at other sites will stop seeing advertisements from
>this gateway.


   Gyan> Yes.  Agreed.  I wanted to draw some more attention to this to the
authors on the withdrawal that it’s critical and agreed a MUST.

>
>
> So when GW2’s external peering goes down, GW2 withdraws its auto discovery
> route, and therefore GW1 re-advertises its routes externally without GW2
> listed in the tunnel attribute.
>




> I will say that reviewing the above-quoted text — which seems tailor-made
> for a “MUST withdraw” — made me notice that the draft makes only sporadic
> and desultory use of RFC2119 keywords. In fact there are so few used, that
> it seems like it might be better to scrub those two SHOULD and two MUST out
> and remove the 2119 citation.


Gyan> Agreed.  I will parse the draft for RFC 2119 keyword  placement  in
my final GEN-ART review update

>
>
> —John

-- 

<http://www.verizon.com/>

*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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

hink
> what the document says (as opposed to what’s in the authors’ heads?) is the
> first description I give below. Let me know if you want me to walk through
> my reasoning in detail with reference to the document.
>
>
>
> —John
>
>
>
> On May 14, 2021, at 4:12 PM, John Scudder  wrote:
>
>  Hi Adrian,
>
>
>
> Thanks for your reply. Pressed for time at the moment but one partial
> response:
>
>
>
> On May 14, 2021, at 1:04 PM, Adrian Farrel  wrote:
>
>
>
> Agree with you that "stuff happens." I think that what you have described
> is a window not a permanent situation.
> When GW2 knows it can't reach X any more, it will stop advertising X, and
> GW1 will receive that and will update what it advertises on behalf of GW2.
>
>
>
> Ah, perhaps I have badly misunderstood the way this works. I had thought
> it went something like this:
>
>
>
> - GW1 knows it can reach GW2 because of GW2’s auto discovery route
>
> - GW1 knows the set S of internal prefixes it can reach
>
> - GW1 advertises each prefix from S with both GW1 and GW2 in the tunnel
> attribute
>
>
>
> In the description above, there’s no notion of GW2 telling GW1 what
> internal prefixes GW2 can reach, or GW1 caring.  Now I suppose you are
> telling me that it goes:
>
>
>
> - GW1 knows it can reach GW2 because of GW2’s auto discovery route
>
> - GW1 knows the full set of prefixes GW2 can reach. _How does it know
> this?_
>
> - GW1 constructs each advertisement listing only the correct set of
> gateways in the tunnel attribute
>
>
>
> The key question is the one I’ve highlighted: how does GW1 come to know
> GW2’s internally-reachable prefixes? I didn’t notice any of this in the
> spec. Maybe it was just my sloppy reading, I’ll look again.
>
>
>
> Further, if GW1 can no longer receive advertisements from GW2 then it will
> stop advertising on behalf of GW2.
>
>
>
> Yes, that’s understood, but I was positing a case where just because GW1
> can reach GW2 stably, and just because GW1 can reach X stably, it does not
> imply GW2 can reach X.
>
>
>
> —John
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*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

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Gyan Mishra]

Hi Lars

I met with the authors on Friday 5/14 and we went over my questions and
review of the draft in detail.

I will respond today with a detailed update on the status of my review
based on feedback from the authors from Friday meeting that the draft is in
a “Ready” state with minor updates & recommendations.

Kind Regards

Gyan

On Mon, May 17, 2021 at 4:38 AM Lars Eggert  wrote:

> Gyan, thank you for your review. I have not seen a response from the
> editors to your review yet, and so I'm holding off for the moment on
> entering a ballot for this document.
>
> Authors, would you please respond to Gyan's review?
>
> Thanks,
> Lars
>
>
> > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker 
> wrote:
> >
> > Reviewer: Gyan Mishra
> > Review result: Not 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
> >
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-bess-datacenter-gateway-??
> > Reviewer: Gyan Mishra
> > Review Date: 2021-04-28
> > IETF LC End Date: 2021-04-29
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >   This document defines a mechanism using the BGP Tunnel Encapsulation
> >   attribute to allow each gateway router to advertise the routes to the
> >   prefixes in the Segment Routing domains to which it provides access,
> >   and also to advertise on behalf of each other gateway to the same
> >   Segment Routing domain.
> >
> > This draft needs to provide some more clarity as far as the use case and
> where
> > this would as well as how it would be used and implemented.  From
> reading the
> > specification it appears there are some technical gaps that exist. There
> are
> > some major issues with this draft. I don’t think this draft is ready yet.
> >
> > Major issues:
> >
> > Abstract comments:
> > It is mentioned that the use of Segment Routing within the Data Center.
> Is
> > that a requirement for this specification to work as this is mentioned
> > throughout the draft?  Technically I would think the concept of the
> discovery
> > of the gateways is feasible without the requirement of SR within the Data
> > Center.
> >
> > The concept of load balancing is a bigger issue brought up in this draft
> as the
> > problem statement and what this draft is trying to solve which I will
> address
> > in the introduction comments.
> >
> > Introduction comments:
> > In the introduction the use case is expanded much further to any
> functional
> > edge AS verbiage below.
> >
> > OLD
> >
> >   “SR may also be operated in other domains, such as access networks.
> >   Those domains also need to be connected across backbone networks
> >   through gateways.  For illustrative purposes, consider the Ingress
> >   and Egress SR Domains shown in Figure 1 as separate ASes.  The
> >   various ASes that provide connectivity between the Ingress and Egress
> >   Domains could each be constructed differently and use different
> >   technologies such as IP, MPLS with global table routing native BGP to
> >   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN”
> >
> > This paragraph expands the use case to any ingress or egress stub domain
> Data
> > Center, Access or any.  If that is the case should the draft name change
> to
> > maybe a “stub edge domain services discovery”.  As this draft can be
> used for
> > any I would not preclude any use case and make the GW discovery open to
> be used
> > for any service GW edge function and change the draft name to something
> more
> > appropriate.
> >
> > This paragraph also states for illustrative purposes which is fine but
> then it
> > expands the overlay/underlay use cases. I believe this use case can only
> be
> > used for any technology that has an overlay/underlay which would
> preclude any
> > use case with just an underlay global table routing such as what is
> mentioned
> > “IP, MPLS with global table routing native BGP to the edge.  The IP or
> global
> > table routing would be an issue as this specification requires setting a
> RT and
> > an export/import RT policy for the discover of routes advertised by the
> GWs.
> > As I don’t think this solution from what I can tell would work
> technic

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Section 3 verbiage below describes the
re-advertisement of current set of GWs due to GW being added or deleted.

So the blackhole John mentioned due to a GW being disconnected from
backbone should not occur.

   As described in Section 1
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-10#section-1>,
each

   GW will include a Tunnel

   Encapsulation attribute with the GW encapsulation information for
   each of the SR domain's active GWs (including itself) in every route
   advertised externally to that SR domain.  As the current set of
   active GWs changes (due to the addition of a new GW or the failure/
   removal of an existing GW) each externally advertised route will be
   re-advertised with a new Tunnel Encapsulation attribute which
   reflects current set of active GWs.

   If a gateway becomes disconnected from the backbone network, or if
   the SR domain operator decides to terminate the gateway's activity,
   it withdraws the advertisements described above.  This means that
   remote gateways at other sites will stop seeing advertisements from
   this gateway.


I support this very important draft that provides a critical solution
for remote site GW auto-discovery over a Multi-AS transit SR / MPLS
domain.


For those whom have not read normative reference below I suggest
reading as it helps provide context to the problem statement and
solution.


https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05



Kind Regards


Gyan


On Sat, May 15, 2021 at 12:35 AM Gyan Mishra  wrote:

>
> Adrian & Authors please correct me if I misspeak the way I read the draft.
>
> I did not see in the draft stating explicitly how the internal DC GW
> routes are advertised which I believe implicitly done via standard BGP AFI
> / SAFI route propagation natively over the SR domain.  So for example if
> the internal GW routers are SAFI 1 unicast they are propagated natively
> global table routed as SAFI 1 inter domain from ingress to egress DC GW.
>
> For VPN overlay SAFI 128 129 routes are propagated natively as SAFI 128
> 129 over the SR core.
>
> So all GW internal routes AFI / SAFI are supported meaning SAFI  1, 128,
> 129.
>
> Kind Regards
>
> Gyan
>
> On Fri, May 14, 2021 at 10:45 PM Gyan Mishra 
> wrote:
>
>> Hi Adrian
>>
>> I may have missed this in the draft but the solution for this failover
>> scenario is if each GW can only advertise itself, which I think that is
>> stated in section 3 then GW1 can only advertise itself via tunnel
>> encapsulation attribute and not GW2 as GW2 can only advertise itself when
>> it’s eBGP tie to the core comes Up.  Problem solved.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Fri, May 14, 2021 at 7:02 PM Gyan Mishra 
>> wrote:
>>
>>>
>>> Hi Adrian
>>>
>>> I believe what John is describing is a valid failure scenario where one
>>> of the GWs is no longer a valid gateway because it’s eBGP peering to core
>>> domain is down, however the routing underlay is stable between the GWs
>>> within the DC site. We are assuming the GWs at the site run an IGP to
>>> advertise next hop attribute and maybe also have next hop self configured
>>> between then for iBGP.  So the GW that had eBGP peer to core is able to
>>> send the auto discovery loopback prefix tunnel sub TLV for both GWs.
>>> That’s the problem.
>>>
>>> So that would cause the black hole of traffic between sites for the GW
>>> that has its eBGP link to the core down.
>>>
>>> The other question asked was eve set of internal prefixes how are they
>>> advertised and is that just over the native AFI SAFI iBGP peering between
>>> the GWs.
>>>
>>> So GW1 that is up advertises via iBGP the set of internal prefixes
>>> learned from the other domain.
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Fri, May 14, 2021 at 5:25 PM John Scudder >> 40juniper@dmarc.ietf.org> wrote:
>>>
>>>> Having re-read Section 3 carefully (and skimmed the rest) I still think
>>>> what the document says (as opposed to what’s in the authors’ heads?) is the
>>>> first description I give below. Let me know if you want me to walk through
>>>> my reasoning in detail with reference to the document.
>>>>
>>>> —John
>>>>
>>>> On May 14, 2021, at 4:12 PM, John Scudder  wrote:
>>>>
>>>>  Hi Adrian,
>>>>
>>>>
>>>> Thanks for your reply. Pressed for time at the moment but one partial
>>>> response:
>>>>
>>>

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Adrian & Authors please correct me if I misspeak the way I read the draft.

I did not see in the draft stating explicitly how the internal DC GW routes
are advertised which I believe implicitly done via standard BGP AFI / SAFI
route propagation natively over the SR domain.  So for example if the
internal GW routers are SAFI 1 unicast they are propagated natively global
table routed as SAFI 1 inter domain from ingress to egress DC GW.

For VPN overlay SAFI 128 129 routes are propagated natively as SAFI 128 129
over the SR core.

So all GW internal routes AFI / SAFI are supported meaning SAFI  1, 128,
129.

Kind Regards

Gyan

On Fri, May 14, 2021 at 10:45 PM Gyan Mishra  wrote:

> Hi Adrian
>
> I may have missed this in the draft but the solution for this failover
> scenario is if each GW can only advertise itself, which I think that is
> stated in section 3 then GW1 can only advertise itself via tunnel
> encapsulation attribute and not GW2 as GW2 can only advertise itself when
> it’s eBGP tie to the core comes Up.  Problem solved.
>
> Kind Regards
>
> Gyan
>
> On Fri, May 14, 2021 at 7:02 PM Gyan Mishra  wrote:
>
>>
>> Hi Adrian
>>
>> I believe what John is describing is a valid failure scenario where one
>> of the GWs is no longer a valid gateway because it’s eBGP peering to core
>> domain is down, however the routing underlay is stable between the GWs
>> within the DC site. We are assuming the GWs at the site run an IGP to
>> advertise next hop attribute and maybe also have next hop self configured
>> between then for iBGP.  So the GW that had eBGP peer to core is able to
>> send the auto discovery loopback prefix tunnel sub TLV for both GWs.
>> That’s the problem.
>>
>> So that would cause the black hole of traffic between sites for the GW
>> that has its eBGP link to the core down.
>>
>> The other question asked was eve set of internal prefixes how are they
>> advertised and is that just over the native AFI SAFI iBGP peering between
>> the GWs.
>>
>> So GW1 that is up advertises via iBGP the set of internal prefixes
>> learned from the other domain.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Fri, May 14, 2021 at 5:25 PM John Scudder > 40juniper@dmarc.ietf.org> wrote:
>>
>>> Having re-read Section 3 carefully (and skimmed the rest) I still think
>>> what the document says (as opposed to what’s in the authors’ heads?) is the
>>> first description I give below. Let me know if you want me to walk through
>>> my reasoning in detail with reference to the document.
>>>
>>> —John
>>>
>>> On May 14, 2021, at 4:12 PM, John Scudder  wrote:
>>>
>>>  Hi Adrian,
>>>
>>>
>>> Thanks for your reply. Pressed for time at the moment but one partial
>>> response:
>>>
>>> On May 14, 2021, at 1:04 PM, Adrian Farrel  wrote:
>>>
>>> Agree with you that "stuff happens." I think that what you have
>>> described is a window not a permanent situation.
>>> When GW2 knows it can't reach X any more, it will stop advertising X,
>>> and GW1 will receive that and will update what it advertises on behalf of
>>> GW2.
>>>
>>>
>>> Ah, perhaps I have badly misunderstood the way this works. I had thought
>>> it went something like this:
>>>
>>> - GW1 knows it can reach GW2 because of GW2’s auto discovery route
>>> - GW1 knows the set S of internal prefixes it can reach
>>> - GW1 advertises each prefix from S with both GW1 and GW2 in the tunnel
>>> attribute
>>>
>>> In the description above, there’s no notion of GW2 telling GW1 what
>>> internal prefixes GW2 can reach, or GW1 caring.  Now I suppose you are
>>> telling me that it goes:
>>>
>>> - GW1 knows it can reach GW2 because of GW2’s auto discovery route
>>> - GW1 knows the full set of prefixes GW2 can reach. _How does it know
>>> this?_
>>> - GW1 constructs each advertisement listing only the correct set of
>>> gateways in the tunnel attribute
>>>
>>> The key question is the one I’ve highlighted: how does GW1 come to know
>>> GW2’s internally-reachable prefixes? I didn’t notice any of this in the
>>> spec. Maybe it was just my sloppy reading, I’ll look again.
>>>
>>> Further, if GW1 can no longer receive advertisements from GW2 then it
>>> will stop advertising on behalf of GW2.
>>>
>>>
>>> Yes, that’s understood, but I was positing a case where just because GW1
>>> can reach GW2 stably,