Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Rabadan, Jorge (Nokia - US/Sunnyvale)]

I agree with Vasilenko.

The meaning of the label is given by the encapsulation, e.g. for the EVPN 
family, label=VNI if the bgp encapsulation extended community indicates VXLAN, 
and label=MPLS-label if the encapsulation indicates MPLS.

In this document, the label is a transposed function if the encapsulation 
indicates SRv6 (given by the SRv6 Services TLV). So it is consistent with the 
approach used by SAFIs that support different identifiers in the label field.

Thanks.
Jorge

From: Vasilenko Eduard 
Date: Thursday, February 17, 2022 at 8:30 AM
To: Warren Kumari , Ron Bonica 
Cc: draft-ietf-bess-srv6-services@ietf.org 
, last-c...@ietf.org 
, bess@ietf.org , int-...@ietf.org 

Subject: RE: [bess] [Last-Call] Intdir telechat review of 
draft-ietf-bess-srv6-services-10
Hi all,
About this point:
1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

I have seen in some BESS documents that this field is called “Service Label”, 
not “MPLS label”.
Because MPLS does not exist in VxLAN too, but the same label is used.
Hence, 1) is easy to resolve. It is just a terminology correction that makes 
sense in principle for all BESS documents.
Eduard
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Warren Kumari
Sent: Thursday, February 17, 2022 4:37 AM
To: Ron Bonica 
Cc: draft-ietf-bess-srv6-services@ietf.org; last-c...@ietf.org; 
bess@ietf.org; int-...@ietf.org
Subject: Re: [bess] [Last-Call] Intdir telechat review of 
draft-ietf-bess-srv6-services-10



On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Ron Bonica
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
.

Major issues:

1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

2) In Section 3.2.1 the draft says:

  BGP speakers that do not support this specification may misinterpret,
   on the reception of an SRv6-based BGP service route update, the part
   of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
   for MPLS-based services.  Implementations supporting this
   specification SHOULD provide a mechanism to control the advertisement
   of SRv6-based BGP service routes on a per-neighbor and per-service
   basis.  The details of deployment designs and implementation options
   are outside the scope of this document.

Much thanks to Ron for this OpsDir review -- I'd completely missed the above 
points, and they are important to address.

W


s/BGP speakers that do not support this specification/Legacy BGP implementations

It seems that this isn't backwards compatible unless either:

- the SHOULD becomes a MUST
- the mechanism is described in this document

3) I concur with Warren Kumari's DISCUSS



--
last-call mailing list
last-c...@ietf.org
https://www.ietf.org/mailman/listinfo/last-call


--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Vasilenko Eduard]

Hi all,
About this point:
1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

I have seen in some BESS documents that this field is called “Service Label”, 
not “MPLS label”.
Because MPLS does not exist in VxLAN too, but the same label is used.
Hence, 1) is easy to resolve. It is just a terminology correction that makes 
sense in principle for all BESS documents.
Eduard
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Warren Kumari
Sent: Thursday, February 17, 2022 4:37 AM
To: Ron Bonica 
Cc: draft-ietf-bess-srv6-services@ietf.org; last-c...@ietf.org; 
bess@ietf.org; int-...@ietf.org
Subject: Re: [bess] [Last-Call] Intdir telechat review of 
draft-ietf-bess-srv6-services-10



On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Ron Bonica
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
.

Major issues:

1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

2) In Section 3.2.1 the draft says:

  BGP speakers that do not support this specification may misinterpret,
   on the reception of an SRv6-based BGP service route update, the part
   of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
   for MPLS-based services.  Implementations supporting this
   specification SHOULD provide a mechanism to control the advertisement
   of SRv6-based BGP service routes on a per-neighbor and per-service
   basis.  The details of deployment designs and implementation options
   are outside the scope of this document.

Much thanks to Ron for this OpsDir review -- I'd completely missed the above 
points, and they are important to address.

W


s/BGP speakers that do not support this specification/Legacy BGP implementations

It seems that this isn't backwards compatible unless either:

- the SHOULD becomes a MUST
- the mechanism is described in this document

3) I concur with Warren Kumari's DISCUSS



--
last-call mailing list
last-c...@ietf.org
https://www.ietf.org/mailman/listinfo/last-call


--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Mankamana Mishra (mankamis)]

Thanks john for providing input. New version of draft accommodated all of these 
changes.

Mankamana

From: John E Drake 
Date: Friday, February 11, 2022 at 8:13 AM
To: Mankamana Mishra (mankamis) , Benjamin Kaduk 

