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

[Wen Lin]

As co-author, I support this draft.  I am unaware of any IPR related to this 
draft



Thanks,

Wen




Juniper Business Use Only


From: slitkows.i...@gmail.com 


Date: Wednesday, January 26, 2022 at 1:50 AM

To: bess@ietf.org 
, 
draft-ietf-bess-evpn-mh-split-hori...@ietf.org
 


Cc: bess-cha...@ietf.org 


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

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

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

Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-07

[Jeffrey (Zhaohui) Zhang]

Hi Jorge,

Thanks for the revision. I will start the adoption process.

A couple of further questions below. I snipped text for clarity.

---
4.1.2.  IP A-D per ES route and SRv6 Transport

   When an SRv6 transport is used, each IP A-D per ES route MUST carry
   an SRv6 L3 Service TLV within the BGP Prefix-SID attribute [RFC9252].
   The Service SID MUST be of value 0.  The SRv6 Endpoint Behavior
   SHOULD be one of these End.DT46, End.DT4, End.DT6, End.DX4, or
   End.DX6.

What is the purpose of the above?
[Jorge] A-D per ES routes carry a BGP encapsulation extended community in case 
of VXLAN, MPLS, etc, and an SRv6 Service TLV in case of SRv6, as also described 
in draft-trr-bess-bgp-srv6-args.

Zhz> It's good to clarify that (like what you did for 4.1.3).

---

4.3.  Handling Silent Host MAC/IP route for IP Aliasing
   ...
   Thus to avoid blackholing, when PE2 detects loss of reachability to
   PE1, it should trigger ARP/ND requests for all remote IP prefixes
   received from PE1 across all affected IP-VRFs.  This will force host
   H1 to reply to the solicited ARP/ND messages from PE2 and refresh
   both MAC and IP for the corresponding host in its tables.

This section talks about the silent host MAC/IP route. I suppose there is no 
similar mechanism for Section 4.2 if a single routing session from the CE to 
one of the PEs?
[Jorge] 4.2 talks about the synchronization of the ip routes on the PEs 
attached to the same ES, and 4.3 about the synch of the ARP/ND entries on the 
PEs. Unless a use case is explicitly mentioned, the sections from 2. on are 
relevant to all use cases - 1.1, 1.2 and 1.3. I added a sentence at the end of 
section 2.

Zzh> What I meant was, if the routes that PE1 learns are from a single routing 
session (like BGP) vs. ARP/ND, then PE2 can't learn them proactively even after 
it detects PE1's failure. Is that correct?
Zzh> Is "refresh both MAC and IP for the corresponding host in its tables" for 
PE2? The way the text reads, it's H1.

Zzh> Additionally, I noticed the following right after the above quoted text:

   Even in core failure scenario on PE1, PE1 must withdraw all its local
   layer-2 connectivity, as Layer-2 traffic should not be received by
   PE1.

Zzh> I struggled with "withdraw all its local layer-2 connectivity". I finally 
think you probably mean "bring down all its local layer-2 connectivity". Is 
that right?

--
For the following normalization rule:

  ... If the
  ingress PE learns a prefix P via a non-reserved ESI RT-5 route
  with a weight (for which IP A-D per ES routes also signal a
  weight) and a zero ESI RT-5 that includes a weight, the ingress PE
  will consider all the PEs attached to the ES as a single PE when
  normalizing weights.

  As an example, consider PE1 and PE2 are attached to ES-1 and PE1
  advertises an RT-5 for prefix P with ESI-1 (and EVPN Link
  Bandwidth of 1).  Consider PE3 advertises an RT-5 for P with ESI=0
  and EVPN Link Bandwidth of 2.  If PE1 and PE2 advertise an EVPN
  Link Bandwidth of 1 and 2, respectively, in the IP A-D per ES
  routes for ES-1, an ingress PE4 SHOULD assign a normalized weight
  of 1 to ES-1 and a normalized weight of 2 to PE3.

What is the rationale for normalizing the weight of ES-1 to 1?
[Jorge] the ES represents a single CE, and the weight of the RT-5 with ESI=1 
influences the number of flows for that CE. So if the remote PE gets two RT-5s: 
RT-5 (weight=1) and RT-5 (weight=2) it should apply the weights based on those 
RT-5s.

