Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Susan Hares]

Gyan: 

 

+1 to Roberts comments.Robert, Linda and I have taken this topic off line.  
If you are interested, ping. 

 

Sue 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Tuesday, March 31, 2020 9:52 PM
To: Robert Raszuk
Cc: i...@ietf.org; Linda Dunbar; Huaimo Chen; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using 
SDWAN SAFI to encode SDWAN Instance ID in the NLRI

 

 

 

Thanks Robert!! 

 

For me to really comprehend I have to have to put the tire to the road and test 
in my Dev lab.  Any caveats with Cisco XR?  Ping me off list on cisco specific 
reply.

 

Kind regards

 

Gyan

 

On Tue, Mar 31, 2020 at 6:43 AM Robert Raszuk  wrote:

Hi Gyan,

 

As topic 1 - Extended community which is used for filtering incoming updates 
can be configured under BGP AF - there is nothing in the protocol which 
mandates that such RTs need to be configured under VRF section. 

 

As of topic 2 - This is huge misconception by many people who think that SAFI 
128 requires MPLS transport. So let me clearly state that SAFI 128 application 
can happily run for many years now over pure IP transport. VPN labels and 
transport paradigm are completely separate.. Hint: RFC7510 or RFC4023. Moreover 
- let me also state that MPLS transport does not bring any benefits other then 
few bits savings in the packet header as compared with say IPv4 transport. 
Contrary it costs a lot of complexity in the control plane and forwarding 
planes of the network elements. 

 

Thx,
R.

 

 

 

On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra  wrote:

 

Robert  & Linda 

 

Sorry to inject myself into this thread.

 

You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP control plane 
service layer overlay from PE to RR. Agreed.  By default all PEs including the 
SDWAN PE have RT Filtering enabled by default and only import the RT into the 
VRF at the control plane level if the VRF is configured with RT advertised by 
the RR is being imported by the PE, if not the SAFI 128 prefixes are dropped.  
So I understand that the BGP updates is a control plane function, but how would 
the routes get imported by the PE if the VRF is not defined on the PE.  RFC 
4684 RTC capability allows only the RTs imported on the PE to be advertised by 
the RR to reduced the SAFI 128 route advertised by the RR that would result in 
being filtered on the PE.

 

So how would that work using SAFI 128 RT to provide the network slicing for 
SDWAN without VRF configured.

 

Also you mentioned that SAFI 128 L3 vpn services overlay can run over any 
underlay and that does not have to be MPLS based.  I know SAFI 128 works with 
SR-MPLS but there you are reusing the MPLS data plane.  With SRv6 due to PM 
draft signaling by egress PE for end.dx instantiation, so there is not any 
service label necessary as is with MPLS and thus SAFI 128 works with SRv6.

 

How would SAFI 128 work with IP underlay used with SDWAN?

 

Even with  inter-as option b c ab, with BGP LU you do have topmost label which 
is via BGP labeled unicast.  For inter as options if SAFI128 would work w/o BGP 
LU you could just run SAFI 128 over IP.  I have never tried but I think the 
control plane would come up but the data plane would be broken.

 

Kind regards 

 

Gyan 

 

On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar  wrote:

Robert, 

 

Want to confirm the following two points with you. Do I interpret your words 
correctly? 

 

*   If a CPE supports traditional VPN with multiple VRFs, and supports 
multiple SDWAN instances, the traditional VRF configuration is still same which 
are carried by BGP Route Target Extended community.  
*   For the SDWAN Instances supported by the same CPE, we can use Extended 
Community with a different name (say SDWAN Target ID). When the SDWAN Target ID 
is used, the SAFI 128 can be used for routes for the SDWAN instance,  with the 
exception that the label in the NLRI is not the MPLS label carried by the data 
packets .  

 

Thank you. 

 

Linda Dunbar

From: Robert Raszuk  
Sent: Tuesday, March 24, 2020 3:32 AM
To: Linda Dunbar 
Cc: Huaimo Chen ; i...@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using 
SDWAN SAFI to encode SDWAN Instance ID in the NLRI

 