Cc: The IESG , draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: RE: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)
Hi,

Here are my proposed changes:

8.
  Selective Multicast Procedures for IR tunnels

   If an ingress PE uses ingress replication, then for a given (x,G)
   group in a given BD:

   1.  It sends (x,G) traffic to the set of PEs not supporting IGMP
   Proxy.  This set consists of any PE that has advertised an
   Inclusive Multicast Tag route for the BD without the "IGMP Proxy
   Support" flag.

*JD  This set consists of any PE that has advertised an IMET route for the 
BD
without a  Multicast Flags extended community or with a Multicast Flags extended
community in which neither the IGMP Proxy support nor the  MLD Proxy support
flags are set.

   2.  It sends (x,G) traffic to the set of PEs supporting IGMP Proxy
   and having listeners for that (x,G) group in that BD.  This set
   consists of any PE that has advertised an Inclusive Multicast Tag
   route for the BD with the "IGMP Proxy Support" flag and that has
   advertised a SMET route for that (x,G) group in that BD.

*JD  This set consists of any PE that has advertised an IMET route for the 
BD
with a Multicast Flags extended community in which the IGMP Proxy support and/or
the  MLD Proxy support flags are set and that has advertised a SMET route for 
that (x,G)
group in that BD.

   If an ingress PE's Selective P-Tunnel for a given BD uses P2MP and
   all of the PEs in the BD support that tunnel type and IGMP proxy,

*JD and IGMP and/or MLD proxy,

   then for a given (x,G) group in a given BD it sends (x,G) traffic
   using the Selective P-Tunnel for that (x,G) group in that BD.  This
   tunnel includes those PEs that have advertised a SMET route for that
   (x,G) group on that BD (for Selective P-tunnel) but it may include
   other PEs as well (for Aggregate Selective P-tunnel).

9.4.
  Multicast Flags Extended Community

   The 'Multicast Flags' extended community is a new EVPN extended
   community.  EVPN extended communities are transitive extended
   communities with a Type field value of 6.  IANA will assign a Sub-
   Type from the 'EVPN Extended Community Sub-Types' registry.

   A PE that supports IGMP proxy on a given BD MUST attach this extended
   community to the Inclusive Multicast Ethernet Tag (IMET) route it
   advertises for that BD and it MUST set the IGMP Proxy Support flag to
   1.  Note that an [RFC7432] 
compliant PE will not advertise this
   extended community so its absence indicates that the advertising PE
   does not support IGMP Proxy.

*JD A PE that supports IGMP and/or MLD Proxy on a given BD
MUST attach this extended community to the IMET route it advertises
advertises for that BD and it MUST set the IGMP and/or MLD Proxy
Support flags to 1.  Note that an 
[RFC7432] compliant PE will not 
advertise this
extended community so its absence indicates that the advertising PE
does not support either IGMP or MLD Proxy.


Yours Irrespectively,

John



Juniper Business Use Only
From: Mankamana Mishra (mankamis) 
Sent: Friday, February 11, 2022 11:02 AM
To: John E Drake ; Benjamin Kaduk 
Cc: The IESG ; draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; 
bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com
Subject: Re: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Hi Ben,
Making the changes as you suggested. Attached diff which I would be pushing 
today.

One question

> §8 now talks about an "IGMP or MLD Proxy Support" flag, but we actually have
> separate "IGMP Proxy Support" and "MLD Proxy Support" flags.

Does IGMP or MLD Proxy Support not mean that either of them can be set / unset. 
Any thing specific you want to be added here ?

Mankamana

From: John E Drake mailto:jdr...@juniper.net>>
Date: Monday, February 7, 2022 at 7:17 AM
To: Benjamin Kaduk mailto:ka...@mit.edu>>
Cc: The IESG mailto:i...@ietf.org>>, 
draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org
 
mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
slitkows.i...@gmail.com 

[bess] I-D Action: draft-ietf-bess-evpn-igmp-mld-proxy-18.txt

[internet-drafts]

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   : IGMP and MLD Proxy for EVPN
Authors : Ali Sajassi
  Samir Thoria
  Mankamana Mishra
  John Drake
  Wen Lin
Filename: draft-ietf-bess-evpn-igmp-mld-proxy-18.txt
Pages   : 36
Date: 2022-02-16

Abstract:
   This document describes how to support efficiently endpoints running
   IGMP(Internet Group Management Protocol) or MLD (Multicast Listener
   Discovery) for the multicast services over an EVPN network by
   incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-igmp-mld-proxy-18


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


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

