Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Thu, Feb 17, 2022 at 07:01:35AM +, Mankamana Mishra (mankamis) wrote:
> Thanks john for providing input. New version of draft accommodated all of 
> these changes.

Thanks John, thanks Mankamana.

I have balloted No Objection on the -18.

-Ben

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

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

[Satya Mohanty (satyamoh)]

Sorry, I am delayed on this.

Few minutes back I resubmitted this draft as “draft-ietf-bess-ebgp-dmz” to 
replace “draft-mohanty-bess-ebgp-dmz” as instructed by Matthew below.
Now it shows submission is pending approval by group chairs.

Thanks,
Satya


From: Arie Vayner 
Date: Wednesday, February 23, 2022 at 1:54 PM
To: Satya Mohanty (satyamoh) 
Cc: Bocci, Matthew (Nokia - GB) , Ajay Kini 
, Akshay Gattani , bess@ietf.org 
, Lukas Krattiger (lkrattig) , 
draft-mohanty-bess-ebgp-...@ietf.org 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Pinging the thread as it's been quiet since Dec '21.

Tnx
Arie

On Thu, Dec 9, 2021 at 1:10 PM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi Matthew,

Thanks for your comments.
We will republish this draft as draft-ietf-bess-ebgp-dmz-00 shortly.

Best Regards,
--Satya

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Thursday, December 9, 2021 at 5:36 AM
To: Ajay Kini mailto:ajk...@arista.com>>
Cc: Akshay Gattani mailto:aks...@arista.com>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Lukas Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
draft-mohanty-bess-ebgp-...@ietf.org
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Thanks Ajay

There is consensus to adopt this draft as a BESS WG draft.

Authors: Please republish the draft as draft-ietf-bess-ebgp-dmz-00.

Best regards

Matthew

From: Ajay Kini mailto:ajk...@arista.com>>
Date: Thursday, 9 December 2021 at 13:21
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Cc: Akshay Gattani mailto:aks...@arista.com>>, Lukas 
Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
draft-mohanty-bess-ebgp-...@ietf.org
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Hi Matthew,

I am not aware of any relevant undisclosed IPRs that apply to this draft.

Thanks
Ajay
On Thu, Dec 9, 2021, 4:55 AM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:
Ashkay,

Thank you for your response.

Strictly, I need a response from each individual author, otherwise I will have 
to ask the WG if they are happy to proceed.

Ajay, please can you confirm whether or not you are aware of any undisclosed 
IPR?

Thanks

Matthew

From: Akshay Gattani mailto:aks...@arista.com>>
Date: Friday, 3 December 2021 at 08:10
To: Ajay Kini mailto:ajk...@arista.com>>
Cc: Lukas Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
draft-mohanty-bess-ebgp-...@ietf.org
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
To our knowledge, the authors from Arista are not aware of any relevant 
undisclosed IPRs that apply to this draft document.

Thank you

On Wed, Sep 22, 2021 at 3:04 AM Ajay Kini 
mailto:ajk...@arista.com>> wrote:
I support adoption of this draft as a co-author.

On Tue, Sep 21, 2021 at 2:10 PM Akshay Gattani 
mailto:aks...@arista.com>> wrote:
I fully support adoption of this draft as a co-author.

On Mon, Sep 20, 2021 at 8:27 PM Lukas Krattiger (lkrattig) 
mailto:lkrat...@cisco.com>> wrote:
Good Day,
I fully support the adoption of this draft
Kind Regards
-Lukas

On Sep 7, 2021, at 5:41 AM, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:

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

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

[Robert Raszuk]

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 really not a BESS WG problem.

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 */.

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.

The natural alternative would be to never modify NLRI format once shipped
by RFC. When needed issue a new SAFI. Yes that is an option (and has always
been) but it also comes with its own set of issues. New SAFI is really
great to define for new service/feature etc ... Here however in the context
of this discussion we are changing transport for existing service.  And
just like it was the case with MPLS over UDP or  tunnel attribute etc ...
using a new SAFI would be very hard to deploy as there would need to be
well defined behaviour of BGP speakers receiving duplicate information for
the same VPN prefixes or receiving at one time only from single SAFI then a
bit later from the other one .. Of course one solution is to permit only
one SAFI for a given service at any given time, but that seems way too
restrictive too.

So to summarize while I am personally a huge proponent of new SAFI and new
capabilities to be defines for new service here I do have  some
reservations. It seems to me that deployment of new transport for VPN
service should be either network management driven or enabled when all
participating PEs support it. Enabling it automagically with one hop
capabilities seems to me like not a good thing as the data being sent in
the UPDATES is not optional and dropping it means dropping actual routes.

So at the current time the subject draft took a management approach.

Many thx,
Robert.

On Thu, Feb 24, 2022 at 2:04 AM John Scudder  wrote:

> Further to this point:
>
> > On Feb 18, 2022, at 3:32 PM, John Scudder  wrote:
> >
> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar 
> wrote:
> >>
> >>> 2. One area of concern I would have hoped IDR might have looked into
> is, the
> >>> document makes a creative use of the MPLS Label field of the NLRI to
> carry the
> >>> Function part of the SID. This means the SID is effectively split
> across the
> >>> NLRI and the Prefix-SID attribute. What are the potential error modes
> if the
> >>> Prefix-SID attribute should be lost from the route, while the NLRI is
> retained?
> >>>
> >>> (An obvious way of addressing this particular concern would be to
> define a new
> >>> NLRI type with the desired semantics, instead of creatively
> repurposing fields
> >>> within an existing NLRI type contrary to their definitions. Such an
> NLRI type
> >>> would, for example, presumably state in its specification that if it
> was
> >>> received without an accompanying Prefix-SID attribute, that would
> constitute an
> >>> error.)
> >>>
> >> KT> This document follows the approach similar as taken for extending
> MPLS EVPN RFC7432 by RFC8365.
> >
> > I take it you’re referring to RFC 8365 §5.1.3 which talks about using
> the MPLS Label field (or MPLS1 Label field) to carry the VNI in the
> presence of a BGP Encapsulation Extended Community? Yes, that seems like a
> pretty close analogue. And given this particular trick is only with
> VPN-type address families one can also argue that there’s not a risk of
> affected routes leaking into the big-I Internet, which is the typical
> associated concern.
>
> In a separate reply, the authors of
> draft-lz-bess-srv6-service-capability-02 pointed out that it provides a
> critique of bess-srv6-services which is similar to this discuss point. (The
> authors dropped the IESG from the cc, so I’m following up here instead of
> to their original note.)
>
> On first reading, the critique in draft-lz-bess-srv6-service-capability-02
> seems well argued and responsive to my question above about potential error
> modes. In section 3 of their draft, the authors provide a worked scenario
> where a VPN route carrying a SRv6 service SID using the Transposition
> scheme, if received by an MPLS-only PE, could result in