Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Aissaoui, Mustapha (Nokia - CA/Ottawa)]

Rajesh,
Also you can change the service SID for a subset of prefixes using a policy, to 
apply a flex-algo for example, but you do not want to change the next-hop for 
each new service SID.

Mustapha.

From: spring  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Monday, July 19, 2021 9:47 AM
To: Rajesh M ; Rajesh M 
; Ketan Talaulikar (ketant) 
; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) 
; rob...@raszuk.net; bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; Srihari Sangli ; 
Shraddha Hegde ; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Rajesh,

The draft is written so that the next-hop address MAY be covered by the 
locator, but there are cases in which the next-hop address is not part of the 
locator prefix, and there are implementations already allowing that, so I don't 
agree the document should mandate what you are suggesting.

Thanks.
Jorge

From: Rajesh M mailto:mraj...@juniper.net>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>,
 Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>, 
gdawra.i...@gmail.com 
mailto:gdawra.i...@gmail.com>>, Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>, 
rob...@raszuk.net 
mailto:rob...@raszuk.net>>, 
bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>, Rabadan, Jorge 
(Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Cc: spr...@ietf.org 
mailto:spr...@ietf.org>>, b...@ans.net 
mailto:b...@ans.net>>, Shraddha Hegde 
mailto:shrad...@juniper.net>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Srihari Sangli mailto:ssan...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Hi Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com; 
jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org
Subject: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.

2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully 
resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).


Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line 
with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding 
locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh


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

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Gaurav Dawra]

+1 on Jorge and Robert. I don’t think we should mandate.

Gaurav

> On Jul 19, 2021, at 6:52 AM, Robert Raszuk  wrote:
> 
> 
> I agree with Jorge.. 
> 
> In fact I find the tone of the comment to be very inappropriate: 
> 
> > In case of best effort/flex algo we must mandate user to set corresponding 
> > locator as BGP nexthop for srv6 routes.
> 
> No we MUST not mandate anything to the user. 
> 
> We MUST provide flexibility to address all deployment cases user may have. 
> 
> Best,
> R.
> 
> 
> 
>> On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) 
>>  wrote:
>> Hi Rajesh,
>> 
>>  
>> 
>> The draft is written so that the next-hop address MAY be covered by the 
>> locator, but there are cases in which the next-hop address is not part of 
>> the locator prefix, and there are implementations already allowing that, so 
>> I don’t agree the document should mandate what you are suggesting.
>> 
>>  
>> 
>> Thanks.
>> 
>> Jorge
>> 
>>  
>> 
>> From: Rajesh M 
>> Date: Monday, July 19, 2021 at 3:24 PM
>> To: Rajesh M , Ketan Talaulikar 
>> (ketant) , gdawra.i...@gmail.com , 
>> Clarence Filsfils (cfilsfil) , rob...@raszuk.net 
>> , bruno.decra...@orange.com , 
>> Rabadan, Jorge (Nokia - US/Mountain View) 
>> Cc: spr...@ietf.org , b...@ans.net , Shraddha 
>> Hegde , bess@ietf.org , Srihari Sangli 
>> 
>> Subject: RE: SRv6 BGP based Overlay Services 
>> (draft-ietf-bess-srv6-services-07)
>> 
>> Hi Authors,
>> 
>>  
>> 
>> Please respond.
>> 
>>  
>> 
>> Thanks
>> 
>> Rajesh
>> 
>>  
>> 
>>  
>> 
>> Juniper Business Use Only
>> From: spring  On Behalf Of Rajesh M
>> Sent: Thursday, July 15, 2021 4:36 PM
>> To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com; 
>> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net; 
>> bruno.decra...@orange.com; jorge.raba...@nokia.com
>> Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
>> bess@ietf.org
>> Subject: [spring] SRv6 BGP based Overlay Services 
>> (draft-ietf-bess-srv6-services-07)
>> 
>>  
>> 
>> [External Email. Be cautious of content]
>> 
>>  
>> 
>> Hi All,
>> 
>>  
>> 
>> As per this draft, this is how resolution must work.
>> 
>>  
>> 
>> 1)For Non Intent service Route:
>> 
>> if BGP next hop is not reachable return.
>> 
>> Resolve SRv6 Service SID for forwarding.
>> 
>>  
>> 
>> 2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
>> 
>> BGP next hop is not reachable return.
>> 
>> Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if 
>> successfully resolves then return.
>> 
>> Resolve BGP next hop for forwarding (in case above is not success).
>> 
>>  
>> 
>>  
>> 
>> Using Service SID (overlay),for resolution is definitely not recommended.
>> 
>>  
>> 
>> Instead in case of srv6, we always resolve on BGP nexthop. This will be in 
>> line with BGP legacy.
>> 
>> In case of best effort/flex algo we must mandate user to set corresponding 
>> locator as BGP nexthop for srv6 routes.
>> 
>> I think this is a reasonable mandate.
>> 
>>  
>> 
>> Thanks
>> 
>> Rajesh
>> 
>>  
>> 
>> Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Rajesh M]