[liu.yao71]

Hi,
Ron and John both mentioned that leveraging the existing AFI/SAFI may cause 
misunderstanding of the SRv6 service routes.
We encountered this problem during implementation and submitted a draft talking 
about this.
https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02
One solution(if new AFI/SAFI is not defined) we proposed in the draft is to 
define a new BGP capability code for for SRv6-based BGP service capability, and 
then SRv6 service routes would only be exchanged between devices that support 
it based on this capability.
Do you think this is a possible solution?

Regards,
Yao

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

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

[Mankamana Mishra (mankamis)]

Hi Eric,
Thanks, uploaded the new version addressing your comment.

Pending:

  1.  About number restarting – There was comment by Alvaro where he wanted 
these numbers to be restarting to differentiate sender and receiver processing
EV> I am sure that Alvaro will not mind have some text, even just 4 words, 
separating the sender / receiver processing

MM : It was not my day to get this logic work in XML. Will figure out some 
expert to enter section there to articulate two different sub topic (sender 
side processing and receiving side processing )

Rest other comment have been addressed.

Mankamana


From: Eric Vyncke (evyncke) 
Date: Friday, February 11, 2022 at 5:39 AM
To: Mankamana Mishra (mankamis) , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)
Hello Mankamana,

Thanks for your reply, see below for EV> (I have elided the original DISCUSS 
part). As soon as a revised I-D is uploaded, then I am clearing my DISCUSS.

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 11 February 2022 at 00:33
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hi Eric,
Thanks for comment.


  1.  For text which talks about how to decode BGP routes back , will it be ok 
to have common section after BPG encoding 
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9)
 ? which talks about fact that receiving PE need to decode it back and consider 
it as IGMP membership request and process it ?
EV> adding sections 9.1.3 / 9.2.3 / 9.3.3 "reconstructing the MLD/IGMP" per 
route type would be preferred of course, but a common subsection on 
reconstruction either after 9.3 (preferred) or after 9.1 would be OK (in the 
sense that it addresses my DISCUSS but is less easy for the 
readers/implementers)


  1.  About number restarting – There was comment by Alvaro where he wanted 
these numbers to be restarting to differentiate sender and receiver processing
EV> I am sure that Alvaro will not mind have some text, even just 4 words, 
separating the sender / receiver processing


  1.  SMET, I would take care of it in terminology.
EV> thanks


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

[bess] I-D Action: draft-ietf-bess-evpn-igmp-mld-proxy-17.txt

[internet-drafts]

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   : IGMP and MLD Proxy for EVPN
Authors : Ali Sajassi
  Samir Thoria
  Mankamana Mishra
  John Drake
  Wen Lin
Filename: draft-ietf-bess-evpn-igmp-mld-proxy-17.txt
Pages   : 35
Date: 2022-02-16

Abstract:
   This document describes how to support efficiently endpoints running
   IGMP(Internet Group Management Protocol) or MLD (Multicast Listener
   Discovery) for the multicast services over an EVPN network by
   incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-igmp-mld-proxy-17


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


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

[liu.yao71]

Hi,


Ron and John both mentioned that leveraging the existing AFI/SAFI may cause 
misunderstanding of the SRv6 service routes.

We encountered this problem during implementation and submitted a draft talking 
about this.

https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02

One solution(if new AFI/SAFI is not defined) we proposed in the draft is to 
define a new BGP capability code for for SRv6-based BGP service capability, and 
then SRv6 service routes would only be exchanged between devices that support 
it based on this capability.

Do you think this is a possible solution?




Regards,

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

[bess] Murray Kucherawy's No Objection on draft-ietf-bess-srv6-services-11: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-srv6-services-11: No Objection

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/



--
COMMENT:
--

Just to double-check: Are we okay with having seven authors on this document
when the guidelines specify a limit of five?



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

[bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Erik Kline via Datatracker]

Erik Kline has entered the following ballot position for
draft-ietf-bess-srv6-services-11: 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:
--

I have little to add to the DISCUSSes held by others beyond my support.

However, I would like to discuss having SRv6 control plane information, i.e.
SIDs and their behaviours etc., being isolated by associating it with
a separate SAFI.  Any other protocol element that needs to refer to such
information can make reference to it through context-appropriate extensions.

