[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-06-12 Thread Adam 1. Simpson (Nokia) 
I am not aware of any undisclosed IPR either. Sorry for my delay.

From: Stephane Litkowski (slitkows) 
Date: Thursday, June 12, 2025 at 11:44 AM
To: James Uttaro , Wen Lin 
Cc: John Drake , Ali Sajassi (sajassi) , 
Adam 1. Simpson (Nokia) , [email protected] 
, [email protected] , 
[email protected] , [email protected] 
Subject: RE: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12

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.


Thanks Jim,

We are missing Adam and Ali’s reply, considering Eric is not participating 
anymore to IETF.


From: James Uttaro 
Sent: Thursday, June 12, 2025 8:19 PM
To: Wen Lin 
Cc: John Drake ; Stephane Litkowski (slitkows) 
; Ali Sajassi (sajassi) ; 
[email protected]; [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12

I am unaware of any undisclosed IPR.

Thanks
Jim Uttaro

On Jun 12, 2025, at 10:32 AM, Wen Lin 
mailto:[email protected]>> wrote:

I am not aware of any undisclosed IPR either.

Thanks,
Wen



Juniper Business Use Only
From: John Drake mailto:[email protected]>>
Date: Thursday, June 12, 2025 at 9:31 AM
To: 'Stephane Litkowski (slitkows)' 
mailto:[email protected]>>,
 'Ali Sajassi (sajassi)' mailto:[email protected]>>, Wen Lin 
mailto:[email protected]>>, 
[email protected]mailto:[email protected]>>,
 [email protected] 
mailto:[email protected]>>, 
[email protected] 
mailto:[email protected]>>, 
[email protected] 
mailto:[email protected]>>
Cc: [email protected] mailto:[email protected]>>
Subject: Re: [bess] FW: Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12
[External Email. Be cautious of content]

I'm not aware of any undisclosed IPR.

On Thursday, June 12, 2025 at 02:14:28 AM PDT, 
[email protected] 
mailto:[email protected]>> wrote:



Hi folks,



Just a reminder that this document is blocked for progressing, because we still 
haven’t got IPR replies from all co-authors (at least active ones).





From: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Sent: Monday, February 10, 2025 3:46 PM
To: Ali Sajassi (sajassi) mailto:[email protected]>>; 
[email protected]; 
[email protected]; 
[email protected]; 
[email protected]; 
[email protected]
Cc: [email protected]
Subject: [bess] FW: Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



Hi Authors,



Could you please reply to this new IPR poll regarding 
draft-ietf-bess-evpn-ipvpn-interworking ?



Thanks in advance,



Stephane





From: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Sent: Tuesday, February 4, 2025 7:59 PM
To: Jorge Rabadan (Nokia) 
mailto:[email protected]>>;
 [email protected]; 
[email protected];
 [email protected]
Subject: RE: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



Thanks Jorge.



Yeah, as the IPR call was done a long time ago, I want to ensure we capture any 
new IPR disclosure before we send to IESG.





From: Jorge Rabadan (Nokia) 
mailto:[email protected]>>
Sent: Tuesday, February 4, 2025 2:00 PM
To: [email protected]; Stephane Litkowski 
(slitkows) mailto:[email protected]>>; 
[email protected];
 [email protected]
Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



Hi Stephane,



Version 13 posted, addressing all the comments in the WG last call.



Also I’m not aware of any related IPR.

(sorry, it was not clear to me if we, authors, had to reply again with this).



Thanks!

Jorge



From: [email protected] 
mailto:[email protected]>>
Date: Tuesday, February 4, 2025 at 12:27 AM
To: 'Stephane Litkowski (slitkows)' 
mailto:[email protected]>>,
 
[email protected]
 
mailto:[email protected]>>,
 [email protected] mailto:[email protected]>>
Subject: RE: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-06-12 Thread Stephane Litkowski (slitkows) 
Thanks Jim,

We are missing Adam and Ali’s reply, considering Eric is not participating 
anymore to IETF.


From: James Uttaro 
Sent: Thursday, June 12, 2025 8:19 PM
To: Wen Lin 
Cc: John Drake ; Stephane Litkowski (slitkows) 
; Ali Sajassi (sajassi) ; 
[email protected]; [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12

I am unaware of any undisclosed IPR.

Thanks
Jim Uttaro


On Jun 12, 2025, at 10:32 AM, Wen Lin 
mailto:[email protected]>> wrote:

I am not aware of any undisclosed IPR either.

Thanks,
Wen



Juniper Business Use Only
From: John Drake mailto:[email protected]>>
Date: Thursday, June 12, 2025 at 9:31 AM
To: 'Stephane Litkowski (slitkows)' 
mailto:[email protected]>>,
 'Ali Sajassi (sajassi)' mailto:[email protected]>>, Wen Lin 
mailto:[email protected]>>, 
[email protected]mailto:[email protected]>>,
 [email protected] 
mailto:[email protected]>>, 
[email protected] 
mailto:[email protected]>>, 
[email protected] 
mailto:[email protected]>>
Cc: [email protected] mailto:[email protected]>>
Subject: Re: [bess] FW: Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12
[External Email. Be cautious of content]

I'm not aware of any undisclosed IPR.

On Thursday, June 12, 2025 at 02:14:28 AM PDT, 
[email protected] 
mailto:[email protected]>> wrote:



Hi folks,



Just a reminder that this document is blocked for progressing, because we still 
haven’t got IPR replies from all co-authors (at least active ones).





From: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Sent: Monday, February 10, 2025 3:46 PM
To: Ali Sajassi (sajassi) mailto:[email protected]>>; 
[email protected]; 
[email protected]; 
[email protected]; 
[email protected]; 
[email protected]
Cc: [email protected]
Subject: [bess] FW: Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



Hi Authors,



Could you please reply to this new IPR poll regarding 
draft-ietf-bess-evpn-ipvpn-interworking ?



Thanks in advance,



Stephane





From: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Sent: Tuesday, February 4, 2025 7:59 PM
To: Jorge Rabadan (Nokia) 
mailto:[email protected]>>;
 [email protected]; 
[email protected];
 [email protected]
Subject: RE: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



Thanks Jorge.



Yeah, as the IPR call was done a long time ago, I want to ensure we capture any 
new IPR disclosure before we send to IESG.





From: Jorge Rabadan (Nokia) 
mailto:[email protected]>>
Sent: Tuesday, February 4, 2025 2:00 PM
To: [email protected]; Stephane Litkowski 
(slitkows) mailto:[email protected]>>; 
[email protected];
 [email protected]
Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



Hi Stephane,



Version 13 posted, addressing all the comments in the WG last call.



Also I’m not aware of any related IPR.

(sorry, it was not clear to me if we, authors, had to reply again with this).



Thanks!

Jorge



From: [email protected] 
mailto:[email protected]>>
Date: Tuesday, February 4, 2025 at 12:27 AM
To: 'Stephane Litkowski (slitkows)' 
mailto:[email protected]>>,
 
[email protected]
 
mailto:[email protected]>>,
 [email protected] mailto:[email protected]>>
Subject: RE: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12



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



WGLC is now closed.



We received few comments during this WGLC. Authors, please address them in a 
new version.



I’m also waiting for the IPR disclosure replies and then we can move forward 
with the draft.



Thanks in advance,



From: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Sent: Monday, January 27, 2025 11:25 AM
To: 
draft-ie

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-06-12 Thread James Uttaro 
I am unaware of any undisclosed IPR.

Thanks
Jim Uttaro

> On Jun 12, 2025, at 10:32 AM, Wen Lin  wrote:
> 
> I am not aware of any undisclosed IPR either.
>  
> Thanks,
> Wen
>  
> 
> Juniper Business Use Only
> 
> From: John Drake mailto:[email protected]>>
> Date: Thursday, June 12, 2025 at 9:31 AM
> To: 'Stephane Litkowski (slitkows)'  >, 'Ali Sajassi (sajassi)' 
> mailto:[email protected]>>, Wen Lin  >, [email protected] 
>  >, [email protected] 
>  mailto:[email protected]>>, 
> [email protected]   >, [email protected] 
>   >
> Cc: [email protected]   >
> Subject: Re: [bess] FW: Short new WGLC and IPR poll for 
> draft-ietf-bess-evpn-ipvpn-interworking-12
> 
> [External Email. Be cautious of content]
>  
> I'm not aware of any undisclosed IPR.
>  
> On Thursday, June 12, 2025 at 02:14:28 AM PDT, [email protected] 
>   > wrote:
>  
>  
> Hi folks,
> 
>  
> 
> Just a reminder that this document is blocked for progressing, because we 
> still haven’t got IPR replies from all co-authors (at least active ones).
> 
>  
> 
>  
> 
> From: Stephane Litkowski (slitkows)  >
> Sent: Monday, February 10, 2025 3:46 PM
> To: Ali Sajassi (sajassi) mailto:[email protected]>>; 
> [email protected] ; [email protected] 
> ; [email protected] 
> ; [email protected] ; 
> [email protected] 
> Cc: [email protected] 
> Subject: [bess] FW: Short new WGLC and IPR poll for 
> draft-ietf-bess-evpn-ipvpn-interworking-12
> 
>  
> 
> Hi Authors,
> 
>  
> 
> Could you please reply to this new IPR poll regarding 
> draft-ietf-bess-evpn-ipvpn-interworking ?
> 
>  
> 
> Thanks in advance,
> 
>  
> 
> Stephane
> 
>  
> 
>  
> 
> From: Stephane Litkowski (slitkows)  >
> Sent: Tuesday, February 4, 2025 7:59 PM
> To: Jorge Rabadan (Nokia)  >; [email protected] 
> ; 
> [email protected] 
> ; [email protected] 
> 
> Subject: RE: [bess] Short new WGLC and IPR poll for 
> draft-ietf-bess-evpn-ipvpn-interworking-12
> 
>  
> 
> Thanks Jorge.
> 
>  
> 
> Yeah, as the IPR call was done a long time ago, I want to ensure we capture 
> any new IPR disclosure before we send to IESG.
> 
>  
> 
>  
> 
> From: Jorge Rabadan (Nokia)  >
> Sent: Tuesday, February 4, 2025 2:00 PM
> To: [email protected] ; Stephane 
> Litkowski (slitkows) mailto:[email protected]>>; 
> [email protected] 
> ; [email protected] 
> 
> Subject: Re: [bess] Short new WGLC and IPR poll for 
> draft-ietf-bess-evpn-ipvpn-interworking-12
> 
>  
> 
> Hi Stephane,
> 
>  
> 
> Version 13 posted, addressing all the comments in the WG last call.
> 
>  
> 
> Also I’m not aware of any related IPR.
> 
> (sorry, it was not clear to me if we, authors, had to reply again with this).
> 
>  
> 
> Thanks!
> 
> Jorge
> 
>  
> 
> From: [email protected]  
> mailto:[email protected]>>
> Date: Tuesday, February 4, 2025 at 12:27 AM
> To: 'Stephane Litkowski (slitkows)'  >, 
> [email protected] 
>  
>  >, [email protected] 
>  mailto:[email protected]>>
> Subject: RE: [bess] Short new WGLC and IPR poll for 
> draft-ietf-bess-evpn-ipvpn-interworking-12
> 
>  
> 
> 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 WG,
> 
>  
> 
> WGLC is now closed.
> 
>  
> 
> We received few comments during this WGLC. Authors, please address them in a 
> new version.
> 
>  
> 
> I’m also waiting for the IPR disclosure replies and then we can move forward 
> with the draft.
> 
>  
> 
> Thanks in advance,
> 
>  
> 
> From: Stephane Litkowski (slitkows)  >
> Sent: Monday, January 27, 2025 11:25 AM
> To: [email protected] 
>

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-02-04 Thread Jorge Rabadan (Nokia) 
Hi Stephane,

Version 13 posted, addressing all the comments in the WG last call.

Also I’m not aware of any related IPR.
(sorry, it was not clear to me if we, authors, had to reply again with this).

Thanks!
Jorge

From: [email protected] 
Date: Tuesday, February 4, 2025 at 12:27 AM
To: 'Stephane Litkowski (slitkows)' , 
[email protected] 
, [email protected] 

Subject: RE: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12

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

WGLC is now closed.

We received few comments during this WGLC. Authors, please address them in a 
new version.

I’m also waiting for the IPR disclosure replies and then we can move forward 
with the draft.

Thanks in advance,

From: Stephane Litkowski (slitkows) 
Sent: Monday, January 27, 2025 11:25 AM
To: [email protected]; [email protected]
Subject: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12

Hi,

As draft-ietf-bess-evpn-ipvpn-interworking went through multiple discussions 
that seem to be closed now. We would like to do a new short WGLC of 1-week to 
gather any additional comment before we move forward with the draft.

The WGLC poll starts today and will end on 2/3.

Similarly, as the last IPR poll was done a long time back. We are also polling 
for knowledge of any undisclosed IPR that applies to this document (see RFCs 
3979, 4879, 3669 and 5378 for more details).


Thank you

Brgds,


Stephane, Matthew, Jeffrey (BESS chairs)



___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-02-04 Thread slitkows.ietf 
Hi WG,

 

WGLC is now closed.

 

We received few comments during this WGLC. Authors, please address them in a
new version.

 

I'm also waiting for the IPR disclosure replies and then we can move forward
with the draft.

 

Thanks in advance,

 

From: Stephane Litkowski (slitkows)  
Sent: Monday, January 27, 2025 11:25 AM
To: [email protected]; [email protected]
Subject: [bess] Short new WGLC and IPR poll for
draft-ietf-bess-evpn-ipvpn-interworking-12

 

Hi,

 

As draft-ietf-bess-evpn-ipvpn-interworking went through multiple discussions
that seem to be closed now. We would like to do a new short WGLC of 1-week
to gather any additional comment before we move forward with the draft.

 

The WGLC poll starts today and will end on 2/3.

 

Similarly, as the last IPR poll was done a long time back. We are also
polling for knowledge of any undisclosed IPR that applies to this document
(see RFCs 3979, 4879, 3669 and 5378 for more details).

 

 

Thank you

 

Brgds,

 

 

Stephane, Matthew, Jeffrey (BESS chairs)

 

 

 

___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-02-03 Thread Gyan Mishra 
Agreed. I am good.

Thank you

Gyan

On Mon, Feb 3, 2025 at 8:31 AM Jorge Rabadan (Nokia) <
[email protected]> wrote:

> Hi Gyan,
>
>
>
> The key difference between a regular and a composite domain is that in a
> composite domain, multiple ISF SAFIs are used to advertise ISF prefixes of
> an IP-VRF, whereas a regular domain uses only one. As discussed in the case
> of gateway procedures for regular domains, the procedures on composite PEs
> remain unchanged regarding how they advertise EVPN and/or IPVPN routes for
> a given encapsulation.
>
>
>
> Regarding the wording of “reorigination” versus “readvertisement” — it
> depends on the perspective IMO.
>
>
>
> Consider Figure 2, where PE1 advertises an EVPN VXLAN IP Prefix route for
> 10.0.0.0/24. GW1 imports 10.0.0.0/24 into the IP-VRF route table and then
> reoriginates an IPVPN route, treating the prefix as if it were locally
> learned (from the perspective of IPVPN, although if needed you can
> ‘propagate’ some bgp path attributes between SAFIs as discussed in section
> 5).
>
>
>
> From the perspective of how the route is advertised to a BGP peer with its
> encapsulation parameters, this is a reorigination, as discussed, and it
> follows existing specifications. However, from the viewpoint of the prefix
> and certain path attributes, the route is effectively propagated through
> the gateways all the way to PE2.
>
>
>
> Personally, I don’t think it matters much, since the spec is clear. The
> proof is that it has been implemented by multiple vendors (at least 5
> implementations that I’m aware of) and interoperability has been proven for
> a few years now. So I don’t think there is ambiguity in the text.
>
> Thanks.
>
> Jorge
>
>
>
>
>
> *From: *Gyan Mishra 
> *Date: *Friday, January 31, 2025 at 9:29 PM
> *To: *Jorge Rabadan (Nokia) 
> *Cc: *Stephane Litkowski (slitkows) ,
> [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, Bernier, Daniel 
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *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
>
>
>
> In section 7 composite PE with congruent IPVPN & EVPN PEs at the inter
> domain boundary between the domains, I wanted to confirm that this is also
> underlay independent and hence the IPVPN and EVPN prefixes would be
> automatically propagated between domains without any reorigination.
>
>
>
> The composite case applies to this draft below and so could be an
> alternative to draft below drafts service interworking solution.  The other
> alternative I had come up with that I mentioned is inter-as opt-a for 7.2
> service IW.
>
>
>
> Your composite PE section 7 is much better as it’s a single peer.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00
>
>
>
> Last question on reorigination versus readvertisement.  We have the new
> paragraph addition which says reorigination but I don’t see anywhere in the
> draft saying reorigination but do see readvertising.  If we are using
> reorigination in the paragraph then then the draft maybe  wherever we say
> readvertising we should change reorigination to match or vice versa.  I
> believe for service interworking there is a reorigination keyword used for
> GW/IW function going from safi-x to safi-y.
>
>
>
> Thanks
>
>
>
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[email protected]* 
>
> *M 301 502-1347*
>
>
>
>
>
>
>
> On Fri, Jan 31, 2025 at 11:06 PM Gyan Mishra 
> wrote:
>
>
>
> Hi Jorge
>
>
>
> Please see in-line
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[email protected]* 
>
> *M 301 502-1347*
>
>
>
>
>
>
>
> On Fri, Jan 31, 2025 at 11:16 AM Jorge Rabadan (Nokia) <
> [email protected]> wrote:
>
> Hi Gyan,
>
>
>
> Please see in-line.
>
>
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, January 30, 2025 at 11:19 PM
> *To: *Jorge Rabadan (Nokia) 
> *Cc: *Stephane Litkowski (slitkows) ,
> [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, Bernier, Daniel 
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *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
>
>
>
> Responses in-line
>
>
>
> On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) <
> [email protected]> wrote:
>
> Hi Gyan,
>
>
>
> Thank you for your comments.
>
> I added this text at the end of the introduction section:
>
>
>
> "The interworking procedures in this document always require creating an
>

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-31 Thread Gyan Mishra 
Hi Jorge

In section 7 composite PE with congruent IPVPN & EVPN PEs at the inter
domain boundary between the domains, I wanted to confirm that this is also
underlay independent and hence the IPVPN and EVPN prefixes would be
automatically propagated between domains without any reorigination.

The composite case applies to this draft below and so could be an
alternative to draft below drafts service interworking solution.  The other
alternative I had come up with that I mentioned is inter-as opt-a for 7.2
service IW.

Your composite PE section 7 is much better as it’s a single peer.

https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00

Last question on reorigination versus readvertisement.  We have the new
paragraph addition which says reorigination but I don’t see anywhere in the
draft saying reorigination but do see readvertising.  If we are using
reorigination in the paragraph then then the draft maybe  wherever we say
readvertising we should change reorigination to match or vice versa.  I
believe for service interworking there is a reorigination keyword used for
GW/IW function going from safi-x to safi-y.

Thanks




*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email protected] *



*M 301 502-1347*



On Fri, Jan 31, 2025 at 11:06 PM Gyan Mishra  wrote:

>
> Hi Jorge
>
> Please see in-line
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [email protected] *
>
>
>
> *M 301 502-1347*
>
>
>
> On Fri, Jan 31, 2025 at 11:16 AM Jorge Rabadan (Nokia) <
> [email protected]> wrote:
>
>> Hi Gyan,
>>
>>
>>
>> Please see in-line.
>>
>>
>>
>>
>>
>> *From: *Gyan Mishra 
>> *Date: *Thursday, January 30, 2025 at 11:19 PM
>> *To: *Jorge Rabadan (Nokia) 
>> *Cc: *Stephane Litkowski (slitkows) ,
>> [email protected] <
>> [email protected]>, [email protected] <
>> [email protected]>, Bernier, Daniel 
>> *Subject: *Re: [bess] Short new WGLC and IPR poll for
>> draft-ietf-bess-evpn-ipvpn-interworking-12
>>
>>
>>
>> *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
>>
>>
>>
>> Responses in-line
>>
>>
>>
>> On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) <
>> [email protected]> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>> Thank you for your comments.
>>
>> I added this text at the end of the introduction section:
>>
>>
>>
>> "The interworking procedures in this document always require creating an
>> IP-VRF on the interworking PE. When connecting different domains, the
>> interworking PE follows these steps: it receives routes from one domain
>> (along with that domain’s encapsulation parameters), installs them in the
>> IP-VRF route table, and then reoriginates the routes with the encapsulation
>> parameters of the adjacent domain before advertising them. This
>> reorigination process ensures that the procedures remain independent of the
>> specific transport tunnels used in each domain.”
>>
>>
>>
>> I hope it helps.
>>
>>
>>
>>Gyan> I want to make sure I understand the reorigination with the
>> gateway function see below:
>>
>>
>>
>> So this solution is definitely service interworking with the
>> reorigination which makes it underlay protocol independent.  Please mention
>> service interworking and transport protocol independence
>>
>> *[jorge] Since the procedures mention IP-VPN and EVPN AFI-SAFIs, I think
>> it is clear that the procedures happen in the context of a VRF, i.e. a
>> service. But sure, no issue in adding “service interworking” to the
>> clarification text.*
>>
> Gyan> Thank you
>
>>
>>
>>
>>
>> In a composite domain or PE, IPVPN and EVPN must have different VRF as
>> the different SAFI cannot share the same VRF.
>>
>> *[jorge] Gyan, I have to say that is not true. In our implementations and
>> a few others, IP-VRFs support multiple intersubnet forwarding families in
>> the same IP-VRF. IPVPN and EVPN (L3) can definitively use the same IP-VRF.
>> As described in the text, the IP-VRF in figure 1 can be programmed with ISF
>> routes of different types at the same.*
>>
>>  Gyan> I was not sure and was thinking that using a different VRF would
>> be a way to identify an IPVPN peer from EVPN peer, and the reorigination of
>> the routes,  however I see now EVPN (L3) can be the same VRF as IPVPN as
>> you said.  I was thinking L2/L3 but as this is L3 for both SAFI, as ISF
>> routes can be different route types.  Agreed.
>>
>
>
>> GW
>>
>> IPVPN = VRF IPVPN
>>
>> EVPN = VRF EVPN
>>
>>
>>
>> Domain 1 Domain 2
>>
>> VXLAN  SRv6
>>
>>R1 - EVPN  - GW - PE1 EVPN / IPVPN
>>
>>
>>
>> GW receives the EVPN routes on EVPN peer (safi-x) and reoriginates the
>> routes on IPVPN peer (safi-y)
>>
>>
>>
>> So basically we are just taking the routes from safi-x E

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-31 Thread Gyan Mishra 
Hi Jorge

Please see in-line



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email protected] *



*M 301 502-1347*



On Fri, Jan 31, 2025 at 11:16 AM Jorge Rabadan (Nokia) <
[email protected]> wrote:

> Hi Gyan,
>
>
>
> Please see in-line.
>
>
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, January 30, 2025 at 11:19 PM
> *To: *Jorge Rabadan (Nokia) 
> *Cc: *Stephane Litkowski (slitkows) ,
> [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, Bernier, Daniel 
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *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
>
>
>
> Responses in-line
>
>
>
> On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) <
> [email protected]> wrote:
>
> Hi Gyan,
>
>
>
> Thank you for your comments.
>
> I added this text at the end of the introduction section:
>
>
>
> "The interworking procedures in this document always require creating an
> IP-VRF on the interworking PE. When connecting different domains, the
> interworking PE follows these steps: it receives routes from one domain
> (along with that domain’s encapsulation parameters), installs them in the
> IP-VRF route table, and then reoriginates the routes with the encapsulation
> parameters of the adjacent domain before advertising them. This
> reorigination process ensures that the procedures remain independent of the
> specific transport tunnels used in each domain.”
>
>
>
> I hope it helps.
>
>
>
>Gyan> I want to make sure I understand the reorigination with the
> gateway function see below:
>
>
>
> So this solution is definitely service interworking with the reorigination
> which makes it underlay protocol independent.  Please mention service
> interworking and transport protocol independence
>
> *[jorge] Since the procedures mention IP-VPN and EVPN AFI-SAFIs, I think
> it is clear that the procedures happen in the context of a VRF, i.e. a
> service. But sure, no issue in adding “service interworking” to the
> clarification text.*
>
Gyan> Thank you

>
>
>
>
> In a composite domain or PE, IPVPN and EVPN must have different VRF as the
> different SAFI cannot share the same VRF.
>
> *[jorge] Gyan, I have to say that is not true. In our implementations and
> a few others, IP-VRFs support multiple intersubnet forwarding families in
> the same IP-VRF. IPVPN and EVPN (L3) can definitively use the same IP-VRF.
> As described in the text, the IP-VRF in figure 1 can be programmed with ISF
> routes of different types at the same.*
>
>  Gyan> I was not sure and was thinking that using a different VRF would be
> a way to identify an IPVPN peer from EVPN peer, and the reorigination of
> the routes,  however I see now EVPN (L3) can be the same VRF as IPVPN as
> you said.  I was thinking L2/L3 but as this is L3 for both SAFI, as ISF
> routes can be different route types.  Agreed.
>


> GW
>
> IPVPN = VRF IPVPN
>
> EVPN = VRF EVPN
>
>
>
> Domain 1 Domain 2
>
> VXLAN  SRv6
>
>R1 - EVPN  - GW - PE1 EVPN / IPVPN
>
>
>
> GW receives the EVPN routes on EVPN peer (safi-x) and reoriginates the
> routes on IPVPN peer (safi-y)
>
>
>
> So basically we are just taking the routes from safi-x EVPN peer and
> reoriginating the routes on safi-y IPVPN peer.  In my original examples the
> unicast SAFI on both ends of peering does not require any reorigination
> since it’s the same safi.  However here we are taking the NLRI and
> translating the SAFI from EVPN to IPVPN.  So in that case all the RT-2 mac
> VRF host routes and RT-5 prefix would all get propagated out to PE1 as
> IPVPN routes using the new RT/RD defined for the IPVPN VRF.  Same would
> happen in the opposite direction.  The gateway is configured with
> encapsulation for vxlan domain with NVE tunnnel and also has SRv6 locator
> config and under VRF peer has SRv6 sid allocation mode per-VRF so it’s not
> really underlay independent but underlay dependent since both left vxlan
> domain underlay and right side SRv6 domain are stretched to the GW which is
> siting on both transports.  So in that way it’s doing transport
> interworking by butting up the two adjacent domain types to the GW box.  In
> the case GW box is the VXLAN DCI or ASBR and so sits on the VXLAN side
> already so only have to extend the SRv6 domain over to the GW box on the
> right side.
>
> *[jorge] it is independent of the underlay in the sense that importing
> routes with certain encapsulation parameters and exporting routes with
> certain encapsulation parameters is something specified in other specs and
> this one does not change anything about that termination/origination. For
> instance, import/export of EVPN VXLAN routes is specified in RFC8365

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-31 Thread Jorge Rabadan (Nokia) 
Hi Gyan,

Please see in-line.


From: Gyan Mishra 
Date: Thursday, January 30, 2025 at 11:19 PM
To: Jorge Rabadan (Nokia) 
Cc: Stephane Litkowski (slitkows) , 
[email protected] 
, [email protected] 
, Bernier, Daniel 
Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12

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

Responses in-line

On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) 
mailto:[email protected]>> wrote:
Hi Gyan,