Hi Linda,

 

Nope you do not need VRFs. RT construct works at the control plane level. VRF 
may be useful for traffic separation purposes on multitenant CPEs or if you 
would like to relax requirements for unique IP across SDWAN sites - but not a 
must otherwise. 

 

My main point was  that BGP SAFI 128 gives you for free transport for multiple 
routing contexts so why not leverage it as is? 

 

Moreover you may suddenly also discover that RTC (RFC4684) is your SDWAN friend 
too. 

 

Many thx,
R.

 

 

 

 

On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar  wrote:

Robert, 

 

Thank you very much for the feedback. 

 

If using your suggested Route Target 

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Gyan Mishra]

Thanks Robert!! 

For me to really comprehend I have to have to put the tire to the road and
test in my Dev lab.  Any caveats with Cisco XR?  Ping me off list on cisco
specific reply.

Kind regards

Gyan

On Tue, Mar 31, 2020 at 6:43 AM Robert Raszuk  wrote:

> Hi Gyan,
>
> As topic 1 - Extended community which is used for filtering incoming
> updates can be configured under BGP AF - there is nothing in the protocol
> which mandates that such RTs need to be configured under VRF section.
>
> As of topic 2 - This is huge misconception by many people who think that
> SAFI 128 requires MPLS transport. So let me clearly state that SAFI 128
> application can happily run for many years now over pure IP transport. VPN
> labels and transport paradigm are completely separate. Hint: RFC7510 or
> RFC4023. Moreover - let me also state that MPLS transport does not bring
> any benefits other then few bits savings in the packet header as compared
> with say IPv4 transport. Contrary it costs a lot of complexity in the
> control plane and forwarding planes of the network elements.
>
> Thx,
> R.
>
>
>
> On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra  wrote:
>
>>
>> Robert  & Linda
>>
>> Sorry to inject myself into this thread.
>>
>> You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP control
>> plane service layer overlay from PE to RR. Agreed.  By default all PEs
>> including the SDWAN PE have RT Filtering enabled by default and only import
>> the RT into the VRF at the control plane level if the VRF is configured
>> with RT advertised by the RR is being imported by the PE, if not the SAFI
>> 128 prefixes are dropped.  So I understand that the BGP updates is a
>> control plane function, but how would the routes get imported by the PE if
>> the VRF is not defined on the PE.  RFC 4684 RTC capability allows only the
>> RTs imported on the PE to be advertised by the RR to reduced the SAFI 128
>> route advertised by the RR that would result in being filtered on the PE..
>>
>> So how would that work using SAFI 128 RT to provide the network slicing
>> for SDWAN without VRF configured.
>>
>> Also you mentioned that SAFI 128 L3 vpn services overlay can run over any
>> underlay and that does not have to be MPLS based.  I know SAFI 128 works
>> with SR-MPLS but there you are reusing the MPLS data plane.  With SRv6 due
>> to PM draft signaling by egress PE for end.dx instantiation, so there is
>> not any service label necessary as is with MPLS and thus SAFI 128 works
>> with SRv6.
>>
>> How would SAFI 128 work with IP underlay used with SDWAN?
>>
>> Even with  inter-as option b c ab, with BGP LU you do have topmost label
>> which is via BGP labeled unicast.  For inter as options if SAFI128 would
>> work w/o BGP LU you could just run SAFI 128 over IP.  I have never tried
>> but I think the control plane would come up but the data plane would be
>> broken.
>>
>> Kind regards
>>
>> Gyan
>>
>> On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar 
>> wrote:
>>
>>> Robert,
>>>
>>>
>>>
>>> Want to confirm the following two points with you. Do I interpret your
>>> words correctly?
>>>
>>>
>>>
>>>- If a CPE supports traditional VPN with multiple VRFs, and supports
>>>multiple SDWAN instances, the traditional VRF configuration is still same
>>>which are carried by BGP Route Target Extended community.
>>>- For the SDWAN Instances supported by the same CPE, we can use
>>>Extended Community with a different name (say SDWAN Target ID). When the
>>>SDWAN Target ID is used, the SAFI 128 can be used for routes for the 
>>> SDWAN
>>>instance,  with the exception that the label in the NLRI is not the MPLS
>>>label carried by the data packets .
>>>
>>>
>>>
>>> Thank you.
>>>
>>>
>>>
>>> Linda Dunbar
>>>
>>> *From:* Robert Raszuk 
>>> *Sent:* Tuesday, March 24, 2020 3:32 AM
>>> *To:* Linda Dunbar 
>>> *Cc:* Huaimo Chen ; i...@ietf.org;
>>> bess@ietf.org
>>> *Subject:* Re: [Idr] Seeking feedback of
>>> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance
>>> ID in the NLRI
>>>
>>>
>>>
>>> Hi Linda,
>>>
>>>
>>>
>>> Nope you do not need VRFs. RT construct works at the control plane
>>> level. VRF may be useful for traffic separation purposes on
>>> multitenant CPEs or if you would like to relax requirements for unique IP
>>> across SDWAN sites - but not a must otherwise.
>>>
>>>
>>>
>>> My main point was  that BGP SAFI 128 gives you for free transport for
>>> multiple routing contexts so why not leverage it as is?
>>>
>>>
>>>
>>> Moreover you may suddenly also discover that RTC (RFC4684) is your
>>> SDWAN friend too.
>>>
>>>
>>>
>>> Many thx,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
>>> wrote:
>>>
>>> Robert,
>>>
>>>
>>>
>>> Thank you very much for the feedback.
>>>
>>>
>>>
>>> If using your suggested Route Target approach to represent the SDWAN
>>> Instance ID, does it mean that a SDWAN Edge has to use the same approach to
>>> configure the VRF for 

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Gyan,