{AFI=IPv6, SAFI=unicast} is a valid way to advertise an SRv6 locator prefix,
for example, as that's just IPv6 forwarding information.  If SRv6-specific
information where separately advertised as {AFI=IPv6, SAFI=SRv6} then I
suspect it would be simpler to filter out that information, detect leaks,
and generally help the SRv6 domain fail closed more easily.

But I'm prepared to learn why this wouldn't work or would be somehow worse.





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

Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Warren Kumari]

On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Ron Bonica
> Review result: Not Ready
>
> I am an assigned INT directorate reviewer for
> draft-ietf-bess-srv6-services.txt.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> .
>
> Major issues:
>
> 1) In Section 3.2.1, the draft transposes bits into the MPLS Label field.
> This
> is surprising because MPLS appears nowhere in the forwarding plane. Maybe
> we
> shouldn't advertise an MPLS label?
>
> 2) In Section 3.2.1 the draft says:
>
>   BGP speakers that do not support this specification may misinterpret,
>on the reception of an SRv6-based BGP service route update, the part
>of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
>for MPLS-based services.  Implementations supporting this
>specification SHOULD provide a mechanism to control the advertisement
>of SRv6-based BGP service routes on a per-neighbor and per-service
>basis.  The details of deployment designs and implementation options
>are outside the scope of this document.
>
>
Much thanks to Ron for this OpsDir review -- I'd completely missed the
above points, and they are important to address.

W



> s/BGP speakers that do not support this specification/Legacy BGP
> implementations
>
> It seems that this isn't backwards compatible unless either:
>
> - the SHOULD becomes a MUST
> - the mechanism is described in this document
>
> 3) I concur with Warren Kumari's DISCUSS
>
>
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
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.
>
>
>
> 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:
>
> 

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

[Robert Raszuk]

Hi John,

As you have quoted my note in point #4 I feel that I need to comment on it.

So yes original discussions and major contributions of this work were
focusing on VPN use case and I admit when carefully re- reading it to find
some text there beyond VPN use case.

So we discussed it among co-authors. The point of adding 5.3 & 5.4 is
targeting the networks where Internet routes are not present at each node
and network uses summarization of infrastructure routes (no end to end /128
leaking in the IGP).

The text perhaps may require some clarification that use of SAFI 1 is left
for the operators to choose if the attribute should be attached to Internet
routes - when operator is offering an IP transit or it can be attached just
to next hops which are part of the infrastructure. Let's also not forget
that if this is IP transit in most networks you can reach all hops along
the path anyway (modulo transit SP/ISP policy).

I think major concern expressed from Warren was the potential compromise to
the VPNs when SID demuxing it would leak. Well as we know SAFI 128 or 70
are not public. Yes customer may advertise his routes to SAFI 1 and leak
but no one has control over it and it is orthogonal to what happens in the
SP network.

With that I think that #3 and #4 are no longer a concern.

Best regards,
Robert


On Wed, Feb 16, 2022 at 10:39 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-bess-srv6-services-11: 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:
> --
>
> 1. The shepherd writeup for this document says “It also received an RTG DIR
> review and cross-reviewed with the IDR working group”. Searching in my IDR
> inbox and the IDR mailing list archives, I don’t find any sign of the
> cross-review — can you please point me to it?
>
> 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.)
>
> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
> discussion turned quickly to the assertion that no, they don’t, in VPN
> address
> families. Let’s accept that claim for the sake of conversation. It’s still
> the
> case that sometimes (often?) routes are distributed from VPN address
> families
> into the Global Internet table. When this is done, by default, all the path
> attributes come along for the ride. Anyone who thinks this is just a
> hypothetical case might want to look back to (for example) significant
> network
> outages that were caused around a decade ago by leakage of BGP Attribute
> 128
> (ATTR_SET, RFC 6368) into the global Internet.
>
> The SIDs contained in these if-they-were-to-leak routes potentially give an
> attacker a means of directing packets into a VPN customer’s internal
> network.
>
> 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid
> [WG]
> consensus”; however, there doesn’t seem to be consensus even amongst the
> authors as to whether Sections 5.3 and 5.4 are appropriate. This is a
> fairly
> fundamental disagreement! An illustration of the disagreement is
> https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:
>
> “So I can see why some people may have thought oh since transport in SRv6
> comes
> for free let's load it with services in an attribute and be done. Yes I
> can see
> that flattening this make it potentially easier (one less SAFI to enable),
> *but
> I am not sure we have reached a broad agreement here.* This comes as a
> consequence of moving service prefixes from MP_REACH_NLRI (perhaps new
> format
> and new SAFI) to an attribute.”
>
> (Emphasis added.)
>
> It's of course possible for 

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

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-bess-srv6-services-11: 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:
--