Thank you for your comments.
I added this text at the end of the introduction section:

"The interworking procedures in this document always require creating an IP-VRF 
on the interworking PE. When connecting different domains, the interworking PE 
follows these steps: it receives routes from one domain (along with that 
domain’s encapsulation parameters), installs them in the IP-VRF route table, 
and then reoriginates the routes with the encapsulation parameters of the 
adjacent domain before advertising them. This reorigination process ensures 
that the procedures remain independent of the specific transport tunnels used 
in each domain.”

I hope it helps.

   Gyan> I want to make sure I understand the reorigination with the gateway 
function see below:

So this solution is definitely service interworking with the reorigination 
which makes it underlay protocol independent.  Please mention service 
interworking and transport protocol independence
[jorge] Since the procedures mention IP-VPN and EVPN AFI-SAFIs, I think it is 
clear that the procedures happen in the context of a VRF, i.e. a service. But 
sure, no issue in adding “service interworking” to the clarification text.


In a composite domain or PE, IPVPN and EVPN must have different VRF as the 
different SAFI cannot share the same VRF.
[jorge] Gyan, I have to say that is not true. In our implementations and a few 
others, IP-VRFs support multiple intersubnet forwarding families in the same 
IP-VRF. IPVPN and EVPN (L3) can definitively use the same IP-VRF. As described 
in the text, the IP-VRF in figure 1 can be programmed with ISF routes of 
different types at the same.