As topic 1 - Extended community which is used for filtering incoming
updates can be configured under BGP AF - there is nothing in the protocol
which mandates that such RTs need to be configured under VRF section.

As of topic 2 - This is huge misconception by many people who think that
SAFI 128 requires MPLS transport. So let me clearly state that SAFI 128
application can happily run for many years now over pure IP transport. VPN
labels and transport paradigm are completely separate. Hint: RFC7510 or
RFC4023. Moreover - let me also state that MPLS transport does not bring
any benefits other then few bits savings in the packet header as compared
with say IPv4 transport. Contrary it costs a lot of complexity in the
control plane and forwarding planes of the network elements.

Thx,
R.



On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra  wrote:

>
> Robert  & Linda
>
> Sorry to inject myself into this thread.
>
> You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP control
> plane service layer overlay from PE to RR. Agreed.  By default all PEs
> including the SDWAN PE have RT Filtering enabled by default and only import
> the RT into the VRF at the control plane level if the VRF is configured
> with RT advertised by the RR is being imported by the PE, if not the SAFI
> 128 prefixes are dropped.  So I understand that the BGP updates is a
> control plane function, but how would the routes get imported by the PE if
> the VRF is not defined on the PE.  RFC 4684 RTC capability allows only the
> RTs imported on the PE to be advertised by the RR to reduced the SAFI 128
> route advertised by the RR that would result in being filtered on the PE.
>
> So how would that work using SAFI 128 RT to provide the network slicing
> for SDWAN without VRF configured.
>
> Also you mentioned that SAFI 128 L3 vpn services overlay can run over any
> underlay and that does not have to be MPLS based.  I know SAFI 128 works
> with SR-MPLS but there you are reusing the MPLS data plane.  With SRv6 due
> to PM draft signaling by egress PE for end.dx instantiation, so there is
> not any service label necessary as is with MPLS and thus SAFI 128 works
> with SRv6.
>
> How would SAFI 128 work with IP underlay used with SDWAN?
>
> Even with  inter-as option b c ab, with BGP LU you do have topmost label
> which is via BGP labeled unicast.  For inter as options if SAFI128 would
> work w/o BGP LU you could just run SAFI 128 over IP.  I have never tried
> but I think the control plane would come up but the data plane would be
> broken.
>
> Kind regards
>
> Gyan
>
> On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar 
> wrote:
>
>> Robert,
>>
>>
>>
>> Want to confirm the following two points with you. Do I interpret your
>> words correctly?
>>
>>
>>
>>- If a CPE supports traditional VPN with multiple VRFs, and supports
>>multiple SDWAN instances, the traditional VRF configuration is still same
>>which are carried by BGP Route Target Extended community.
>>- For the SDWAN Instances supported by the same CPE, we can use
>>Extended Community with a different name (say SDWAN Target ID). When the
>>SDWAN Target ID is used, the SAFI 128 can be used for routes for the SDWAN
>>instance,  with the exception that the label in the NLRI is not the MPLS
>>label carried by the data packets .
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Linda Dunbar
>>
>> *From:* Robert Raszuk 
>> *Sent:* Tuesday, March 24, 2020 3:32 AM
>> *To:* Linda Dunbar 
>> *Cc:* Huaimo Chen ; i...@ietf.org;
>> bess@ietf.org
>> *Subject:* Re: [Idr] Seeking feedback of
>> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance
>> ID in the NLRI
>>
>>
>>
>> Hi Linda,
>>
>>
>>
>> Nope you do not need VRFs. RT construct works at the control plane level..
>> VRF may be useful for traffic separation purposes on multitenant CPEs or if
>> you would like to relax requirements for unique IP across SDWAN sites - but
>> not a must otherwise.
>>
>>
>>
>> My main point was  that BGP SAFI 128 gives you for free transport for
>> multiple routing contexts so why not leverage it as is?
>>
>>
>>
>> Moreover you may suddenly also discover that RTC (RFC4684) is your
>> SDWAN friend too.
>>
>>
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
>> wrote:
>>
>> Robert,
>>
>>
>>
>> Thank you very much for the feedback.
>>
>>
>>
>> If using your suggested Route Target approach to represent the SDWAN
>> Instance ID, does it mean that a SDWAN Edge has to use the same approach to
>> configure the VRF for SDWAN instances?
>>
>> If the edge node supports both traditional VPN and SDWAN, will it cause
>> confusion for RT to represent both?
>>
>>
>>
>> RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is
>> encoded in the MP_REACH_NLRI Path Attribute.
>>
>>
>>
>> What do you mean by saying “different name to Route target(s) carried in
>> the SAFI 128”?
>>
>> Do you mean having a different name (say SDWAN_Target) 

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Gyan Mishra]

