Re: [bess] Genart last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[David Schinazi]

That sounds great, thanks Donald!

David

On Fri, Feb 5, 2021 at 6:34 PM Donald Eastlake  wrote:

> Hi Dave,
>
> Thanks for the review. See below.
>
> On Fri, Feb 5, 2021 at 4:44 PM David Schinazi via Datatracker
>  wrote:
> > Reviewer: David Schinazi
> > Review result: Ready with Nits
> >
> > 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
> >
> > .
> >
> > Document: draft-ietf-bess-evpn-oam-req-frmwk-04
> > Reviewer: David Schinazi
> > Review Date: 2021-02-05
> > IETF LC End Date: 2021-02-16
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary: Thank you for a well-written document.
> >   It introduces a lot of terminology I wasn't used to,
> >   but does a good job of explaining it.
> >
> > Major issues: None
> >
> > Minor issues: None
> >
> > Nits/editorial comments:
> >   - The abstract defines all the acronyms (which is great) except PBB,
> could it define that one too?
> >   - Section 2.1 doesn't really explain what a "P node" is.
>
> Sure, we can expand PBB (Provider Backbone Bridge) in the abstract and
> say in Section 2.1 that P is Provider. These should probably also be
> added to the terminology section. I've made these changes in the
> working copy but they are pretty minor so I think I'll wait for the
> results of other reviews before uploading a new version.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[Donald Eastlake]

Hi Dave,

Thanks for the review. See below.

On Fri, Feb 5, 2021 at 4:44 PM David Schinazi via Datatracker
 wrote:
> Reviewer: David Schinazi
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-ietf-bess-evpn-oam-req-frmwk-04
> Reviewer: David Schinazi
> Review Date: 2021-02-05
> IETF LC End Date: 2021-02-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Thank you for a well-written document.
>   It introduces a lot of terminology I wasn't used to,
>   but does a good job of explaining it.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>   - The abstract defines all the acronyms (which is great) except PBB, could 
> it define that one too?
>   - Section 2.1 doesn't really explain what a "P node" is.

Sure, we can expand PBB (Provider Backbone Bridge) in the abstract and
say in Section 2.1 that P is Provider. These should probably also be
added to the terminology section. I've made these changes in the
working copy but they are pretty minor so I think I'll wait for the
results of other reviews before uploading a new version.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

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

[bess] Genart last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[David Schinazi via Datatracker]

Reviewer: David Schinazi
Review result: Ready with Nits

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

.

Document: draft-ietf-bess-evpn-oam-req-frmwk-04
Reviewer: David Schinazi
Review Date: 2021-02-05
IETF LC End Date: 2021-02-16
IESG Telechat date: Not scheduled for a telechat

Summary: Thank you for a well-written document.
  It introduces a lot of terminology I wasn't used to,
  but does a good job of explaining it.

Major issues: None

Minor issues: None

Nits/editorial comments:
  - The abstract defines all the acronyms (which is great) except PBB, could it 
define that one too?
  - Section 2.1 doesn't really explain what a "P node" is.


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

Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Tulasi,

For the default DF algorithm, I think at that point it will be up to the 
implementation how to resolve the candidate list PEs with originating IPs of 
different family.
I know of some implementations that do what you are saying, but you can’t 
assume all RFC7432/8584 implementations will do that.

Thanks.
Jorge

From: BESS  on behalf of TULASI RAM REDDY 

Date: Friday, February 5, 2021 at 2:15 PM
To: Muthu Arul Mozhi Perumal 
Cc: bess@ietf.org 
Subject: Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP 
Address of different address family
Thanks Muthu.
Shouldn't numeric value here mean simply the 4byte or 16 byte unsigned value 
representation of the IP address field?
Thinking loudly on how to interpret numeric value  and the limitations here. 
Any comments?


each PE builds an ordered list of the IP

addresses of all the PE nodes connected to the Ethernet segment

(including itself), in increasing numeric value

Thanks,
Tulasi.
On Fri, Feb 5, 2021 at 3:15 PM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Hi Tulasi,

I think the problem is, there is no standard way to numerically compare IPv4 
with IPv6 addresses to form an ordered list. So, all the PEs multihomed to an 
ES may not always arrive at the same DF (or BFD in the case of single-active 
L-LINE service) with the default DF election algo. This is problematic (and may 
cause traffic loops). Hence, the default DF election algo works only when all 
PEs multihomed to an ES have Originating Router's IP Address of the same AF..

Regards,
Muthu

On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
mailto:tulasiramire...@gmail.com>> wrote:
Hi All,