GW
IPVPN = VRF IPVPN
EVPN = VRF EVPN

Domain 1 Domain 2
VXLAN  SRv6
   R1 - EVPN  - GW - PE1 EVPN / IPVPN

GW receives the EVPN routes on EVPN peer (safi-x) and reoriginates the routes 
on IPVPN peer (safi-y)

So basically we are just taking the routes from safi-x EVPN peer and 
reoriginating the routes on safi-y IPVPN peer.  In my original examples the 
unicast SAFI on both ends of peering does not require any reorigination since 
it’s the same safi.  However here we are taking the NLRI and translating the 
SAFI from EVPN to IPVPN.  So in that case all the RT-2 mac VRF host routes and 
RT-5 prefix would all get propagated out to PE1 as IPVPN routes using the new 
RT/RD defined for the IPVPN VRF.  Same would happen in the opposite direction.  
The gateway is configured with encapsulation for vxlan domain with NVE tunnnel 
and also has SRv6 locator config and under VRF peer has SRv6 sid allocation 
mode per-VRF so it’s not really underlay independent but underlay dependent 
since both left vxlan domain underlay and right side SRv6 domain are stretched 
to the GW which is siting on both transports.  So in that way it’s doing 
transport interworking by butting up the two adjacent domain types to the GW 
box.  In the case GW box is the VXLAN DCI or ASBR and so sits on the VXLAN side 
already so only have to extend the SRv6 domain over to the GW box on the right 
side.
[jorge] it is independent of the underlay in the sense that importing routes 
with certain encapsulation parameters and exporting routes with certain 
encapsulation parameters is something specified in other specs and this one 
does not change anything about that termination/origination. For instance, 
import/export of EVPN VXLAN routes is specified in RFC8365, IPVPN or EVPN for 
SRv6 routes is specified in RFC9252 (and so forth)