1. The shepherd writeup for this document says “It also received an RTG DIR
review and cross-reviewed with the IDR working group”. Searching in my IDR
inbox and the IDR mailing list archives, I don’t find any sign of the
cross-review — can you please point me to it?

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

3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
discussion turned quickly to the assertion that no, they don’t, in VPN address
families. Let’s accept that claim for the sake of conversation. It’s still the
case that sometimes (often?) routes are distributed from VPN address families
into the Global Internet table. When this is done, by default, all the path
attributes come along for the ride. Anyone who thinks this is just a
hypothetical case might want to look back to (for example) significant network
outages that were caused around a decade ago by leakage of BGP Attribute 128
(ATTR_SET, RFC 6368) into the global Internet.

The SIDs contained in these if-they-were-to-leak routes potentially give an
attacker a means of directing packets into a VPN customer’s internal network.

4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG]
consensus”; however, there doesn’t seem to be consensus even amongst the
authors as to whether Sections 5.3 and 5.4 are appropriate. This is a fairly
fundamental disagreement! An illustration of the disagreement is
https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:

“So I can see why some people may have thought oh since transport in SRv6 comes
for free let's load it with services in an attribute and be done. Yes I can see
that flattening this make it potentially easier (one less SAFI to enable), *but
I am not sure we have reached a broad agreement here.* This comes as a
consequence of moving service prefixes from MP_REACH_NLRI (perhaps new format
and new SAFI) to an attribute.”

(Emphasis added.)

It's of course possible for an author to be in the rough as regards consensus,
just as any other WG contributor, but it's a little unusual, and this
disagreement doesn't even seem to have been previously aired. For this reason,
I have to question the strength of the consensus behind this document, and ask
the WG chairs to weigh in regarding whether consensus on at least this point
needs to be checked before we proceed forward.

5. Finally, I have to question the length of the author list. As I’m sure you
know, the guidance is to limit author lists to no more than five, other than
under unusual circumstances. I would have expected to find an explanation of
the circumstances around the author list of this document in the shepherd
writeup; there is none. (It’s a specific check item in Guidelines to Authors of
Internet-Drafts, https://www.ietf.org/how/ids/guidelines/)

The easiest way to resolve this would be to trim the author list per the
suggestions in RFC 7322 §4.1.1, of course.


--
COMMENT:
--

1. I support Warren Kumari’s DISCUSS.

2. (Further comments TBD and I apologize for not providing them now; I wanted
to get this sent off though.)



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

Re: [bess] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Ron Bonica]

Ketan,

Mislabeling attributes is not only sloppy, but it can be dangerous. The danger 
is that somebody might read the label and believe it. Or conversely, that our 
labels will become meaningless, even when they are correct, because people 
learn that things are so frequently mislabeled.

Wouldn't we be better off with a new AFI/SAFI?

Ron



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Tuesday, February 15, 2022 3:49 AM
To: Ron Bonica 
Cc: int-...@ietf.org; BESS ; 
draft-ietf-bess-srv6-services@ietf.org; last-c...@ietf.org
Subject: Re: Intdir telechat review of draft-ietf-bess-srv6-services-10

[External Email. Be cautious of content]

Hi Ron,

Thanks for your review and please check inline below for responses.


On Mon, Feb 14, 2022 at 10:49 PM Ron Bonica via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Ron Bonica
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
>.

Major issues:

1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

KT> You are correct that there are no MPLS labels used in the forwarding. The 
label fields are part of the BGP NLRI Encoding and not something introduced 
newly. The transposition scheme leverages them for encoding efficiency and 
better packing of BGP updates.


2) In Section 3.2.1 the draft says:

  BGP speakers that do not support this specification may misinterpret,
   on the reception of an SRv6-based BGP service route update, the part
   of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
   for MPLS-based services.  Implementations supporting this
   specification SHOULD provide a mechanism to control the advertisement
   of SRv6-based BGP service routes on a per-neighbor and per-service
   basis.  The details of deployment designs and implementation options
   are outside the scope of this document.

s/BGP speakers that do not support this specification/Legacy BGP implementations

KT> I am, personally, not in favor of using the term "legacy" in this case.


It seems that this isn't backwards compatible unless either:

- the SHOULD becomes a MUST
- the mechanism is described in this document

KT> Ack. We can change the SHOULD to MUST.

Thanks,
Ketan