Zzh> I still don't get the rational. PE1/PE2/PE3 advertise link bandwidth 1/2/2 
respectively, yet we normalize ES-1 to weight 1?
Zzh> Thanks.
Zzh> Jeffrey

Thanks.
Jeffrey



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[Jorge Rabadan (Nokia)]

Hi Jeffrey,

Thanks again.

I think your suggested changes are ok. We can make the changes either after the 
WG adoption call or before if you think it is better (when the data tracker is 
open for publication again).

Thanks.
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Monday, October 23, 2023 at 8:20 PM
To: Jorge Rabadan (Nokia) , Kiran Nagaraj (Nokia) 
, Wen Lin , 'Ali Sajassi (sajassi)' 

Cc: 'BESS' 
Subject: RE: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

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

Thanks for the revision.
Please see zzh> below for two comments.



Juniper Business Use Only
From: Jorge Rabadan (Nokia) 
Sent: Monday, October 23, 2023 10:33 AM
To: Jeffrey (Zhaohui) Zhang ; Kiran Nagaraj (Nokia) 
; Wen Lin ; 'Ali Sajassi (sajassi)' 

Cc: 'BESS' 
Subject: Re: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[External Email. Be cautious of content]

Hi Jeffrey,

Thanks very much for the review. Version 6 is published addressing your 
comments.

Please see in-line.

Thanks!
Jorge



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Date: Wednesday, September 27, 2023 at 5:34 PM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Kiran Nagaraj 
(Nokia) mailto:kiran.naga...@nokia.com>>, Wen Lin 
mailto:w...@juniper.net>>, 'Ali Sajassi (sajassi)' 
mailto:saja...@cisco.com>>
Cc: 'BESS' mailto:bess@ietf.org>>
Subject: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

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,

I have the following comments/suggestions/questions:

Idnits reported:

  -- The draft header indicates that this document updates RFC8365, but the
 abstract doesn't seem to mention this, which it should.
[Jorge] good point. Added.


Would this update 7432 as well?
[Jorge] since 7432bis obsoletes 7432 and refers to this document, it is 
probably ok not to say it updates 7432… but I don’t have a strong opinion. It 
may depend on how fast 7432bis progresses as well?

Zzh> 7432bis WGLC has not happened yet, so I believe this one will go before 
7432bis and should update 7432.


  == Outdated reference: A later version (-06) exists of
 draft-ietf-bess-evpn-geneve-05

I normally don't reference a specific revision of a document, unless the 
revision number matters. If you remove the revision in the reference, you'll 
not need to worry about updating it again.
[Jorge] sure, done.


Given that this is ahead of rfc7432bis, the "EVPN ESI Multihoming Attributes" 
registry creation for the 1-octet Flags field in the ESI Label Extended 
Community should be moved to this draft.
[Jorge] As long as this document it is really ahead of 7432bis, sure. We added 
it to the IANA section, and we can always remove it if 7432bis goes out before 
this one.

Zzh> I should have noticed it earlier, but now I think the name “EVPN ESI 
Multihoming Attributes” is a bit confusing. I think it’s better called “EVPN 
ESI Label Extended Community Flags” registry. In addition, all existing bits 
should also be documented in the registry-creation request.
Zzh> Thanks!
Zzh> Jeffrey


"MPLS-based IP Tunnel" does not seem to be accurate to me. It should be 
"IP-based MPLS Tunnel". Related to that, the three tunnel types can be renamed 
to:

- IP-based MPLS Tunnel
- (SR-)MPLS Tunnel
- IP Tunnel

I don't think we need "group" in terms like "group MPLS-based IP" - it can 
simply be "IP-based MPLS".
[Jorge] ok, changed


There a few references like the following:

   [RFC9012] BGP Encapsulation extended community

I believe the reference should be put after the relevant text:

   BGP Encapsulation extended community [RFC9012]
[Jorge] ok, fixed.



Thanks.
Jeffrey

Juniper Business Use Only
___
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

[bruno . decraene]

Hi Ketan,

Thanks for your reply.

Your proposed changes look good to me.

Thanks for this.

--Bruno