Please let me know if I got it right.

I modified the paragraph slightly based on my understanding.  Figure 8 is a bit 
confusing for GW diagram.  I would think the GW box since it sits in the DC 
side and is the EVPN Denmark PE to the core it should have EVPN MAC-VRF  like 
Figure 7 being a composite PE.  The diagram shows the NVO tunnels on PE1 and 
PE2 and the stretched MPLS tunnels to the gateway which is perfect for the 
transport interworking.  The point I am making about gateway placement is 
important as it would always sit on the DC side and connect to the core PE.  
You may have to redraw a bit the diagrams so they all match up.
Since you have 2 DC one on left and one on right with core in the middle we are 
missing a few routers.
I would make PE1-4 core boxes.  I would give different names for DC side call 
it leaf fo

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-30 Thread Gyan Mishra 
Hi Jorge

Responses in-line


On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) <
[email protected]> wrote:

> Hi Gyan,
>
> Thank you for your comments.
I added this text at the end of the introduction section:

"The interworking procedures in this document always require creating an
IP-VRF on the interworking PE. When connecting different domains, the
interworking PE follows these steps: it receives routes from one domain
(along with that domain’s encapsulation parameters), installs them in the
IP-VRF route table, and then reoriginates the routes with the encapsulation
parameters of the adjacent domain before advertising them. This
reorigination process ensures that the procedures remain independent of the
specific transport tunnels used in each domain.”