3) I concur with Warren Kumari's DISCUSS

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

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

[Ketan Talaulikar]

Hi Alvaro,

Thanks for your detailed review and comments. Please check inline below for
responses.

We have also posted an update for the draft to address comments from you
and other reviewers:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-11


On Tue, Feb 15, 2022 at 11:29 PM Alvaro Retana via Datatracker <
nore...@ietf.org> wrote:

> Alvaro Retana 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:
> --
>
> I am balloting DISCUSS because the document underspecifies the use of
> Endpoint
> Behaviors. As a result, it is unclear when they should be checked,
> enforced,
> or needed. Details follow.
>
>
> The descriptions of the TLVs in §2 say (twice) that the "SRv6 Endpoint
> behaviors which MAY be encoded, but not limited to, are...etc."
>
>The text above ends with "etc." which means there are other possible
>behaviors. That's not a great use of normative language, even if
> optional.
>

KT> Agree. We have removed the "etc".


>My initial instinct was to ask you to be specific, BUT...
>
>The description of the SRv6 SID Information Sub-TLV (§3.1) says that "an
>unrecognized endpoint behavior MUST NOT be considered invalid", which
> seems
>to mean that any behavior is ok, AND...
>
>There's no validation specified, except for the description of the SRv6
> SID
>Structure Sub-Sub-TLV (§3.2.1), where it says that the "Argument length
>MUST be set to 0 for SIDs where the Argument is not applicable". AND...
>
>Several of the service descriptions in §5/§6 say that "The SRv6 Endpoint
>behavior of the SRv6 SID is entirely up to the originator of the
>advertisement. In practice, the SRv6 Endpoint behavior is..."
>
>
> The result is that any endpoint behavior (even unrecognized) can be used,
> while also requiring a specific setting for the argument length in some
> cases.
>
> How can the argument length be validated if the endpoint behavior is
> unknown?
>

KT> The argument length cannot be validated unless the endpoint behavior is
known. The ingress PE needs to actually write the ARG part of the SID into
the SRv6 SID advertised by the egress PE when sending packets for that
service to the egress PE. Therefore, knowing that the behavior involves
argument and validating the argument length is important. We have clarified
this in the text.


>
> Clearly (from looking at rfc8986), not all endpoint behaviors apply to the
> services defined in this document. Should a receiver accept any endpoint
> behavior? What should a receiver do if a known but unrelated behavior (End,
> for example) is received?
>
> What should the receiver do if the endpoint behavior is known and
> applicable,
> but the attribute length is not set correctly?
>

KT> Could you clarify which attribute length you are referring to?


>
> For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick
> one),
> should the behaviors used "in practice" be enforced? What if different
> behavior
> is advertised? Can it safely be ignored?
>
> Why is the Endpoint Behavior included in the Sub-TLV if (from the above) it
> looks like it doesn't matter?
>

KT> The endpoint behavior is something that is associated with the SID
instantiated on the Egress PE. In most cases for VPN services, the ingress
PE simply needs to use the SID to send the packet to the egress PE. This is
much like how a context/instruction is associated with the VPN label for
MPLS - it could be per-vrf or per-ce or per-prefix - normally the ingress
PE does not care. However, with SRv6, we have behaviors that have arguments
that do require the ingress PE to be aware since it needs to set up the ARG
part of the SID in the packet encapsulation. In certain other cases, the
knowledge of the behavior on the ingress PE could enable local optimization
which we do want to preclude. Having the ability to signal the SRv6
Endpoint behavior also helps in troubleshooting and monitoring.


>
>
> --
> COMMENT:
> --
>
> (1) To make sure, the new "BGP SRv6 Service SID Flags" registry is
> intended to document the allocations for the "SRv6 SID Flags" field in the
> SRv6 SID Information Sub-TLV (§3.1), right?
>

KT> Correct.


>
> Please say so 

[bess] I-D Action: draft-ietf-bess-srv6-services-11.txt

[internet-drafts]

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   : SRv6 BGP based Overlay Services
Authors : Gaurav Dawra
  Clarence Filsfils
  Ketan Talaulikar
  Robert Raszuk
  Bruno Decraene
  Shunwan Zhuang
  Jorge Rabadan
Filename: draft-ietf-bess-srv6-services-11.txt
Pages   : 33
Date: 2022-02-16

Abstract:
   This document defines procedures and messages for SRv6-based BGP
   services including L3VPN, EVPN, and Internet services.  It builds on
   RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
   "BGP MPLS-Based Ethernet VPN".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-11


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


