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

[Shraddha Hegde]

I agree with Jim that fallback needs to be discussed in the draft .

The current draft mandates the resolvability of the service SID. The fact that 
when flex-algo is allowed to
Fallback to best effort,  service SID resolvability is not required  because 
service SID corresponds to flex-algo locator in this case.This is an important 
aspect that needs to be addressed in the draft.

Rgds
Shraddha



Juniper Business Use Only
From: UTTARO, JAMES 
Sent: Tuesday, July 20, 2021 10:59 PM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) ; 
Srihari Sangli ; Shraddha Hegde ; 
Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Comments In-Line..

Thanks,
  Jim Uttaro

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Aissaoui, Mustapha (Nokia - CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to "SRv6 service with best-effort connectivity" and to "SRv6 
service in conjunction with an underlay SLA". I would propose to change these 
to "SRv6 service using shortest path in base or a flex-algo topology" and "SRv6 
service using SRv6 policy" respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.
[Jim U>] Fallback should be addressed as it needs to be consistent.

Regards,
Mustapha.

From: Srihari Sangli mailto:ssan...@juniper.net>>
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph "When providing best-effort 
connectivity..." where it specifically talks about fallback to best-effort and 
if so, perform the resolvability check on the service-SID. Going by what you 
are saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari...


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





"When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an outer IPv6 header where the 
destination

address is the SRv6 Service SID associated with the related BGP route update.

 Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
Service SID

 before considering the received prefix for the BGP best path computation.

"

"In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths w

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-datacenter-gateway-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Oops, this got set aside for much longer than planned (even with the
multiple reminders from the authors).
My humble apologies for the long delay and the need to be reminded.
In part it seems that I misremembered how complicated my concerns were and
thus was trying to allocate a larger chunk of time to reviewing the changes
than ended up being necessary, but that only accounts for a small part of
the delay.

Carrying on from where we left off, which is I suppose the best I can do at
this point...

On Wed, Jun 02, 2021 at 12:00:57PM +0100, Adrian Farrel wrote:
> Thanks for what you got to yesterday.
> 
> We can take this step by step.
> 
> [snip the Discuss]
> 
> >>Given that the gateways and ASBRs are connected by tunnels that may 
> >> run across parts of the network that are not trusted, 
> >> data center operators using the approach set out in this network 
> >> SHOULD consider using gateway-to-gateway encryption to
> >
> > "SHOULD consider"?  We're not even bold enough to go with just SHOULD?
> 
> I find this aspect of IETF Security considerations hard. Maybe I have a 
> philosophical problem.
> You might tell your child or another vulnerable person that they "SHOULD 
> carry their money in a safe place". But with an adult one usually points out 
> the risks and says that they "SHOULD consider carrying their money in a safe 
> place."
> 
> >>protect the data center traffic.  Additionally, due consideration 
> >> SHOULD be given to encrypting end-to-end traffic as it
> >>would be for any traffic that uses a public or untrusted network for 
> >> transport.
> >
> > I am thinking that I might be in a similar situation as Warren: my
> > recollection from when we processed 8402 is that nodes remotely connected
> > to each other would be using secure tunnels that provide at least as much
> > protection as the "secure physical network" within the local domain. 
> 
> I really don't want to be painted as someone who supports every word of 8402, 
> but...
> 
> The essence of 8402 is that intervening transit nodes do not need to be 
> tunnelled past.
> 
> Consider, for example, how SRv6 packets may be forwarded across regular IPv6 
> (i.e., not SRv6-capable) routers. The sending SRv6 router sets the IPv6 
> destination address to the address of the receiving SRv6 router, updates the 
> SRH (which is just an IPv6 extension header), and forwards the packet. The 
> transit routers simply forward the packet as an IPv6 packet without even 
> being aware that there is an SRH present. Only when the packet arrives at the 
> receiving SRv6 router (which sees itself in the IPv6 destination field) is 
> SRv6 actioned. Thus, there may be a "logical tunnel" between remotely 
> connected SRv6 nodes, but there is no tunnelling technology used. Thus, the 
> protection is weaker than in a secure physical network.
> 
> Now, you and I might argue that this gives a strong incentive to use a secure 
> tunnelling technology between remotely connected SR nodes. That is, however, 
> hard for the sender to enforce for remote (sic) remotely connected nodes. 
> Hence the consideration of GW-to-GW encryption. 
> 
> The proponents of 8402 might argue that SR is a forwarding technology and so 
> it is no different to IP: it is up to the applications to decide whether the 
> underlying network is safe. Thus, if a service provider decides to use SR 
> inside their network, it has no additional security considerations over the 
> same provider using IP inside their network.

That's fair, and thank you for writing it out.
(You and I might also argue that there is strong incentive to use a secure
tunnelling technology between remotely connected nodes even when non-SR IP
is in use...)

> > With
> > that background, I would have gone with MUSTs here, but I am not at the
> > moment finding much in 8402 to strongly support that as a requirement.
> 
> Well, I could go with "MUST consider" and "consideration MUST be given". That 
> directs thought, but not action.

Right.


And as this is the end of the DISCUSS section, I'll note that the text in
the -12 does resolve my listed concerns; thank you!

> >>> COMMENT:
> >>> 
> >>>
> >>> The Abstract is perhaps pushing the bounds of reasonable length for an 
> >>> abstract. 
> >> 
> >> The Style Guide recommends 25 lines or fewer. We have 18 lines of text.
> >
> > Er, which style guide?  I'm not seeing much in RFC 7322 ... and
> > https://www.rfc-editor.org/policy.html#policy.abstract (which admittedly
> > does say it has been replaced by https://www.rfc-editor.org/styleguide/)
> > puts the cap at 20, with 5-10 being "typical".
> 
> Oh, I apologise. 
> Either my memory is faulty or this section has been updated over the last 
> twenty years.
> Anyway, "cap at 20" tells us what to do.
> 
> [snip]
> 
> >> NEW
> >>Data centers are attached to the Internet or a backbone network by
> >>gateway routers.  One data center typic

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-datacenter-gateway-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Picking up (belatedly) where I left off in my initial reply...

On Fri, May 28, 2021 at 10:03:12PM +0100, Adrian Farrel wrote:
[snip]
> >As the current set of active GWs
> >   changes (due to the addition of a new GW or the failure/removal of an
> >   existing GW) each externally advertised route will be re-advertised
> >   with a new Tunnel Encapsulation attribute which reflects current set
> >   of active GWs.
> >
> > The "everybody advertises the union of what they've seen" behavior seems
> > like it will latch NLRI in place as being a GW, but here we're saying that
> > removal will be propagated as well as addition.  What's the mechanism for
> > removing stale data (whether maliciously added or as part of maintenance? 
> > If it's an explicit withdrawal, is that also propagated by everybody?  How 
> > long
> > does it have to stay around for?  (I recognize that some of this is just 
> > stock
> > BGP, but I am looking for more clarity on how it interacts with the 
> > "advertise
> > the union of what you saw" behavior that is new to this document.
> 
> Yes, this is all handled by standard BGP mechanisms. It's how the withdraw 
> message works and is propagated.
> 
> If a gateway auto-discovery route gets withdrawn (explicit message or dropped 
> peering), then the remaining gateways remove its tunnel TLVs from the union 
> and re-advertise the site's routes. 

For what it's worth, what's going on here seems to have become much more
clear to me after a re-read of the document and the month's delay.  I'm
sorry that I was confused about it the first time around.

In short: the "union of what you saw" only gets advertised externally, and
the auto-discovery (internal) advertisements will always just be for the
advertising router's own information.  There's no auto-discovery that
includes the union of what you saw, which is I think what I was concerned
about here.

> > The text in the next paragraph mentions that there can be situations with
> > broken internal routing where things land in a broken state -- how long do
> > they stay broken and how can they be fixed?
> 
> It completely depends upon the situation, what the breakage is, and how the 
> breakage is discovered. 
> JGS suggested we flag up the situation rather than try to solve it (which we 
> did in the paragraph quoted below).
> While not an impossible situation, it does represent a strange brokenness 
> that is possibly causing traffic within the site to get misrouted as well.
> 
> >   If a gateway becomes disconnected from the backbone network, or if
> >   the site operator decides to terminate the gateway's activity, it
> >   MUST withdraw the advertisements described above.  This means that
> >   remote gateways at other sites will stop seeing advertisements from
> >   this gateway.  Note that if the routing within a site is broken (for
> >   example, such that there is a route from one GW to another, but not
> >   in the reverse direction), then it is possible that incoming traffic
> >   will be routed to the wrong GW to reach the destination prefix - in
> >   this degraded network situation, traffic may be dropped.
> >
> > This is probably worth reiterating in the security considerations section.
> 
> Muttering about, "Not all problems are security problems" 😊
> As an attack it says, "If you can break the routing within a site, then 
> traffic coming from outside the site might also be incorrectly routed."
> We don't think reiteration of this peculiarly broken situation would help.

Ok.

> >   Note that if a GW is (mis)configured with a different site identifier
> >   from the other GWs to the same site then it will not be auto-
> >   discovered by the other GWs (and will not auto-discover the other
> >   GWs).  This would result in a GW for another site receiving only the
> >   Tunnel Encapsulation attribute included in the BGP best route; i.e.,
> >   the Tunnel Encapsulation attribute of the (mis)configured GW or that
> >   of the other GWs.
> >
> > Are there noteworthy operational considerations of this, e.g., if all the
> > traffic gets directed to a GW that lacks the bandwidth to handle it?
> 
> It is worth noting that without this mechanism, all traffic gets directed to 
> just one gateway because that is what BGP does (plus or minus ADDPATH). 
> What this document does is allow path selection, and choosing paths allows a 
> degree of traffic engineering. So the misconfiguration situation is never 
> worse than before this document.

Good point!

> > Section 4
> >
> >   attribute to identify the GWs through which X can be reached.  It
> >   uses this information to compute SR Traffic Engineering (SR TE) paths
> >   across the backbone network looking at the information advertised to
> >   it in SR BGP Link State (BGP-LS)
> >
> > This seems to leave the reader wondering about the details of how 
> > those SR TE paths are computed.  I understand that it's properly out
> > of scope for this documen

[bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-gateway-12: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/



--
COMMENT:
--

The -12 does address the discuss point that I raised, thank you!

In re-reading the draft so as to clear my discuss position, one thing
that occurred to me is that a reader might wonder what mechanisms are in
place to prevent an attacker outside of a site from spoofing an
auto-discovery route with a given site's site identifier.  (The security
considerations already dutifully considers the case of a node in the
site that is not a gateway being able to falsify an auto-discovery
route.)  As far as I can tell this is not an issue because nodes in the
site will not accept auto-discovery routes that initiate from outside
the site, based on configured knowledge of whether a given BGP peering
is internal or external.  The document already makes some allusions to
this by specifying that the actual tunnel encapsulation with the union
of all GWs' data is only included in "every route advertised externally
to that site", implying that the auto-discovery routes are on the
non-external (i.e., internal) advertisements.  It might (or might not)
be worth being more explicit about auto-discovery only occuring
internally within a site, to clarify this mechanism of action.

NITS

Section 1

   Data centers (DCs) are critical components of the infrastructure used
   by network operators to provide services to their customers.  DCs
   (sites) are interconnected by a backbone network, which consists of
   any number of private networks and/or the Internet, by gateway
   routers (GWs).  [...]

This currently looks like "interconnected by  (...), by " which
doesn't seem right.  Maybe end the sentence after "and/or the Internet"
and finish with "Each DC is connected to the backbone by one or more
gateway routers (GWs)"?

   The solution described in this document is agnostic as to whether the
   transit ASes do or do not have SR capabilities.  the solution uses SR
   to stitch together path segments between GWs and through the ASBRs.

Start the sentence with a majuscule 'T'.

   technique will experience scaling issues.  This all means that the
   Add-Paths approach is limited to sites connected over a single AS.

I'd consider "effectively limited"; we know that some groups/individuals
have a high capacity for hitting themselves in the way that recursive
Add-Path would entail.



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

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-gateway-12: (with COMMENT)

[John E Drake]

Ben,

Thanks for your thorough review and discussion.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: BESS  On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Wednesday, July 21, 2021 1:22 PM
> To: The IESG 
> Cc: draft-ietf-bess-datacenter-gate...@ietf.org; matthew.bo...@nokia.com;
> bess-cha...@ietf.org; bess@ietf.org
> Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-
> gateway-12: (with COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-datacenter-gateway-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-
> criteria.html__;!!NEt6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-
> 8g0fltDGASgWWcsQJ-toZT_lgRJk$
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-
> datacenter-gateway/__;!!NEt6yMaO-
> gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ-
> toZ_kua3SE$
> 
> 
> 
> --
> COMMENT:
> --
> 
> The -12 does address the discuss point that I raised, thank you!
> 
> In re-reading the draft so as to clear my discuss position, one thing that 
> occurred
> to me is that a reader might wonder what mechanisms are in place to prevent an
> attacker outside of a site from spoofing an auto-discovery route with a given
> site's site identifier.  (The security considerations already dutifully 
> considers the
> case of a node in the site that is not a gateway being able to falsify an 
> auto-
> discovery
> route.)  As far as I can tell this is not an issue because nodes in the site 
> will not
> accept auto-discovery routes that initiate from outside the site, based on
> configured knowledge of whether a given BGP peering is internal or external.
> The document already makes some allusions to this by specifying that the 
> actual
> tunnel encapsulation with the union of all GWs' data is only included in 
> "every
> route advertised externally to that site", implying that the auto-discovery 
> routes
> are on the non-external (i.e., internal) advertisements.  It might (or might 
> not) be
> worth being more explicit about auto-discovery only occuring internally 
> within a
> site, to clarify this mechanism of action.
> 
> NITS
> 
> Section 1
> 
>Data centers (DCs) are critical components of the infrastructure used
>by network operators to provide services to their customers.  DCs
>(sites) are interconnected by a backbone network, which consists of
>any number of private networks and/or the Internet, by gateway
>routers (GWs).  [...]
> 
> This currently looks like "interconnected by  (...), by " which doesn't 
> seem
> right.  Maybe end the sentence after "and/or the Internet"
> and finish with "Each DC is connected to the backbone by one or more gateway
> routers (GWs)"?
> 
>The solution described in this document is agnostic as to whether the
>transit ASes do or do not have SR capabilities.  the solution uses SR
>to stitch together path segments between GWs and through the ASBRs.
> 
> Start the sentence with a majuscule 'T'.
> 
>technique will experience scaling issues.  This all means that the
>Add-Paths approach is limited to sites connected over a single AS.
> 
> I'd consider "effectively limited"; we know that some groups/individuals have 
> a
> high capacity for hitting themselves in the way that recursive Add-Path would
> entail.
> 
> 
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!N
> Et6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ-
> toZF8-VjNc$

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

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

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

Hi Shraddha,
do you agree this is about switching between shortest path (in base topology or 
flex-algo topology) and SRv6 policy?

You can describe a fallback strategy but the need to resolve or not the service 
SID is orthogonal and is only dictated by the use of shortest path forwarding 
or SRv6 policy.

Mustapha.
Sent from my iPhone

On Jul 21, 2021, at 5:16 AM, Shraddha Hegde  wrote:


I agree with Jim that fallback needs to be discussed in the draft .

The current draft mandates the resolvability of the service SID. The fact that 
when flex-algo is allowed to
Fallback to best effort,  service SID resolvability is not required  because 
service SID corresponds to flex-algo locator in this case.This is an important 
aspect that needs to be addressed in the draft.

Rgds
Shraddha



Juniper Business Use Only
From: UTTARO, JAMES 
Sent: Tuesday, July 20, 2021 10:59 PM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) ; 
Srihari Sangli ; Shraddha Hegde ; 
Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Comments In-Line..

Thanks,
  Jim Uttaro

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Aissaoui, Mustapha (Nokia - CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to “SRv6 service with best-effort connectivity” and to “SRv6 
service in conjunction with an underlay SLA”. I would propose to change these 
to “SRv6 service using shortest path in base or a flex-algo topology” and “SRv6 
service using SRv6 policy” respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.
[Jim U>] Fallback should be addressed as it needs to be consistent.

Regards,
Mustapha.

From: Srihari Sangli mailto:ssan...@juniper.net>>
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph “When providing best-effort 
connectivity…” where it specifically talks about fallback to best-effort and if 
so, perform the resolvability check on the service-SID. Going by what you are 
saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari…


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





“When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an outer

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

[Swadesh Agrawal (swaagraw)]

Hi Rajesh,

As specified in the draft-ietf-srv6-services draft, when using transposition 
scheme prefix SID attribute carries common part of SRv6 SID  (example locator). 
draft-dskc-bess-bgp-car proposes to carry variable part in SRv6 SID TLV in NLRI 
when same scheme is used. This helps to be efficient in number of bytes 
consumed for each NLRI. We will clarify this in draft.

Regards
Swadesh

From: Rajesh M 
Date: Monday, July 19, 2021 at 6:24 AM
To: Rajesh M , "Dhananjaya Rao (dhrao)" 
, Swadesh Agrawal , "Clarence Filsfils 
(cfilsfil)" , "Ketan Talaulikar (ketant)" 
Cc: "spr...@ietf.org" , "bess@ietf.org" 
Subject: RE: draft-dskc-bess-bgp-car-02

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

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

[Rajesh M]

Hi Swadesh,

This I understood by going through the draft thoroughly. But definitely more 
clarification is better  as you pointed.


1) So SRv6 SID TLV is used only to carry variable part ? it will never carry 
complete SID ?





2) Is there any case where we carry a complete SID1 in prefix SID attribute as 
well as complete SID2 in SRv6 SID TLV ?

Thanks
Rajesh




Juniper Business Use Only
From: Swadesh Agrawal (swaagraw) 
Sent: Thursday, July 22, 2021 7:10 AM
To: Rajesh M ; Rajesh M 
; Dhananjaya Rao (dhrao) 
; Clarence Filsfils (cfilsfil) ; Ketan 
Talaulikar (ketant) 
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: draft-dskc-bess-bgp-car-02

[External Email. Be cautious of content]

Hi Rajesh,

As specified in the draft-ietf-srv6-services draft, when using transposition 
scheme prefix SID attribute carries common part of SRv6 SID  (example locator). 
draft-dskc-bess-bgp-car proposes to carry variable part in SRv6 SID TLV in NLRI 
when same scheme is used. This helps to be efficient in number of bytes 
consumed for each NLRI. We will clarify this in draft.

Regards
Swadesh

From: Rajesh M mailto:mraj...@juniper.net>>
Date: Monday, July 19, 2021 at 6:24 AM
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>,
 "Dhananjaya Rao (dhrao)" mailto:dh...@cisco.com>>, Swadesh 
Agrawal mailto:swaag...@cisco.com>>, "Clarence Filsfils 
(cfilsfil)" mailto:cfils...@cisco.com>>, "Ketan Talaulikar 
(ketant)" mailto:ket...@cisco.com>>
Cc: "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: RE: draft-dskc-bess-bgp-car-02

Hi Authors,

Please respond.

Thanks
Rajesh




Juniper Business Use Only
From: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>
Sent: Thursday, July 8, 2021 2:24 PM
To: Rajesh M mailto:mraj...@juniper.net>>; 
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