I hope it helps.

   Gyan> I want to make sure I understand the reorigination with the
gateway function see below:

So this solution is definitely service interworking with the reorigination
which makes it underlay protocol independent.  Please mention service
interworking and transport protocol independence

In a composite domain or PE, IPVPN and EVPN must have different VRF as the
different SAFI cannot share the same VRF.

GW
IPVPN = VRF IPVPN
EVPN = VRF EVPN

Domain 1 Domain 2
VXLAN  SRv6
   R1 - EVPN  - GW - PE1 EVPN / IPVPN

GW receives the EVPN routes on EVPN peer (safi-x) and reoriginates the
routes on IPVPN peer (safi-y)

So basically we are just taking the routes from safi-x EVPN peer and
reoriginating the routes on safi-y IPVPN peer.  In my original examples the
unicast SAFI on both ends of peering does not require any reorigination
since it’s the same safi.  However here we are taking the NLRI and
translating the SAFI from EVPN to IPVPN.  So in that case all the RT-2 mac
VRF host routes and RT-5 prefix would all get propagated out to PE1 as
IPVPN routes using the new RT/RD defined for the IPVPN VRF.  Same would
happen in the opposite direction.  The gateway is configured with
encapsulation for vxlan domain with NVE tunnnel and also has SRv6 locator
config and under VRF peer has SRv6 sid allocation mode per-VRF so it’s not
really underlay independent but underlay dependent since both left vxlan
domain underlay and right side SRv6 domain are stretched to the GW which is
siting on both transports.  So in that way it’s doing transport
interworking by butting up the two adjacent domain types to the GW box.  In
the case GW box is the VXLAN DCI or ASBR and so sits on the VXLAN side
already so only have to extend the SRv6 domain over to the GW box on the
right side.