___
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

[Rabadan, Jorge (Nokia - US/Sunnyvale)]

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 
, 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 
mailto:hayabusa...@gmail.com>> wrote:

I support publication.

Thanks

Gyan

On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) 
mailto:jorge.raba...@nokia.com>> wrote:
Thank you Anoop. We will fix those in the next version.
Jorge

From: Anoop Ghanwani mailto:an...@alumni.duke.edu>>
Date: Saturday, February 5, 2022 at 12:19 AM
To: slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>
Cc: BESS mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-mh-split-hori...@ietf.org
 
mailto:draft-ietf-bess-evpn-mh-split-hori...@ietf.org>>,
 bess-cha...@ietf.org 
mailto: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 
mailto:slitkows.i...@gmail.com>> 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 

Re: [bess] Submitting comments against draft-ietf-bess-rfc7432bis-02

[Luc André Burdet]

Thanks Marek.
I will go through them and just reply on-thread (here) with any questions or 
clarifications.

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: Marek Hajduczenia 
Date: Wednesday, February 16, 2022 at 10:17
To: 'Luc André Burdet' , bess@ietf.org 
, draft-ietf-bess-rfc7432...@ietf.org 

Subject: RE: [bess] Submitting comments against draft-ietf-bess-rfc7432bis-02
Thank you, Luc André

CCing the dedicated distro for this document.

Attached please find the document with comments (92 in total). A large share 
are editorial (I hope these are self-explanatory), but there are also a number 
of technical questions / comments. Is there any interactive comment resolution 
process planned for this document at any point of time?

Regards

Marek

From: Luc André Burdet 
Sent: Wednesday, February 16, 2022 8:10 AM
To: mxhajducze...@gmail.com; bess@ietf.org
Subject: Re: [bess] Submitting comments against draft-ietf-bess-rfc7432bis-02

Hi Marek,

You can just submit them to the alias, or to the authors 
(draft-ietf-bess-rfc7432...@ietf.org).
(In tracker there are 2 links for ‘Email authors’ and ‘Email WG’)

I am preparing an up-revision soon so your comments are welcome and timely (PDF 
is fine)

Regards,
Luc André

Luc André Burdet |  Cisco  |  
laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
mxhajducze...@gmail.com 
mailto:mxhajducze...@gmail.com>>
Date: Tuesday, February 15, 2022 at 12:04
To: bess@ietf.org mailto:bess@ietf.org>>
Subject: [bess] Submitting comments against draft-ietf-bess-rfc7432bis-02
Hi,

I have a generic question about submitting comments against 
draft-ietf-bess-rfc7432bis-02. I read the document in detail and marked up a 
number of comments / suggestions in the PDF document. Is there any formal 
process to submit these comments and have them reviewed?

I am new to the IETF process, hence the question

Thanks

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

Re: [bess] Submitting comments against draft-ietf-bess-rfc7432bis-02

[Luc André Burdet]

Hi Marek,

You can just submit them to the alias, or to the authors 
(draft-ietf-bess-rfc7432...@ietf.org).
(In tracker there are 2 links for ‘Email authors’ and ‘Email WG’)

I am preparing an up-revision soon so your comments are welcome and timely (PDF 
is fine)

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: BESS  on behalf of mxhajducze...@gmail.com 

Date: Tuesday, February 15, 2022 at 12:04
To: bess@ietf.org 
Subject: [bess] Submitting comments against draft-ietf-bess-rfc7432bis-02
Hi,

I have a generic question about submitting comments against 
draft-ietf-bess-rfc7432bis-02. I read the document in detail and marked up a 
number of comments / suggestions in the PDF document. Is there any formal 
process to submit these comments and have them reviewed?

I am new to the IETF process, hence the question

Thanks

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

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-srv6-services-10: (with COMMENT)

[Ketan Talaulikar]

Hi Roman,

Thanks for your review. Please check inline for a response to your proposed
text change.