From: Ketan Talaulikar 
Sent: Monday, October 23, 2023 1:06 PM
To: DECRAENE Bruno INNOV/NET 
Cc: Matthew Bocci (Nokia) ; 
draft-trr-bess-bgp-srv6-a...@ietf.org; bess@ietf.org
Subject: Re: WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

Hi Bruno,

Thanks for your support and comments. Please check inline below for response.

On Wed, Oct 11, 2023 at 7:51 PM 
mailto:bruno.decra...@orange.com>> wrote:
I support adoption : clarifying spec and improving interop is important.

Thank you for section 4 regarding Backward Compatibility.
May be 1 comment although I didn’t take time to read everything in details and 
I’m not familiar with EVPN.

It’s not completely clear to me whether backward compatibility MAY be preserved 
or MUST be preserved.
Unless there is a good technical reason, my preference would be for “MUST be 
preserved”.
e.g.
§4

OLD: Backward compatibility with implementations doing the bitwise
   logical-OR operation can be preserved by the advertisement of SIDs


NEW: Backward compatibility with implementations doing the bitwise

   logical-OR operation is preserved thanks to the advertisement of SIDs


KT> Ack. We will incorporate this change in the next version.

§3.1
OLD:

it is

   REQUIRED that proper LBL, LNL, and FL values be set corresponding to

   the supported SID Structure for the End.DT2M SRv6 Service SIDs.

KT> In this context, the "proper" values are the same values as signaled via 
the SID Structure for the End.DT2M SID. Would the following work?

NEW:
it is
REQUIRED that the LBL, LNL, and FL values be set as indicated via
the SID Structure for the End.DT2M SRv6 Service SIDs.





Given that this is already the second spec to clarify this, may be “proper [..] 
value” could be expanded so as to specify the precise behavior which is 
REQUIRED.


Probably similar comment for §3.2 (“The LBL, LNL, and FL MUST be set to 
appropriate values”).

KT> Perhaps the word "appropriate" is redundant here ... would removing it help?

Thanks,
Ketan


Thanks,
Regards,
--Bruno



Orange Restricted


Orange Restricted
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Matthew Bocci (Nokia)
Sent: Thursday, September 28, 2023 4:49 PM
To: bess@ietf.org
Cc: 
draft-trr-bess-bgp-srv6-a...@ietf.org
Subject: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

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)



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, 

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

[Matthew Bocci (Nokia)]

Hi Ketan

Thanks. That works.

Matthew

From: Ketan Talaulikar 
Date: Monday, 23 October 2023 at 12:07
To: Matthew Bocci (Nokia) 
Cc: bess@ietf.org , draft-trr-bess-bgp-srv6-a...@ietf.org 

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

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

We have just posted the WG version of the draft that is identical to the one 
that was up for adoption.

We will post another update after incorporating the changes to address Bruno's 
comments after we conclude on the text changes.

Thanks,
Ketan


On Wed, Oct 18, 2023 at 4:10 PM Matthew Bocci (Nokia) 
mailto:matthew.bo...@nokia.com>> wrote:
WG,

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

Authors: please respond to the one comment form Bruno and upload a new version 
of the draft as draft-ietf-bess-bgp-srv6-args-00.

Thanks

Matthew

From: Matthew Bocci (Nokia) 
mailto:matthew.bo...@nokia.com>>
Date: Thursday, 28 September 2023 at 15:49
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-trr-bess-bgp-srv6-a...@ietf.org
 
mailto:draft-trr-bess-bgp-srv6-a...@ietf.org>>
Subject: WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02
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] I-D Action: draft-ietf-bess-bgp-srv6-args-00.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-bgp-srv6-args-00.txt is now available. It is a
work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   SRv6 Argument Signaling for BGP Services
   Authors: Ketan Talaulikar
Kamran Raza
Jorge Rabadan
Wen Lin
   Name:draft-ietf-bess-bgp-srv6-args-00.txt
   Pages:   13
   Dates:   2023-10-23

Abstract:

   RFC9252 defines procedures and messages for SRv6-based BGP services
   including L3VPN, EVPN, and Internet services.  This document updates
   RFC9252 and provides more detailed specifications for the signaling
   and processing of SRv6 SID advertisements for BGP Service routes
   associated with SRv6 Endpoint Behaviors that support arguments.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-00

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