Robert  & Linda

Sorry to inject myself into this thread.

You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP control
plane service layer overlay from PE to RR. Agreed.  By default all PEs
including the SDWAN PE have RT Filtering enabled by default and only import
the RT into the VRF at the control plane level if the VRF is configured
with RT advertised by the RR is being imported by the PE, if not the SAFI
128 prefixes are dropped.  So I understand that the BGP updates is a
control plane function, but how would the routes get imported by the PE if
the VRF is not defined on the PE.  RFC 4684 RTC capability allows only the
RTs imported on the PE to be advertised by the RR to reduced the SAFI 128
route advertised by the RR that would result in being filtered on the PE.

So how would that work using SAFI 128 RT to provide the network slicing for
SDWAN without VRF configured.

Also you mentioned that SAFI 128 L3 vpn services overlay can run over any
underlay and that does not have to be MPLS based.  I know SAFI 128 works
with SR-MPLS but there you are reusing the MPLS data plane.  With SRv6 due
to PM draft signaling by egress PE for end.dx instantiation, so there is
not any service label necessary as is with MPLS and thus SAFI 128 works
with SRv6.

How would SAFI 128 work with IP underlay used with SDWAN?

Even with  inter-as option b c ab, with BGP LU you do have topmost label
which is via BGP labeled unicast.  For inter as options if SAFI128 would
work w/o BGP LU you could just run SAFI 128 over IP.  I have never tried
but I think the control plane would come up but the data plane would be
broken.