As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF algorithm 
is expected to have
all multihomed PEs to have Originating IP of the same address family.
Do we see any interop issue if the different address families are considered, 
i.e. ordering in
ascending order based on numerical value in Originating IP here? For IPv4 read 
4 octets as unsigned integer
and IPv6 is considered as 16 octet unsigned integer.

1.3.  Problem Statement

Default DF election algorithm assumes

that all the PEs who are multihomed to the same ES (and interested in

the DF election by exchanging EVPN routes) use an Originating

Router's IP address [RFC7432] of the same 
family.

Thanks,
TULASI RAMI REDDY N
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


--
TULASI RAMI REDDY N
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[TULASI RAM REDDY]

Thanks Muthu.
Shouldn't numeric value here mean simply the 4byte or 16 byte unsigned
value representation of the IP address field?
Thinking loudly on how to interpret numeric value  and the limitations
here. Any comments?

each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the Ethernet segment
(including itself), in *increasing numeric value*


Thanks,
Tulasi.
On Fri, Feb 5, 2021 at 3:15 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:

> Hi Tulasi,
>
> I think the problem is, there is no standard way to numerically compare
> IPv4 with IPv6 addresses to form an ordered list. So, all the PEs
> multihomed to an ES may not always arrive at the same DF (or BFD in the
> case of single-active L-LINE service) with the default DF election algo.
> This is problematic (and may cause traffic loops). Hence, the default DF
> election algo works only when all PEs multihomed to an ES have Originating
> Router's IP Address of the same AF..
>
> Regards,
> Muthu
>
> On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
> wrote:
>
>> Hi All,
>>
>> As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF
>> algorithm is expected to have
>> all multihomed PEs to have Originating IP of the same address family.
>> Do we see any interop issue if the different address families are
>> considered, i.e. ordering in
>> ascending order based on numerical value in Originating IP here? For IPv4
>> read 4 octets as unsigned integer
>> and IPv6 is considered as 16 octet unsigned integer.
>>
>> 1.3 .  Problem Statement
>>
>> Default DF election algorithm assumes
>> that all the PEs who are multihomed to the same ES (and interested in
>> the DF election by exchanging EVPN routes) use an Originating
>> Router's IP address [RFC7432 ] of the 
>> same family.
>>
>>
>> Thanks,
>> TULASI RAMI REDDY N
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>

-- 
TULASI RAMI REDDY N
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[Muthu Arul Mozhi Perumal]

Hi Tulasi,

I think the problem is, there is no standard way to numerically compare
IPv4 with IPv6 addresses to form an ordered list. So, all the PEs
multihomed to an ES may not always arrive at the same DF (or BFD in the
case of single-active L-LINE service) with the default DF election algo.
This is problematic (and may cause traffic loops). Hence, the default DF
election algo works only when all PEs multihomed to an ES have Originating
Router's IP Address of the same AF..

Regards,
Muthu

On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
wrote:

> Hi All,
>
> As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF
> algorithm is expected to have
> all multihomed PEs to have Originating IP of the same address family.
> Do we see any interop issue if the different address families are
> considered, i.e. ordering in
> ascending order based on numerical value in Originating IP here? For IPv4
> read 4 octets as unsigned integer
> and IPv6 is considered as 16 octet unsigned integer.
>
> 1.3 .  Problem Statement
>
> Default DF election algorithm assumes
> that all the PEs who are multihomed to the same ES (and interested in
> the DF election by exchanging EVPN routes) use an Originating
> Router's IP address [RFC7432 ] of the 
> same family.
>
>
> Thanks,
> TULASI RAMI REDDY N
> ___
> 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] I-D Action: draft-ietf-bess-evpn-inter-subnet-forwarding-12.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   : Integrated Routing and Bridging in EVPN
Authors : Ali Sajassi
  Samer Salam
  Samir Thoria
  John E Drake
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-inter-subnet-forwarding-12.txt
Pages   : 35
Date: 2021-02-05

Abstract:
   Ethernet VPN (EVPN) provides an extensible and flexible multi-homing
   VPN solution over an MPLS/IP network for intra-subnet connectivity
   among Tenant Systems and End Devices that can be physical or virtual.
   However, there are scenarios for which there is a need for a dynamic
   and efficient inter-subnet connectivity among these Tenant Systems
   and End Devices while maintaining the multi-homing capabilities of
   EVPN.  This document describes an Integrated Routing and Bridging
   (IRB) solution based on EVPN to address such requirements.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-inter-subnet-forwarding-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-inter-subnet-forwarding-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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