On Wed, Feb 16, 2022 at 8:47 AM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-bess-srv6-services-10: No Objection
>
> 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/
>
>
>
> --
> COMMENT:
> --
>
> Thank you to Joseph Salowey for the SECDIR review.
>
> Thank you to the authors for the implementation report pointer
> (draft-matsushima-spring-srv6-deployment-status)
>
> I support Alvaro Retana’s DISCUSS position.
>
> I also support Warren Kumari’s DISCUSS position.  In particular,
> discussing the
> magnitude of the exposure of an internal topology due to a BGP leak would
> be
> helpful to document.
>
> ** Section 8.  It would be worth repeating the two key security assumptions
> from RFC8402:
>
> OLD
> SRv6 operates within a trusted SR domain with filtering of traffic at
>the domain boundaries.
>
> NEW
> SRv6 operates within a trusted SR domain with filtering of traffic at the
> domain boundaries. Likewise, there is an assumed trust model such that any
> node
> adding an SRH to the packet is assumed to be allowed to do so.
>
>
KT> I agree. I think it would be good to also qualify the newly inserted
sentence with the option of using the SRH HMAC TLV (where verification is
required) that was introduced by RFC8754.

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

Re: [bess] [EXTERNAL] EVPN service carving with ingress VLAN translation

[Muthu Arul Mozhi Perumal]

Hi Sasha,

Thanks for your response. I agree, using a manually configured ID is the
best option when VID translation is performed at one or more ingress PEs
that are part of the multi-homed group to obtain a predictable default DF
election result..

That said, the current situation is, different vendors seem to use
different VIDs for DF election when VID translation is performed at the
ingress PE; some seem to use the translated VID and some even the BGP
router ID when the translation rule removes the tag entirely (making it
untagged) without proving a configurable ID..

How about adding some text to rfc7432bis section 6?


   An Ethernet Tag ID is a 32-bit field containing either a 12-bit or
   24-bit identifier that identifies a particular broadcast domain
   (e.g., a VLAN) in an EVPN instance.  The 12-bit identifier is called
   the VLAN ID (VID).  An EVPN instance consists of one or more
   broadcast domains (one or more VLANs).  VLANs are assigned to a given
   EVPN instance by the provider of the EVPN service.  A given VLAN can
   itself be represented by multiple VIDs.  In such cases, the PEs
   participating in that VLAN for a given EVPN instance are responsible
   for performing VLAN ID translation to/from locally attached CE
   devices.



   An Ethernet Tag ID is a 32-bit field containing either a 12-bit or
   24-bit identifier that identifies a particular broadcast domain
   (e.g., a VLAN) in an EVPN instance.  The 12-bit identifier is called
   the VLAN ID (VID).  An EVPN instance consists of one or more
   broadcast domains (one or more VLANs).  VLANs are assigned to a given
   EVPN instance by the provider of the EVPN service.  A given VLAN can
   itself be represented by multiple VIDs.  In such cases, the PEs
   participating in that VLAN for a given EVPN instance are responsible
   for performing VLAN ID translation to/from locally attached CE
   devices.


*If a PE performs VID translation of frames received from   locally
attached CE (including removing all tags making it untagged),   the PE
SHOULD provide a configurable ID for the EVPN instance for   the purpose of
DF election.*


Regards,
Muthu

On Tue, Feb 15, 2022 at 6:53 PM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> Muthu,
>
> Quoting from Section 3 of 7432bis
> 
> :
>
>
>
>Ethernet Tag:  Used to represent a BD that is configured on a given
>
>   ES for the purposes of DF election and  identification
>
>   for frames received from the CE.  Note that any of the following
>
>   may be used to represent a BD: VIDs (including Q-in-Q tags),
>
>   configured IDs, VNIs (Virtual Extensible Local Area Network
>
>   (VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service
>
>   Instance Identifiers), etc., as long as the representation of the
>
>   BDs is configured consistently across the multihomed PEs attached
>
>   to that ES.
>
>
>
> As I see it, using manually configured IDs can address your concerns.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@rbbn.com
>
>
>
> *From:* BESS  *On Behalf Of * Muthu Arul Mozhi
> Perumal
> *Sent:* Tuesday, February 15, 2022 1:23 PM
> *To:* bess@ietf.org
> *Subject:* [EXTERNAL] [bess] EVPN service carving with ingress VLAN
> translation
>
>
>
> Hi,
>
>
>
> Though rfc7432bis recommends VLAN translation to be performed at the
> disposition PE (for VLAN-based and VLAN-aware bundle services), I believe
> there are existing deployments where VLAN translation is performed at the
> ingress PE. In this scenario, is there any guideline on whether service
> carving is to be performed based on the original VLAN or translated VLAN?
>
>
>
> I think this cannot be left implementation specific, since DF election is
> a distributed algorithm and should yield the same result in all PEs that
> are part of the multi-homed group.
>
>
>
> Any feedback would be helpful..
>
>
>
> Regards,
>
> Muthu
>
>
> 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,
>