Kind regards

Gyan

On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Want to confirm the following two points with you. Do I interpret your
> words correctly?
>
>
>
>- If a CPE supports traditional VPN with multiple VRFs, and supports
>multiple SDWAN instances, the traditional VRF configuration is still same
>which are carried by BGP Route Target Extended community.
>- For the SDWAN Instances supported by the same CPE, we can use
>Extended Community with a different name (say SDWAN Target ID). When the
>SDWAN Target ID is used, the SAFI 128 can be used for routes for the SDWAN
>instance,  with the exception that the label in the NLRI is not the MPLS
>label carried by the data packets .
>
>
>
> Thank you.
>
>
>
> Linda Dunbar
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, March 24, 2020 3:32 AM
> *To:* Linda Dunbar 
> *Cc:* Huaimo Chen ; i...@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi
> using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
>
>
>
> Hi Linda,
>
>
>
> Nope you do not need VRFs. RT construct works at the control plane level.
> VRF may be useful for traffic separation purposes on multitenant CPEs or if
> you would like to relax requirements for unique IP across SDWAN sites - but
> not a must otherwise.
>
>
>
> My main point was  that BGP SAFI 128 gives you for free transport for
> multiple routing contexts so why not leverage it as is?
>
>
>
> Moreover you may suddenly also discover that RTC (RFC4684) is your
> SDWAN friend too.
>
>
>
> Many thx,
> R.
>
>
>
>
>
>
>
>
>
> On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
> wrote:
>
> Robert,
>
>
>
> Thank you very much for the feedback.
>
>
>
> If using your suggested Route Target approach to represent the SDWAN
> Instance ID, does it mean that a SDWAN Edge has to use the same approach to
> configure the VRF for SDWAN instances?
>
> If the edge node supports both traditional VPN and SDWAN, will it cause
> confusion for RT to represent both?
>
>
>
> RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is
> encoded in the MP_REACH_NLRI Path Attribute.
>
>
>
> What do you mean by saying “different name to Route target(s) carried in
> the SAFI 128”?
>
> Do you mean having a different name (say SDWAN_Target) in
> Extended_Communities Path Attribute, and have MP_REACH_NLRI Path Attribute
> including the SAFI 128?
>
>
>
> SDWAN Instance ID is for the control Plane, not to be carried by the data
> packets. SAFI 128 for VPN has the Label encoded in the NLRI field that is
> to be carried by the data packets. But SDWAN Instance ID is not carried by
> the Data Packets. Is it correct?
>
>
>
> Thank you.
>
> Linda
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, March 23, 2020 2:28 PM
> *To:* Linda Dunbar 
> *Cc:* Huaimo Chen ; i...@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi
> using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
>
>
>
> Hi Linda,
>
>
>
> I think you are mixing data plane and control plane.
>
>
>
> In SDWAN data plane is of no issue as you are interconnecting sites in a
> given VPN over mesh of secure tunnels.
>
>
>
> You are asking how to keep control plane separate between VPN instances.
> This is precisely what RFC4364 does already and RT 

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Linda Dunbar]

Robert,

Want to confirm the following two points with you. Do I interpret your words 
correctly?


  *   If a CPE supports traditional VPN with multiple VRFs, and supports 
multiple SDWAN instances, the traditional VRF configuration is still same which 
are carried by BGP Route Target Extended community.
  *   For the SDWAN Instances supported by the same CPE, we can use Extended 
Community with a different name (say SDWAN Target ID). When the SDWAN Target ID 
is used, the SAFI 128 can be used for routes for the SDWAN instance,  with the 
exception that the label in the NLRI is not the MPLS label carried by the data 
packets .

Thank you.

Linda Dunbar
From: Robert Raszuk 
Sent: Tuesday, March 24, 2020 3:32 AM
To: Linda Dunbar 
Cc: Huaimo Chen ; i...@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using 
SDWAN SAFI to encode SDWAN Instance ID in the NLRI

Hi Linda,