Hi All,

For best effort service, flex algo - Resolve SRv6 Service SID for forwarding.
For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.

There is no unification here, it's better to unify.
Any other solution is OK.

Thanks
Rajesh



Juniper Business Use Only
From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Monday, July 19, 2021 7:17 PM
To: Rajesh M ; Rajesh M 
; Ketan Talaulikar (ketant) 
; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) 
; rob...@raszuk.net; bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
bess@ietf.org; Srihari Sangli 
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi Rajesh,

The draft is written so that the next-hop address MAY be covered by the 
locator, but there are cases in which the next-hop address is not part of the 
locator prefix, and there are implementations already allowing that, so I don't 
agree the document should mandate what you are suggesting.

Thanks.
Jorge

From: Rajesh M mailto:mraj...@juniper.net>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>,
 Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>, 
gdawra.i...@gmail.com 
mailto:gdawra.i...@gmail.com>>, Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>, 
rob...@raszuk.net 
mailto:rob...@raszuk.net>>, 
bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>, Rabadan, Jorge 
(Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Cc: spr...@ietf.org 
mailto:spr...@ietf.org>>, b...@ans.net 
mailto:b...@ans.net>>, Shraddha Hegde 
mailto:shrad...@juniper.net>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Srihari Sangli mailto:ssan...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Hi Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com; 
jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org
Subject: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.

2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully 
resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).


Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line 
with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding 
locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh


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

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Robert Raszuk]

I agree with Jorge..

In fact I find the tone of the comment to be very inappropriate:

*> In case of best effort/flex algo we must mandate user to set
corresponding locator as BGP nexthop for srv6 routes.*

*No we MUST not mandate anything to the user. *

*We MUST provide flexibility to address all deployment cases user may
have. *

*Best,*
*R.*



On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi Rajesh,
>
>
>
> The draft is written so that the next-hop address MAY be covered by the
> locator, but there are cases in which the next-hop address is not part of
> the locator prefix, and there are implementations already allowing that, so
> I don’t agree the document should mandate what you are suggesting.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Rajesh M 
> *Date: *Monday, July 19, 2021 at 3:24 PM
> *To: *Rajesh M , Ketan Talaulikar
> (ketant) , gdawra.i...@gmail.com ,
> Clarence Filsfils (cfilsfil) , rob...@raszuk.net <
> rob...@raszuk.net>, bruno.decra...@orange.com ,
> Rabadan, Jorge (Nokia - US/Mountain View) 
> *Cc: *spr...@ietf.org , b...@ans.net ,
> Shraddha Hegde , bess@ietf.org ,
> Srihari Sangli 
> *Subject: *RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
> Hi Authors,
>
>
>
> Please respond.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring  *On Behalf Of *Rajesh M
> *Sent:* Thursday, July 15, 2021 4:36 PM
> *To:* Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com;
> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net;
> bruno.decra...@orange.com; jorge.raba...@nokia.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org
> *Subject:* [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All,
>
>
>
> As per this draft, this is how resolution must work.
>
>
>
> 1)For Non Intent service Route:
>
> if BGP next hop is not reachable return.
>
> Resolve SRv6 Service SID for forwarding.
>
>
>
> 2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR
> Policy):
>
> BGP next hop is not reachable return.
>
> Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if
> successfully resolves then return.
>
> Resolve BGP next hop for forwarding (in case above is not success).
>
>
>
>
>
> *Using Service SID (overlay),for resolution is definitely not recommended.*
>
>
>
> *Instead in case of srv6, we always resolve on BGP nexthop. This will be
> in line with BGP legacy.*
>
> *In case of best effort/flex algo we must mandate user to set
> corresponding locator as BGP nexthop for srv6 routes.*
>
> *I think this is a reasonable mandate.*
>
>
>
> Thanks
>
> Rajesh
>
>
>
> Juniper Business Use Only
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

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

Hi Rajesh,

The draft is written so that the next-hop address MAY be covered by the 
locator, but there are cases in which the next-hop address is not part of the 
locator prefix, and there are implementations already allowing that, so I don’t 
agree the document should mandate what you are suggesting.

Thanks.
Jorge