Please let me know if I got it right.

I modified the paragraph slightly based on my understanding.  Figure 8 is a
bit confusing for GW diagram.  I would think the GW box since it sits in
the DC side and is the EVPN Denmark PE to the core it should have EVPN
MAC-VRF  like Figure 7 being a composite PE.  The diagram shows the NVO
tunnels on PE1 and PE2 and the stretched MPLS tunnels to the gateway which
is perfect for the transport interworking.  The point I am making about
gateway placement is important as it would always sit on the DC side and
connect to the core PE.  You may have to redraw a bit the diagrams so they
all match up.
Since you have 2 DC one on left and one on right with core in the middle we
are missing a few routers.
I would make PE1-4 core boxes.  I would give different names for DC side
call it leaf for very left and right PE device and add a single GW PE on
left and right side that connects to PE5 and PE1 and PE2.  On the right
side GW PE that sits between PE3 PE4 and PE6.  We can clean up figure 9 to
also have the clear core & dc demark.  The device that connects to the
gateway PE in the DC call if a leaf.

I would label core & dc so you know the demark point for each domain. That
way it matches as well the paragraph below.

"The interworking gateway procedures in this document always require
creating an IP-VRF on the gateway  PE. When connecting to the core
 domains, the gateway PE follows these steps: it receives routes from dc
domain (along with that domain’s dc underlay encapsulation parameters),
installs them in the MAC-VRF  route table, and then reoriginates the routes
with the core underlay encapsulation parameters  before advertising them to
core PE.  This reorigination process as it happens on the core IPVPN peers
with the underlay encapsulation to core PE, it provides the transport
interworking congruence dependency on the specific transport tunnel type by
extending that transport tunnel to the gateway.





> About this:
>
> Example of draft for MPLS/SR-MPLS to SRv6 GW/IW uses a GW for transport
> translation interworking
> & service interworking. This is just one draft but their are many drafts
> on interworking between technologies and both transport and service
> interworking concepts.
>
>
> https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking-15
>
>
> We spoke with the aut

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-30 Thread Jorge Rabadan (Nokia) 
Hi Gyan,

Thank you for your comments.
I added this text at the end of the introduction section:

"The interworking procedures in this document always require creating an IP-VRF 
on the interworking PE. When connecting different domains, the interworking PE 
follows these steps: it receives routes from one domain (along with that 
domain’s encapsulation parameters), installs them in the IP-VRF route table, 
and then reoriginates the routes with the encapsulation parameters of the 
adjacent domain before advertising them. This reorigination process ensures 
that the procedures remain independent of the specific transport tunnels used 
in each domain.”

I hope it helps.

About this:
Example of draft for MPLS/SR-MPLS to SRv6 GW/IW uses a GW for transport 
translation interworking
& service interworking. This is just one draft but their are many drafts on 
interworking between technologies and both transport and service interworking 
concepts.

https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking-15

We spoke with the authors before 
draft-ietf-spring-srv6-mpls-interworking
 was adopted by SPRING. They will add references to our document for their 
section 7.2.1 Gateway Interworking, which is a high level description of the 
gateway model we are specifying in our document in detail for intersubnet 
forwarding. As discussed, draft-ietf-bess-evpn-ipvpn-interworking procedures 
work irrespective of the encapsulation of the domains, since there is always an 
IP-VRF instantiation and the routes are reoriginated with the encapsulation 
parameters of the destination domain.

About this:
Gyan> yes this example is subinterfaces and not tunnels in my opt-a example.  
Since this draft is talking about the all the permutations and details of 
service interworking and transport independence I wonder if it would be 
possible to include as it does not require any gateway feature and the routes 
get propagated between domains.
I don’t think there is anything new to specify with respect to RFC4364 section 
10 option a to guarantee interoperability, and that is not already described. 
It would be good to hear from others too, in case I’m missing something.

Thanks.
Jorge


From: Gyan Mishra 
Date: Wednesday, January 29, 2025 at 10:46 PM
To: Jorge Rabadan (Nokia) 
Cc: Stephane Litkowski (slitkows) , 
[email protected] 
, [email protected] 
, Voyer, Daniel , Bernier, Daniel 

Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12


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

Responses in-line

Thanks

Gyan




On Wed, Jan 29, 2025 at 8:28 AM Jorge Rabadan (Nokia) 
mailto:[email protected]>> wrote:
Hi Gyan,

Thanks for reviewing the draft.
Please see my comments in-line.

From: Gyan Mishra mailto:[email protected]>>
Date: Tuesday, January 28, 2025 at 9:02 PM
To: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Cc: 
[email protected]
 
mailto:[email protected]>>,
 [email protected] mailto:[email protected]>>, 
Voyer, Daniel mailto:[email protected]>>, Bernier, 
Daniel mailto:[email protected]>>
Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12


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.



 I support progressing this draft with some slight modifications below.

I have a very important addition to the draft that I think is pertinent that I 
would like to share.

Before I get to that I had a comment on the draft as it exists today.

The draft does not talk about underlay mismatch at the domain boundary which is 
very important.
[jorge] the procedures we're outlining are independent of the underlying 
infrastructure in each domain. I don’t think the draft needs to discuss any 
underlay aspects. If you think the scope should clarify that the procedures are 
independent of the underlay, we can do it in the introduction.

Gyan> yes please clarify in the introduction why the procedures are 
independent of the underlay and why.