Nope you do not need VRFs. RT construct works at the control plane level. VRF 
may be useful for traffic separation purposes on multitenant CPEs or if you 
would like to relax requirements for unique IP across SDWAN sites - but not a 
must otherwise.

My main point was  that BGP SAFI 128 gives you for free transport for multiple 
routing contexts so why not leverage it as is?

Moreover you may suddenly also discover that RTC (RFC4684) is your SDWAN friend 
too.

Many thx,
R.




On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Thank you very much for the feedback.

If using your suggested Route Target approach to represent the SDWAN Instance 
ID, does it mean that a SDWAN Edge has to use the same approach to configure 
the VRF for SDWAN instances?
If the edge node supports both traditional VPN and SDWAN, will it cause 
confusion for RT to represent both?

RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is encoded 
in the MP_REACH_NLRI Path Attribute.

What do you mean by saying “different name to Route target(s) carried in the 
SAFI 128”?
Do you mean having a different name (say SDWAN_Target) in Extended_Communities 
Path Attribute, and have MP_REACH_NLRI Path Attribute including the SAFI 128?

SDWAN Instance ID is for the control Plane, not to be carried by the data 
packets. SAFI 128 for VPN has the Label encoded in the NLRI field that is to be 
carried by the data packets. But SDWAN Instance ID is not carried by the Data 
Packets. Is it correct?

Thank you.
Linda




From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, March 23, 2020 2:28 PM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
i...@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using 
SDWAN SAFI to encode SDWAN Instance ID in the NLRI

Hi Linda,

I think you are mixing data plane and control plane.

In SDWAN data plane is of no issue as you are interconnecting sites in a given 
VPN over mesh of secure tunnels.

You are asking how to keep control plane separate between VPN instances. This 
is precisely what RFC4364 does already and RT import/export is used to indicate 
the instance which given set of reachability belongs. Why to reinvent the wheel 
and do something new just for the heck of it :) ?

To be original you can at best invent a different name to Route target(s) 
carried in the SAFI 128 but let's keep the mechanism the same. That would be my 
suggestion.

Kind regards,
R.

PS. While this is obvious for some many folks are still confused. RFC4364 does 
not need to run over MPLS data plane. It can run over IPSec or over DTLS or 
over UDP/IP just fine.

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
IDR experts:

SDWAN is an overlay network arching over multiple types of networks. A SDWAN 
edge node may need to map client traffic to different SDWAN network instances 
(or segmentations).
It might not be feasible to use the AS number in the BGP message to 
differentiate the SDWAN network instances as multiple SDWAN instances may share 
the same AS number.

We would like to hear feedback from IDR group on using similar method as  
Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance ID to  
prefixes.

When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI [RFC8277] 
as:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length | Label |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Linda,

Nope you do not need VRFs. RT construct works at the control plane level.
VRF may be useful for traffic separation purposes on multitenant CPEs or if
you would like to relax requirements for unique IP across SDWAN sites - but
not a must otherwise.

My main point was  that BGP SAFI 128 gives you for free transport for
multiple routing contexts so why not leverage it as is?

Moreover you may suddenly also discover that RTC (RFC4684) is your
SDWAN friend too.

Many thx,
R.