From: Rajesh M 
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M , Ketan Talaulikar (ketant) 
, gdawra.i...@gmail.com , Clarence 
Filsfils (cfilsfil) , rob...@raszuk.net 
, bruno.decra...@orange.com , 
Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: spr...@ietf.org , b...@ans.net , Shraddha 
Hegde , bess@ietf.org , Srihari Sangli 

Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Hi Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring  On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com; 
Clarence Filsfils (cfilsfil) ; rob...@raszuk.net; 
bruno.decra...@orange.com; jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
bess@ietf.org
Subject: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.

2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully 
resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).


Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line 
with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding 
locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh


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

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Rajesh M]

Hi Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring  On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com; 
Clarence Filsfils (cfilsfil) ; rob...@raszuk.net; 
bruno.decra...@orange.com; jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
bess@ietf.org
Subject: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.

2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully 
resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).


Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line 
with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding 
locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh


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

[bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Rajesh M]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.
2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully 
resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).


Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line 
with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding 
locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh


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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Vivek Venkatraman]

The implementation of Link Bandwidth in FRR uses a transitive community to 
signal & perform an automatic accumulation at the AS boundary. This seems 
useful as it obviates the need for additional info (configuration) at each AS 
boundary to generate a new community using accumulated values.

From: Arie Vayner 
Sent: Tuesday, July 6, 2021 10:13 PM
To: Jeff Tantsura 
Cc: bess@ietf.org; Satya Mohanty (satyamoh) 
; Gyan Mishra ; 
vi...@cumulusnetworks.com
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

External email: Use caution opening links or attachments

The way I see this implementation, this is not really a transitive community. 
The values are consumed within the local AS, and then a new community is 
generated, based on accumulated values, at the AS boundary.

Tnx
Arie

On Fri, Jul 2, 2021 at 2:52 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Arie,

The way the draft reads, it is quite clear that IANA allocated Link Bandwidth 
Ext. Community (0x4004) should be used (and formally changed to transitive), 
I'd be rather surprised if it is not the case ( that would make implementations 
non interoperable).
I'm in the process of reviewing all existing implementations and will come back 
on this one. Implementers - please do respond (FRR incl)
Practically  - if there's wg consensus (I don't think this is needed, given 
there's a number of working implementations) to use a new extended community 
the document should become standard track with the formal IANA allocation 
request.

Thanks,
Jeff


On Tue, May 25, 2021 at 1:16 PM Arie Vayner 
mailto:ar...@vayner.net>> wrote:
Jeff,

Actually, the way this draft is written, and how the implementations I'm aware 
of are implemented, this is not really a transitive community. It is a new 
community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an 
cumulative value of other received communities, and then advertised as a new 
value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in another 
draft.
Gyan  - please note, while pretty much every vendor has implemented the 
community and relevant data-plane constructs, initial draft defines the 
community as non transititive, some vendors have followed that while some other 
have implemented it a transitive (to support obvious use case - eBGP in DC).


Cheers,
Jeff
On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>>, wrote:

Hi all,

On behalf of all the authors, we request a discussion of the draft 
https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
  and subsequent WG adoption.
This draft extends the usage of the DMZ link bandwidth to scenarios where the 
cumulative link bandwidth needs to be advertised to a BGP speaker.
Additionally, there is provision to send the link bandwidth extended community 
to EBGP speakers via configurable knobs. Please refer to section 3 and 4 for 
the use cases.

This feature has multiple-vendor implementations and has been deployed by 
several customers in their networks.

Best Regards,
--Satya
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-dskc-bess-bgp-car-02

[Rajesh M]

Hi Authors,

Please respond.

Thanks
Rajesh




Juniper Business Use Only
From: Rajesh M 
Sent: Thursday, July 8, 2021 2:24 PM
To: Rajesh M ; dh...@cisco.com; swaag...@cisco.com; 
cfils...@cisco.com; ket...@cisco.com
Cc: spr...@ietf.org; bess@ietf.org
Subject: RE: draft-dskc-bess-bgp-car-02

[External Email. Be cautious of content]

+bess working group



Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Rajesh M
Sent: Thursday, July 8, 2021 12:38 PM
To: dh...@cisco.com; 
swaag...@cisco.com; 
cfils...@cisco.com; 
ket...@cisco.com
Cc: spr...@ietf.org
Subject: [spring] draft-dskc-bess-bgp-car-02

[External Email. Be cautious of content]

Hi All,

Have below query on BGP CAR draft section  "2.9.2.3 SRv6 SID TLV"

1) why we are using Prefix-SID attribute ?
The idea was omitting BGP Prefix SID Attribute from the color-aware routes for 
better BGP packing efficiency.

2) Which SID we are advertising in BGP Prefix SID Attribute ?



Thanks
Rajesh


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