There are a variety of different underlays and depending on the underlay type 
the solution maybe completely different as it would require a special gateway / 
IW feature specific to the two underlays that need to communicate with some 
type of translation.  Also the underlay protocol maybe a mismatch IPv4 on one 
side and IPv6 on the other and that poses a another problem.  In my initial 
email I mentioned inter-as opt-a because it is plain IP b

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-29 Thread Gyan Mishra 
Hi Jorge

Responses in-line

Thanks

Gyan





On Wed, Jan 29, 2025 at 8:28 AM Jorge Rabadan (Nokia) <
[email protected]> wrote:

> Hi Gyan,
>
> Thanks for reviewing the draft.
> Please see my comments in-line.
>
> From: Gyan Mishra 
> Date: Tuesday, January 28, 2025 at 9:02 PM
> To: Stephane Litkowski (slitkows) 
> Cc: [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, Voyer, Daniel , Bernier, Daniel <
> [email protected]>
> Subject: Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
> 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.
>
>
>
>  I support progressing this draft with some slight modifications below.
>
> I have a very important addition to the draft that I think is pertinent
> that I would like to share.
>
> Before I get to that I had a comment on the draft as it exists today.
>
> The draft does not talk about underlay mismatch at the domain boundary
> which is very important.
> *[jorge] the procedures we're outlining are independent of the underlying
> infrastructure in each domain. I don’t think the draft needs to discuss any
> underlay aspects. If you think the scope should clarify that the procedures
> are independent of the underlay, we can do it in the introduction.*
>

Gyan> yes please clarify in the introduction why the procedures are
independent of the underlay and why.

There are a variety of different underlays and depending on the underlay
type the solution maybe completely different as it would require a special
gateway / IW feature specific to the two underlays that need to communicate
with some type of translation.  Also the underlay protocol maybe a mismatch
IPv4 on one side and IPv6 on the other and that poses a another problem.
In my initial email I mentioned inter-as opt-a because it is plain IP back
to back VRF and the underlay transport IW is taken out of the picture and
only service IW is dealt with and it works seamlessly and is thus underlay
independent.

>
Example of draft for MPLS/SR-MPLS to SRv6 GW/IW uses a GW for transport
translation interworking
& service interworking. This is just one draft but their are many drafts on
interworking between technologies and both transport and service
interworking concepts.

https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking-15


> The draft does not talk about intra-domain scenario within a NVO VXLAN or
> MPLS / SR-MPLS / SRv6 fabric.
> *[jorge] the document defines a domain as follows:*
>
> *Domain: Two PEs are in the same domain if they are attached to the same
> tenant and the packets between them do not require a data path IP lookup
> (in the tenant space) in any intermediate router. A gateway PE is always
> configured with multiple DOMAIN-IDs. The domain boundaries are not limited
> to an Autonomous System or an IGP instance. The PEs in a domain can all be
> part of the same or different Autonomous System, and an Autonomous System
> can also contain multiple domains.*
>
> *So it is independent of the underlay “domains”. *
>

Domain is not the same think as underlay.  Domain is very generic.
When I say underlay I am talking about the technology used in the underlay
that may require some sort of translation or gateway interworking at the
transport underlay level.  Along the same lines for any technology their is
transport interworking which is for the underlay technology and service
interworking which is the overlay.

>
> Also this draft talks mostly all about the new D-PATH path attribute but
> does not talk about any details of the gateway function going from ISF to
> SAFI 128 and how that would work.  Is the RT reoriginated at the domain
> boundary as the other type of SAFI in either direction I am guessing maybe
> but the draft does not talk about it at all.
> *[jorge] Not sure what you mean by “from ISF to SAFI 128”. SAFI 128 routes
> are deined as ISF routes too in the document. Also if by “RT” you mean
> route targets, sections 5 and 8 describe how route targets are treated when
> routes are readvertised into the adjacent domain. *
>

Gyan> Sorry I should be more by ISF I meant L2 VPN EVPN and SAFI 128 I
meant IP VPN.  Yes by RT I mean route target.  So in a composite domain the
tenant VRFs are advertised in both EVPN & IP VPN and so they have identical
set of prefixes.  I would think the difference would be EVPN has MAC VRF
RT-2 so not identical but would be preferred due to longer matches. In
figure 9 it’s not clear is PE1 have EVPN and IPVPN peer to IPVPN? I did not
think that was possible?  In section 8 figure 8 the gateway device has a
safi-x peer and a safi-y peer and is able to propagate the prefixes from
any of the 4 NLRI let’s say safi-x is RT-2 / RT-5 and safi-y is IPVPN.  How
is that possible as the SAFI are different I wou

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-29 Thread Jorge Rabadan (Nokia) 
Hi Gyan,

Thanks for reviewing the draft.
Please see my comments in-line.

From: Gyan Mishra 
Date: Tuesday, January 28, 2025 at 9:02 PM
To: Stephane Litkowski (slitkows) 
Cc: [email protected] 
, [email protected] 
, Voyer, Daniel , Bernier, Daniel 

Subject: Re: [bess] Short new WGLC and IPR poll for 
draft-ietf-bess-evpn-ipvpn-interworking-12


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.



 I support progressing this draft with some slight modifications below.

I have a very important addition to the draft that I think is pertinent that I 
would like to share.

Before I get to that I had a comment on the draft as it exists today.

The draft does not talk about underlay mismatch at the domain boundary which is 
very important.
[jorge] the procedures we're outlining are independent of the underlying 
infrastructure in each domain. I don’t think the draft needs to discuss any 
underlay aspects. If you think the scope should clarify that the procedures are 
independent of the underlay, we can do it in the introduction.

The draft does not talk about intra-domain scenario within a NVO VXLAN or MPLS 
/ SR-MPLS / SRv6 fabric.
[jorge] the document defines a domain as follows:
Domain: Two PEs are in the same domain if they are attached to the same tenant 
and the packets between them do not require a data path IP lookup (in the 
tenant space) in any intermediate router. A gateway PE is always configured 
with multiple DOMAIN-IDs. The domain boundaries are not limited to an 
Autonomous System or an IGP instance. The PEs in a domain can all be part of 
the same or different Autonomous System, and an Autonomous System can also 
contain multiple domains.
So it is independent of the underlay “domains”.

Also this draft talks mostly all about the new D-PATH path attribute but does 
not talk about any details of the gateway function going from ISF to SAFI 128 
and how that would work.  Is the RT reoriginated at the domain boundary as the 
other type of SAFI in either direction I am guessing maybe but the draft does 
not talk about it at all.
[jorge] Not sure what you mean by “from ISF to SAFI 128”. SAFI 128 routes are 
deined as ISF routes too in the document. Also if by “RT” you mean route 
targets, sections 5 and 8 describe how route targets are treated when routes 
are readvertised into the adjacent domain.

I think this is critical to the progression of the draft.

My recommendation is to rename the draft to “EVPN to IPVPN  IW with D-PATH” 
would make more sense the way the draft is written.
[jorge] I'm not sure I agree. D-PATH is only one aspect. The spec also talks 
about Path attribute propagation, route selection across ISF routes, composite 
and gateway procedures, error handling, etc.

In the context of IPVPN & EVPN interaction and ISF and SAFI 128 there is a 
myriad of scenarios that can exist.

This is an extremely important topic as it comes up all the time for inter 
domain boundaries propagating  of L2 & L3 NLRI successfully across domain 
boundaries and within a domain a translation gateway.

In most all cases generally the composite PE, composite domain works seamlessly 
no issues as two ships in the night that don’t touch each other.

The complexity and possible loops that D-PATH solves the Gateway scenario.

A typical method which is very commonly done for eBGP peering  to propagate 
EVPN RT-5 prefixes to IP VPN.  One end of eBGP peering is NVO VXLAN/GENEVE ASBR 
(CE) and other end is MPLS IP VPN SAFI 128 PE.  The peering is inter-as opt-a 
back to back VRF IPv4 Unicast and IPv6 unicast peering. This works extremely 
well and both ends can be pretty much any kind of underlay data plane mismatch 
and you don’t require any special gateway transport or service interworking in 
the case of any of the following:

MPLS / SR-MPLS to SRv6.
MPLS / SR-MPLS to VXLAN
SRv6 to VXLAN

Stick diagram (eBGP)

 Inter-as opt-a

If the underlay  on core & dc is the same then you still have to use inter-as 
opt-a

ASBR (DC EVPN) <-> PE (Core IP VPN)
[jorge] I’m not sure if I follow. RFC4364 section 10 option a is IP-VRF to 
IP-VRF connectivity via subinterfaces, not tunnels. This spec does not 
introduce any procedures for option “a".

If you have underlay  mismatch then there is also IW/GW transport or service 
interworking

This same concept works with iBGP peering within the data center where the 
concept requires an intermediate router we can call a Gateway and can be solved 
by NVO VXLAN/GENEVE EVPN  on one end iBGP to  PE with IP VPN SAFI 128 PE.  The 
EVPN leaf-1  advertises the routes IPv4 unicast / IPv6 unicast routes RT-5 
prefixes to an intermediate router (GW) PE SAFI 128 -> VPNv4 / VPNv6 (RR) -> 
propagates VPNv4/VPNv6 to rest of fabric.

Stick diagram (iBGP)

leaf-1 <-> GW <-> (RR) <-> rest of fabric
[jorge] this falls under the gateway procedures in t

[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

2025-01-28 Thread Gyan Mishra 
 I support progressing this draft with some slight modifications below.

I have a very important addition to the draft that I think is pertinent
that I would like to share.

Before I get to that I had a comment on the draft as it exists today.

The draft does not talk about underlay mismatch at the domain boundary
which is very important.

The draft does not talk about intra-domain scenario within a NVO VXLAN or
MPLS / SR-MPLS / SRv6 fabric.

Also this draft talks mostly all about the new D-PATH path attribute but
does not talk about any details of the gateway function going from ISF to
SAFI 128 and how that would work.  Is the RT reoriginated at the domain
boundary as the other type of SAFI in either direction I am guessing maybe
but the draft does not talk about it at all.

I think this is critical to the progression of the draft.

My recommendation is to rename the draft to “EVPN to IPVPN  IW with D-PATH”
would make more sense the way the draft is written.

In the context of IPVPN & EVPN interaction and ISF and SAFI 128 there is a
myriad of scenarios that can exist.

This is an extremely important topic as it comes up all the time for inter
domain boundaries propagating  of L2 & L3 NLRI successfully across domain
boundaries and within a domain a translation gateway.

In most all cases generally the composite PE, composite domain works
seamlessly no issues as two ships in the night that don’t touch each other.

The complexity and possible loops that D-PATH solves the Gateway scenario.

A typical method which is very commonly done for eBGP peering  to propagate
EVPN RT-5 prefixes to IP VPN.  One end of eBGP peering is NVO VXLAN/GENEVE
ASBR (CE) and other end is MPLS IP VPN SAFI 128 PE.  The peering is
inter-as opt-a back to back VRF IPv4 Unicast and IPv6 unicast peering. This
works extremely well and both ends can be pretty much any kind of underlay
data plane mismatch and you don’t require any special gateway transport or
service interworking in the case of any of the following:

MPLS / SR-MPLS to SRv6.
MPLS / SR-MPLS to VXLAN
SRv6 to VXLAN

Stick diagram (eBGP)

 Inter-as opt-a

If the underlay  on core & dc is the same then you still have to use
inter-as opt-a

ASBR (DC EVPN) <-> PE (Core IP VPN)

If you have underlay  mismatch then there is also IW/GW transport or
service interworking

This same concept works with iBGP peering within the data center where the
concept requires an intermediate router we can call a Gateway and can be
solved by NVO VXLAN/GENEVE EVPN  on one end iBGP to  PE with IP VPN SAFI
128 PE.  The EVPN leaf-1  advertises the routes IPv4 unicast / IPv6 unicast
routes RT-5 prefixes to an intermediate router (GW) PE SAFI 128 -> VPNv4 /
VPNv6 (RR) -> propagates VPNv4/VPNv6 to rest of fabric.

Stick diagram (iBGP)

leaf-1 <-> GW <-> (RR) <-> rest of fabric

In both the eBGP & iBGP use case we are trying to get the EVPN mac VRF
routes reachability imported into SAFI 128 but all we need is the RT-5
prefixes and not the MAC VRF RT-2 host routes so the RT-5 summary suffices.


Using this solution it’s very simple and elegant and no loops.

Is it possible to add my comments to the draft.

Many Thanks!!

Gyan


On Mon, Jan 27, 2025 at 5:25 AM Stephane Litkowski (slitkows)  wrote:

> Hi,
>
>
>
> As draft-ietf-bess-evpn-ipvpn-interworking went through multiple
> discussions that seem to be closed now. We would like to do a new short
> WGLC of 1-week to gather any additional comment before we move forward with
> the draft.
>
>
>
> The WGLC poll starts today and will end on 2/3.
>
>
>
> Similarly, as the last IPR poll was done a long time back. We are also
> polling for knowledge of any undisclosed IPR that applies to this document
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
>
>
> Thank you
>
>
>
> Brgds,
>
>
>
>
>
> Stephane, Matthew, Jeffrey (BESS chairs)
>
>
>
>
>
>
> ___
> BESS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]