On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Thank you very much for the feedback.
>
>
>
> If using your suggested Route Target approach to represent the SDWAN
> Instance ID, does it mean that a SDWAN Edge has to use the same approach to
> configure the VRF for SDWAN instances?
>
> If the edge node supports both traditional VPN and SDWAN, will it cause
> confusion for RT to represent both?
>
>
>
> RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is
> encoded in the MP_REACH_NLRI Path Attribute.
>
>
>
> What do you mean by saying “different name to Route target(s) carried in
> the SAFI 128”?
>
> Do you mean having a different name (say SDWAN_Target) in
> Extended_Communities Path Attribute, and have MP_REACH_NLRI Path Attribute
> including the SAFI 128?
>
>
>
> SDWAN Instance ID is for the control Plane, not to be carried by the data
> packets. SAFI 128 for VPN has the Label encoded in the NLRI field that is
> to be carried by the data packets. But SDWAN Instance ID is not carried by
> the Data Packets. Is it correct?
>
>
>
> Thank you.
>
> Linda
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, March 23, 2020 2:28 PM
> *To:* Linda Dunbar 
> *Cc:* Huaimo Chen ; i...@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi
> using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
>
>
>
> Hi Linda,
>
>
>
> I think you are mixing data plane and control plane.
>
>
>
> In SDWAN data plane is of no issue as you are interconnecting sites in a
> given VPN over mesh of secure tunnels.
>
>
>
> You are asking how to keep control plane separate between VPN instances.
> This is precisely what RFC4364 does already and RT import/export is used to
> indicate the instance which given set of reachability belongs. Why to
> reinvent the wheel and do something new just for the heck of it :) ?
>
>
>
> To be original you can at best invent a different name to Route target(s)
> carried in the SAFI 128 but let's keep the mechanism the same. That would
> be my suggestion.
>
>
>
> Kind regards,
>
> R.
>
>
>
> PS. While this is obvious for some many folks are still confused. RFC4364
> does not need to run over MPLS data plane. It can run over IPSec or over
> DTLS or over UDP/IP just fine.
>
>
>
> On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
> wrote:
>
> IDR experts:
>
>
>
> SDWAN is an overlay network arching over multiple types of networks. A
> SDWAN edge node may need to map client traffic to different SDWAN network
> instances (or segmentations).
>
> It might not be feasible to use the AS number in the BGP message to
> differentiate the SDWAN network instances as multiple SDWAN instances may
> share the same AS number.
>
>
>
> We would like to hear feedback from IDR group on using similar method as
>  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance
> ID to  prefixes.
>
>
>
> When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI
> [RFC8277] as:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length | Label |Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>Figure 2: NLRI with One Label
>
>
>
> We would like to  propose the SDWAN Instance ID being encoded in the Label
> field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length |  SDWAN Instance ID (Label)|Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> NLRI with SDWAN Instance ID.
>
>
>
> Greatly 

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Linda Dunbar]

Robert,

Thank you very much for the feedback.

If using your suggested Route Target approach to represent the SDWAN Instance 
ID, does it mean that a SDWAN Edge has to use the same approach to configure 
the VRF for SDWAN instances?
If the edge node supports both traditional VPN and SDWAN, will it cause 
confusion for RT to represent both?

RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is encoded 
in the MP_REACH_NLRI Path Attribute.

What do you mean by saying “different name to Route target(s) carried in the 
SAFI 128”?
Do you mean having a different name (say SDWAN_Target) in Extended_Communities 
Path Attribute, and have MP_REACH_NLRI Path Attribute including the SAFI 128?

SDWAN Instance ID is for the control Plane, not to be carried by the data 
packets. SAFI 128 for VPN has the Label encoded in the NLRI field that is to be 
carried by the data packets. But SDWAN Instance ID is not carried by the Data 
Packets. Is it correct?

Thank you.
Linda




From: Robert Raszuk 
Sent: Monday, March 23, 2020 2:28 PM
To: Linda Dunbar 
Cc: Huaimo Chen ; i...@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using 
SDWAN SAFI to encode SDWAN Instance ID in the NLRI

Hi Linda,

I think you are mixing data plane and control plane.

In SDWAN data plane is of no issue as you are interconnecting sites in a given 
VPN over mesh of secure tunnels.

You are asking how to keep control plane separate between VPN instances. This 
is precisely what RFC4364 does already and RT import/export is used to indicate 
the instance which given set of reachability belongs. Why to reinvent the wheel 
and do something new just for the heck of it :) ?

To be original you can at best invent a different name to Route target(s) 
carried in the SAFI 128 but let's keep the mechanism the same. That would be my 
suggestion.

Kind regards,
R.

PS. While this is obvious for some many folks are still confused. RFC4364 does 
not need to run over MPLS data plane. It can run over IPSec or over DTLS or 
over UDP/IP just fine.

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
IDR experts:

SDWAN is an overlay network arching over multiple types of networks. A SDWAN 
edge node may need to map client traffic to different SDWAN network instances 
(or segmentations).
It might not be feasible to use the AS number in the BGP message to 
differentiate the SDWAN network instances as multiple SDWAN instances may share 
the same AS number.

We would like to hear feedback from IDR group on using similar method as  
Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance ID to  
prefixes.

When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI [RFC8277] 
as:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length | Label |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: NLRI with One Label

We would like to  propose the SDWAN Instance ID being encoded in the Label 
field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length |  SDWAN Instance ID (Label)|Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NLRI with SDWAN Instance ID.

Greatly appreciate any comments or other suggestions..

Thank you,
Linda Dunbar

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Monday, March 23, 2020 9:14 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
i...@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?

Hi Linda,

It seems that using another SAFI is a possible solution.

Best Regards,
Huaimo

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Friday, March 20, 2020 12:54 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
i...@ietf.org mailto:i...@ietf.org>>
Cc: 

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Linda,

I think you are mixing data plane and control plane.

In SDWAN data plane is of no issue as you are interconnecting sites in a
given VPN over mesh of secure tunnels.

You are asking how to keep control plane separate between VPN instances.
This is precisely what RFC4364 does already and RT import/export is used to
indicate the instance which given set of reachability belongs. Why to
reinvent the wheel and do something new just for the heck of it :) ?

To be original you can at best invent a different name to Route target(s)
carried in the SAFI 128 but let's keep the mechanism the same. That would
be my suggestion.

Kind regards,
R.

PS. While this is obvious for some many folks are still confused. RFC4364
does not need to run over MPLS data plane. It can run over IPSec or over
DTLS or over UDP/IP just fine.

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
wrote:

> IDR experts:
>
>
>
> SDWAN is an overlay network arching over multiple types of networks. A
> SDWAN edge node may need to map client traffic to different SDWAN network
> instances (or segmentations).
>
> It might not be feasible to use the AS number in the BGP message to
> differentiate the SDWAN network instances as multiple SDWAN instances may
> share the same AS number.
>
>
>
> We would like to hear feedback from IDR group on using similar method as
>  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance
> ID to  prefixes.
>
>
>
> When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI
> [RFC8277] as:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length | Label |Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>Figure 2: NLRI with One Label
>
>
>
> We would like to  propose the SDWAN Instance ID being encoded in the Label
> field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length |  SDWAN Instance ID (Label)|Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> NLRI with SDWAN Instance ID.
>
>
>
> Greatly appreciate any comments or other suggestions..
>
>
>
> Thank you,
>
> Linda Dunbar
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Monday, March 23, 2020 9:14 AM
> *To:* Linda Dunbar ; i...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Hi Linda,
>
>
>
> It seems that using another SAFI is a possible solution.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Linda Dunbar 
> *Sent:* Friday, March 20, 2020 12:54 AM
> *To:* Huaimo Chen ; i...@ietf.org 
> *Cc:* bess@ietf.org 
> *Subject:* RE: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Huaimo,
>
>
>
> Thank you very much for the suggestion.
>
> Do you mean using the similar approach as VPN Label carried by NLRI Path
> Attribute [RFC8277] for SDWAN Segmentation Identifier?
>
> If yes, the UPDATE message should not use the MPLS VPN SAFI (=128) to
> avoid confusion, right?
>
>
>
> Linda
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Thursday, March 19, 2020 6:45 PM
> *To:* Linda Dunbar ; i...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Hi Linda,
>
>
>
> It seems that a label may be used as an "Identifier" to differentiate
> SD-WAN Segmentation.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Idr  on behalf of Linda Dunbar <
> linda.dun...@futurewei.com>
> *Sent:* Thursday, March 19, 2020 1:22 PM
> *To:* i...@ietf.org 
> *Cc:* bess@ietf.org 
> *Subject:* [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> BGP Experts,
>
>
>
> Do you