Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Gyan Mishra]

Hi Linda

On Fri, Mar 12, 2021 at 3:26 PM Linda Dunbar 
wrote:

> Gyan,
>
>
>
> You said:
>
> * Gyan>  The Anycast environments that I have worked with architecture
> have been server clusters in data centers geographically diverse that sit
> behind a load balancer that uses a concept called HRI host route injection
> that if the service is up the VIP is BGP advertised for the cluster to DC
> core and then services VIP host route are advertised into the core all BGP
> attributes equal so lowest IGP metric tie breaker picks best path shortest
> path across the core  as best path and of iBGP multipath is used that
> services VIPs are geographically load balanced flow based if metric is a
> tie and if IPv6 is used in the core then 5-tuple per flow load balanced
> optimized.  *
>
> The “cluster of servers” in your paragraph  is considered as ONE (address)
> in In draft-dunbar-lsr-5g-edge-compute-ospf-ext. Only the ADDRESS (or the
> VIP) of the cluster is visible to the network. How the App Load Balancer
> distribute the traffic to individual servers is not visit to network.
>
>  Gyan> Yes only one address VIP is visible to the network and an
> xforwardedfor header is tacked on with the client IP when the packet is
> forwarded to the backend server.  The LB is performing a NAT like function
> but it’s just forwarding  to the attached services being monitored in a
> hash round robin fashion.  Correct the load balancing algorithm is not
> visible to the network.
>
You said:
>
> *Gyan>  With Anycast routing as I mentioned you don’t have a single point
> of failure and really have optimal redundancy which is why for any services
> such as DNS, NTP and many others Anycast is the best most redundancy and
> optimal as proximity routing is used. *
>
> [Linda] Are you saying using VIP to achieve the “Anycast routing” ?
>

Gyan> Having the servers behind a LB provides better redundancy and as
the LB can distribute the flows using a variety of LB algorithms.

> Using a  VIP for multiple  clusters of servers requiring all those
> clusters of servers to be attached to a common device, such as a NAT or a
> GW router.  The “single point failure and bottleneck” is referring to the
> NAT or the GW router.
>
Gyan> Yes all the backend servers in the cluster would be locally routed
attached but don’t have to be on the same subnet so technically they don’t
even have to be in the same geographic location but generally are at least
within the same DC.

> 5G EC needs the multiple clusters of servers to be placed in different
> mini Edge-DCs.  And desire to use the same IP address for those clusters of
> servers attached to different egress routers.
>

Gyan> So with LB front ending the back end servers in a cluster you can
have that same setup in every edge DC with a LB device VIP front ending the
backend servers.

With non Anycast VIP just standard app VIP what’s registered in DNS if the
app is geo load balanced is a site specific name and geo load balanced name
and so the Geo DNS database based on the client source IP the Geo DNS can
serve up Name based on proximity so the app flow is optimal hits the
closest DC resources.

> *Gyan>  If your closest lowest IGP metric iBGP load balanced path goes
> down let’s say multiple DC outages you still have your next closest in the
> BGP path list pecking order to reach the service thus optimized redundancy
> as every DC would have to be down for service VIP to be down.  Also with
> Anycast as it a distributed architecture you are not overloading core paths
> or certain DC VIPs as all traffic is distributed geographically proximity
> load balanced automatically.  So there is a lesser chance of bottleneck as
> the Anycast architecture is distributed.*
>
> [Linda] Yes, when multiple clusters of servers are attached to different
> routers, the IGP metric and iBGP load balanced path can select the optimal
> one.
>
>  Gyan> Exactly.  Would this LB model work for you for the 5G edge
> computing?
>
> The  draft-dunbar-lsr-5g-edge-compute-ospf-ext adds another component into
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01
> ,
> i.e. the “Load to reach the cluster”  which is influenced by
> “site-capacity + load measurement + Preference + xxx”. The “Load to reach
> the cluster” can be the raw measurements collected by the egress routers
> based on the instruction from a controller, or informed by the App
> Controller periodically.
>
>
>
> I don’t see  any conflicts to the
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01
> 

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Gyan,

You said:
 Gyan>  The Anycast environments that I have worked with architecture have been 
server clusters in data centers geographically diverse that sit behind a load 
balancer that uses a concept called HRI host route injection that if the 
service is up the VIP is BGP advertised for the cluster to DC core and then 
services VIP host route are advertised into the core all BGP attributes equal 
so lowest IGP metric tie breaker picks best path shortest path across the core  
as best path and of iBGP multipath is used that services VIPs are 
geographically load balanced flow based if metric is a tie and if IPv6 is used 
in the core then 5-tuple per flow load balanced optimized.
The "cluster of servers" in your paragraph  is considered as ONE (address) in 
In draft-dunbar-lsr-5g-edge-compute-ospf-ext. Only the ADDRESS (or the VIP) of 
the cluster is visible to the network. How the App Load Balancer distribute the 
traffic to individual servers is not visit to network.

You said:
Gyan>  With Anycast routing as I mentioned you don't have a single point of 
failure and really have optimal redundancy which is why for any services such 
as DNS, NTP and many others Anycast is the best most redundancy and optimal as 
proximity routing is used.
[Linda] Are you saying using VIP to achieve the "Anycast routing" ?
Using a  VIP for multiple  clusters of servers requiring all those clusters of 
servers to be attached to a common device, such as a NAT or a GW router.  The 
"single point failure and bottleneck" is referring to the NAT or the GW router.
5G EC needs the multiple clusters of servers to be placed in different mini 
Edge-DCs.  And desire to use the same IP address for those clusters of servers 
attached to different egress routers.
Gyan>  If your closest lowest IGP metric iBGP load balanced path goes down 
let's say multiple DC outages you still have your next closest in the BGP path 
list pecking order to reach the service thus optimized redundancy as every DC 
would have to be down for service VIP to be down.  Also with Anycast as it a 
distributed architecture you are not overloading core paths or certain DC VIPs 
as all traffic is distributed geographically proximity load balanced 
automatically.  So there is a lesser chance of bottleneck as the Anycast 
architecture is distributed.
[Linda] Yes, when multiple clusters of servers are attached to different 
routers, the IGP metric and iBGP load balanced path can select the optimal one.

The  draft-dunbar-lsr-5g-edge-compute-ospf-ext adds another component into 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01,
 i.e. the "Load to reach the cluster"  which is influenced by  "site-capacity + 
load measurement + Preference + xxx". The "Load to reach the cluster" can be 
the raw measurements collected by the egress routers based on the instruction 
from a controller, or informed by the App Controller periodically.

I don't see  any conflicts to the 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01,
 am I missing anything?

Thanks, Linda Dunbar

From: Gyan Mishra 
Sent: Wednesday, March 10, 2021 11:49 PM
To: Linda Dunbar 
Cc: Christian Hopps ; Liyizhou ; 
lsr@ietf.org
Subject: Re: [Lsr] Why not leverage Network conditions to optimize balancing 
among multiple App Layer Load Balancers? as proposed by 
draft-dunbar-lsr-5g-edge-compute-ospf-ext

Hi Linda

Comments in-line

On Wed, Mar 10, 2021 at 6:46 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Gyan,

To a router, having multiple servers with the same (ANYCAST) address attached 
to different egress routers (A-ER) is same as having multiple paths to reach 
the (ANYCAST) address.

You are absolutely correct that there are many tools to influence the path 
section, such as the routing distance, TE metrics, policies, etc.

draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes to add another component to 
influence the path selection: the "Site-Cost"  which is influenced by  
"site-capacity + load measurement + Preference + xxx". The "site-Cost" can be 
raw measurements collected by the egress routers based on 

Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles

[Peter Psenak]

Hi Ran,

On 12/03/2021 14:35, chen@zte.com.cn wrote:


Hi Peter,

Thank you very much for your comments.


##PP
as I expressed earlier, my preference would be to keep the flex-algo
being based on L3 link information only and not to use L2 link
information during the flex-algo computation. There are other ways to

solve your problem. But I will let the WG to discuss and decide.


Ran:Would you like to provide other ways? Then we can take it as an 
optional solution and compare with our solution.


a) SRTE
b) usage of L3 links instead of L2 bundle in such case

thanks,
Peter






Best Regards,

Ran




原始邮件
*发件人：*PeterPsenak
*收件人：*彭少富10053815;
*抄送人：*lsr@ietf.org;
*日 期 ：*2021年03月12日 20:04
*主 题 ：**Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles*
Hi Shaofu,

please see inline (##PP):

On 12/03/2021 04:26, peng.sha...@zte.com.cn wrote:
 >
 > Hi Peter,
 >
 >
 > Thanks for your important comments.
 >
 > It seems that we have a consensus that the use-case described in the
 > draft is valid.
 >
 > I've heard some people say that flex-algo has already supported this
 > l2-bundles scenario, no additional definition is needed. This seems
 > that, from the view of some people, the use-case need to be solved
 > through flex-algo itself.

##PP
no, flex-algo does not have any support for l2-bundles at this point.

 >
 > The solution currently described in this document may not be mature, but
 > the direction may not be wrong ?

##PP
as I expressed earlier, my preference would be to keep the flex-algo
being based on L3 link information only and not to use L2 link
information during the flex-algo computation. There are other ways to

solve your problem. But I will let the WG to discuss and decide.



 >
 >
 > Others please see inline [PSF].
 >
 >
 > Regards,
 >
 > PSF
 >
 >
 > 原始邮件
 > *发件人：*PeterPsenak
 > *收件人：*lsr@ietf.org;
 > *日 期 ：*2021年03月09日 18:08
 > *主 题 ：**[Lsr] draft-peng-lsr-flex-algo-l2bundles*
 > Dear authors,
 >
 > here are couple of comments to draft-peng-lsr-flex-algo-l2bundles:
 >
 > 1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only
 > uses L3 link information for path computation. This is consistent with
 > the regular Algo 0 path computation. My preference would be to keep it
 > that way.
 >
 > *[PSF] There maybe one way not to violate this rule, but more complex. *
 >
 > *[PSF] Currently for an L3 link there are multiple Application specific
 > attributes, is it possible for an application (such as Flex-algo) there
 > are multiple APP Instance specific attributes ? For example, an
 > L2-bundle interface can have multiple Flex-algo APP instance delay
 > metric, for algorithm-128 the delay metric is 10ms (exactly get from the
 > dynamic detection of member link 1), for algorithm-129 the delay metric
 > is 20ms (exactly get from the dynamic detection of member link 2), for
 > algorithm-0 the delay metric get from the dynamic detection of bundles
 > itself.** However I don't like the this way. Other ways?*

##PP
what you are proposing above is a per flex-algo ID link attributes, but
I don't believe that is the direction we want to go. It does not scale.

 >
 >
 > 2. Flex-algo is not a replacement for SRTE. The problem that you are
 > trying to solve can be solved by SRTE with the usage of the L2 Adj-SIDs.
 >
 > *[PSF] Flex-algo is constraint based SPF, for the initial purpose, is
 > SID stack depth optimization for SR-TE path ? It's hard to convince
 > operators by just saying that "the problem is out the scope of
 > Flex-algo" when he has already selected Flex-algo *to reduce the number
 > of Adj-SIDs.**

##PP
Flex-algo is constraint based SPF, but so far based on L3 link
information only.

 >
 >
 > 3. Usage of the L2 link data for flex-algo path computation is much more
 > complex than defining the L-flag in the FAD. You would need to deal with
 > things like:
 >
 > a) conflicting information in L3 and L2 link information
 > b) missing information in L3 or L2 link information
 >
 > *[PSF] Yes, more computation rules need be added based on the existing
 > ones defined in draft-ietf-lsr-flex-algo. I think it's no more complex
 > than Flex-algo itself.*

##PP
the question is how much extra complexity do we want to add for the
benefit it brings.

We need to consider how frequent is the use case that you describe
present in the field and whether existing mechanisms like SRTE, or usage
of L3 links instead if L2 bundles in such case, are not sufficient to
address the problem.

The fact that it is possible to address the problem by flex-algo does
not mandate the usage of it.

thanks,
Peter

 >
 >
 > which would require to define a strict path computation preference rules
 > and conflict resolutions that all routers would need to follow. I would
 > argue that this is much easier to be done with SRTE, where the logic to
 > select the path is a local matter compared to consistency in path
 > selection that is required for distributed calculation used by flex-algo.
 >
 > *[PSF] Unfortunately we 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[Acee Lindem (acee)]

Thanks for your review and comments Bruno and Peter for quick resolution. 
Acee

On 3/12/21, 9:20 AM, "bruno.decra...@orange.com"  
wrote:

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, March 12, 2021 3:13 PM
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 12/03/2021 11:39, bruno.decra...@orange.com wrote:
> > Peter, Alvaro
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, March 11, 2021 11:47 AM
> >
> > [...]
> >
> >>> ...
> >>> 221   4.3.  Maximum H.Encaps MSD Type
> >>>
> >>> 223  The Maximum H.Encaps MSD Type specifies the maximum
> number
> >> of SIDs
> >>> 224  that can be included as part of the "H.Encaps" behavior as
> defined
> >> in
> >>> 225  [I-D.ietf-spring-srv6-network-programming].
> >>>
> >>> [nit] s/included/pushed   That is the terminology used in rfc8986.
> >>
> >> ##PP
> >> fixed.
> >>
> >>>
> >>>
> >>> ...
> >>> 229 If the advertised value is zero or no value is advertised
> >>> 230 then the router can apply H.Encaps only by encapsulating
> >>> 231 the incoming packet in another IPv6 header without SRH
> >>> 232 the same way IPinIP encapsulation is performed.
> >>>
> >>> 234 If the advertised value is non-zero then the router
> supports both
> >>> 235 IPinIP and SRH encapsulation subject to the SID limitation
> >>> 236 specified by the advertised value.
> >>>
> >>> [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does 
say
> this:
> >>>
> >>>  The push of the SRH MAY be omitted when the SRv6 Policy only
> contains
> >>>  one segment and there is no need to use any flag, tag or TLV.
> >>>
> >>> Suggestion (to replace the last two paragraphs)>
> >>>   If the advertised value is zero or no value is advertised then 
the
> >>>   headend can apply an SR Policy that only contains one segment, 
by
> >>>   omitting the SRH push.
> >>>
> >>>   A non-zero SRH Max H.encaps MSD indicates that the headend can
> push
> >>>   an SRH up to the advertised value.
> >>
> >> ##PP
> >> done, but used "insert" instead of "push".
> >
> > In SRv6, "Insert" has been used with a different meaning (SRH insertion
> without IP encapsulation) and hence is very connoted. So I would prefer if
> we could avoid the term "insert", to avoid both misunderstanding and
> ambiguities.
> >
> > I'm not sure how many/which  :s/push/insert  you are referring to as I'm
> seen 3  "push". I'll assume you meant the 3 of them. I would suggest the
> following change, but any other formulation would probably work for me.
> >
> > OLD: The push of the SRH MAY be omitted
> > NEW: The SRH MAY be omitted
> >
> > OLD: by omitting the SRH push.
> > NEW by omitting the SRH.
> >
> > OLD: the headend can push an SRH up to the advertised value.
> > NEW: the headend can perform IP encapsulation with an SRH containing up
> to MSD SIDs.
> > (or may be: up to this number of SIDs)
> 
> not sure which document/version do you look at, but I don't see any
> occurrence of "push" or "insert" in the latest published version (11).

I'm referring to the email (above) that you sent yesterday on the LSR 
mailing list in which you said " ##PP done, but used "insert" instead of 
"push"."
It's not reflected in the latest published version which date from October 
8, 2020

 > The single "push" I added as a response to Alvaro's comment was at:
> 
> 
> The Maximum H.Encaps MSD Type signals the maximum number of SIDs
> that can be pushed as part of the "H.Encaps" behavior as defined in
> [RFC8986]"
> 
> Please let me know how do you prefer that to be modified.
> 
> 
> >
> >
> > [...]
> >
> >
> >> 245  SRH Max End D Type: 45
> >>
> >> 247  If the advertised value is zero or no value is advertised
> >> 248  then it is assumed that the router cannot apply
> >> 249  "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
> >> 250  contains an SRH.
> >
> > Since I've started, I'll continue to nick pick.
> >
> > "assume" does not seem like the right term when talking about an 
explicit
> signalling.
> > I would suggest
> > OLD: then it is assumed that the router cannot apply
> > NEW: then the router cannot apply
> 
> fixed them all.

Thanks,
--Bruno


> Peter
> >
> >
> > *3 (in §4.1, §4.2, §4.4)
> >
> >
> > Thank you,
> > --Bruno
> >
> >
> __
> 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, March 12, 2021 3:13 PM
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 12/03/2021 11:39, bruno.decra...@orange.com wrote:
> > Peter, Alvaro
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, March 11, 2021 11:47 AM
> >
> > [...]
> >
> >>> ...
> >>> 221   4.3.  Maximum H.Encaps MSD Type
> >>>
> >>> 223  The Maximum H.Encaps MSD Type specifies the maximum
> number
> >> of SIDs
> >>> 224  that can be included as part of the "H.Encaps" behavior as
> defined
> >> in
> >>> 225  [I-D.ietf-spring-srv6-network-programming].
> >>>
> >>> [nit] s/included/pushed   That is the terminology used in rfc8986.
> >>
> >> ##PP
> >> fixed.
> >>
> >>>
> >>>
> >>> ...
> >>> 229     If the advertised value is zero or no value is advertised
> >>> 230     then the router can apply H.Encaps only by encapsulating
> >>> 231     the incoming packet in another IPv6 header without SRH
> >>> 232     the same way IPinIP encapsulation is performed.
> >>>
> >>> 234     If the advertised value is non-zero then the router
> supports both
> >>> 235     IPinIP and SRH encapsulation subject to the SID limitation
> >>> 236     specified by the advertised value.
> >>>
> >>> [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say
> this:
> >>>
> >>>      The push of the SRH MAY be omitted when the SRv6 Policy only
> contains
> >>>      one segment and there is no need to use any flag, tag or TLV.
> >>>
> >>> Suggestion (to replace the last two paragraphs)>
> >>>       If the advertised value is zero or no value is advertised then the
> >>>       headend can apply an SR Policy that only contains one segment, by
> >>>       omitting the SRH push.
> >>>
> >>>       A non-zero SRH Max H.encaps MSD indicates that the headend can
> push
> >>>       an SRH up to the advertised value.
> >>
> >> ##PP
> >> done, but used "insert" instead of "push".
> >
> > In SRv6, "Insert" has been used with a different meaning (SRH insertion
> without IP encapsulation) and hence is very connoted. So I would prefer if
> we could avoid the term "insert", to avoid both misunderstanding and
> ambiguities.
> >
> > I'm not sure how many/which  :s/push/insert  you are referring to as I'm
> seen 3  "push". I'll assume you meant the 3 of them. I would suggest the
> following change, but any other formulation would probably work for me.
> >
> > OLD: The push of the SRH MAY be omitted
> > NEW: The SRH MAY be omitted
> >
> > OLD: by omitting the SRH push.
> > NEW by omitting the SRH.
> >
> > OLD: the headend can push an SRH up to the advertised value.
> > NEW: the headend can perform IP encapsulation with an SRH containing up
> to MSD SIDs.
> > (or may be: up to this number of SIDs)
> 
> not sure which document/version do you look at, but I don't see any
> occurrence of "push" or "insert" in the latest published version (11).

I'm referring to the email (above) that you sent yesterday on the LSR mailing 
list in which you said " ##PP done, but used "insert" instead of "push"."
It's not reflected in the latest published version which date from October 8, 
2020

 > The single "push" I added as a response to Alvaro's comment was at:
> 
> 
> The Maximum H.Encaps MSD Type signals the maximum number of SIDs
> that can be pushed as part of the "H.Encaps" behavior as defined in
> [RFC8986]"
> 
> Please let me know how do you prefer that to be modified.
> 
> 
> >
> >
> > [...]
> >
> >
> >> 245  SRH Max End D Type: 45
> >>
> >> 247  If the advertised value is zero or no value is advertised
> >> 248  then it is assumed that the router cannot apply
> >> 249  "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
> >> 250  contains an SRH.
> >
> > Since I've started, I'll continue to nick pick.
> >
> > "assume" does not seem like the right term when talking about an explicit
> signalling.
> > I would suggest
> > OLD: then it is assumed that the router cannot apply
> > NEW: then the router cannot apply
> 
> fixed them all.

Thanks,
--Bruno

 
> Peter
> >
> >
> > *3 (in §4.1, §4.2, §4.4)
> >
> >
> > Thank you,
> > --Bruno
> >
> >
> __
> __
> _
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> > ce
> message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[Peter Psenak]

Hi Bruno,

please see inline:

On 12/03/2021 11:39, bruno.decra...@orange.com wrote:

Peter, Alvaro


From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Thursday, March 11, 2021 11:47 AM


[...]


...
221 4.3.  Maximum H.Encaps MSD Type

223    The Maximum H.Encaps MSD Type specifies the maximum number

of SIDs

224    that can be included as part of the "H.Encaps" behavior as defined

in

225    [I-D.ietf-spring-srv6-network-programming].

[nit] s/included/pushed   That is the terminology used in rfc8986.


##PP
fixed.




...
229       If the advertised value is zero or no value is advertised
230       then the router can apply H.Encaps only by encapsulating
231       the incoming packet in another IPv6 header without SRH
232       the same way IPinIP encapsulation is performed.

234       If the advertised value is non-zero then the router supports both
235       IPinIP and SRH encapsulation subject to the SID limitation
236       specified by the advertised value.

[major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say this:

     The push of the SRH MAY be omitted when the SRv6 Policy only contains
     one segment and there is no need to use any flag, tag or TLV.

Suggestion (to replace the last two paragraphs)>
      If the advertised value is zero or no value is advertised then the
      headend can apply an SR Policy that only contains one segment, by
      omitting the SRH push.

      A non-zero SRH Max H.encaps MSD indicates that the headend can push
      an SRH up to the advertised value.


##PP
done, but used "insert" instead of "push".


In SRv6, "Insert" has been used with a different meaning (SRH insertion without IP 
encapsulation) and hence is very connoted. So I would prefer if we could avoid the term 
"insert", to avoid both misunderstanding and ambiguities.

I'm not sure how many/which  :s/push/insert  you are referring to as I'm seen 3  
"push". I'll assume you meant the 3 of them. I would suggest the following 
change, but any other formulation would probably work for me.

OLD: The push of the SRH MAY be omitted
NEW: The SRH MAY be omitted

OLD: by omitting the SRH push.
NEW by omitting the SRH.

OLD: the headend can push an SRH up to the advertised value.
NEW: the headend can perform IP encapsulation with an SRH containing up to MSD 
SIDs.
(or may be: up to this number of SIDs)


not sure which document/version do you look at, but I don't see any 
occurrence of "push" or "insert" in the latest published version (11).


The single "push" I added as a response to Alvaro's comment was at:


The Maximum H.Encaps MSD Type signals the maximum number of SIDs
that can be pushed as part of the "H.Encaps" behavior as defined in
[RFC8986]"

Please let me know how do you prefer that to be modified.





[...]



245   SRH Max End D Type: 45

247   If the advertised value is zero or no value is advertised
248   then it is assumed that the router cannot apply
249   "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
250   contains an SRH.


Since I've started, I'll continue to nick pick.

"assume" does not seem like the right term when talking about an explicit 
signalling.
I would suggest
OLD: then it is assumed that the router cannot apply
NEW: then the router cannot apply


fixed them all.

Peter



*3 (in §4.1, §4.2, §4.4)


Thank you,
--Bruno

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles

[chen.ran]

Hi Peter,


Thank you very much for your comments. 






##PPas I expressed earlier, my preference would be to keep the flex-algo being 
based on L3 link information only and not to use L2 link information during the 
flex-algo computation. There are other ways to 


solve your problem. But I will let the WG to discuss and decide.






Ran:Would you like to provide other ways? Then we can take it as an optional 
solution and compare with our solution.










Best Regards,


Ran















原始邮件



发件人：PeterPsenak
收件人：彭少富10053815;
抄送人：lsr@ietf.org;
日 期 ：2021年03月12日 20:04
主 题 ：Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles


Hi Shaofu,

please see inline (##PP):

On 12/03/2021 04:26, peng.sha...@zte.com.cn wrote:
> 
> Hi Peter,
> 
> 
> Thanks for your important comments.
> 
> It seems that we have a consensus that the use-case described in the 
> draft is valid.
> 
> I've heard some people say that flex-algo has already supported this 
> l2-bundles scenario, no additional definition is needed. This seems 
> that, from the view of some people, the use-case need to be solved 
> through flex-algo itself.

##PP
no, flex-algo does not have any support for l2-bundles at this point.

> 
> The solution currently described in this document may not be mature, but 
> the direction may not be wrong ?

##PP
as I expressed earlier, my preference would be to keep the flex-algo 
being based on L3 link information only and not to use L2 link 
information during the flex-algo computation. There are other ways to 
solve your problem. But I will let the WG to discuss and decide.







> 
> 
> Others please see inline [PSF].
> 
> 
> Regards,
> 
> PSF
> 
> 
> 原始邮件
> *发件人：*PeterPsenak
> *收件人：*lsr@ietf.org;
> *日 期 ：*2021年03月09日 18:08
> *主 题 ：**[Lsr] draft-peng-lsr-flex-algo-l2bundles*
> Dear authors,
> 
> here are couple of comments to draft-peng-lsr-flex-algo-l2bundles:
> 
> 1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only
> uses L3 link information for path computation. This is consistent with
> the regular Algo 0 path computation. My preference would be to keep it
> that way.
> 
> *[PSF] There maybe one way not to violate this rule, but more complex. *
> 
> *[PSF] Currently for an L3 link there are multiple Application specific 
> attributes, is it possible for an application (such as Flex-algo) there 
> are multiple APP Instance specific attributes ? For example, an 
> L2-bundle interface can have multiple Flex-algo APP instance delay 
> metric, for algorithm-128 the delay metric is 10ms (exactly get from the 
> dynamic detection of member link 1), for algorithm-129 the delay metric 
> is 20ms (exactly get from the dynamic detection of member link 2), for 
> algorithm-0 the delay metric get from the dynamic detection of bundles 
> itself.** However I don't like the this way. Other ways?*

##PP
what you are proposing above is a per flex-algo ID link attributes, but 
I don't believe that is the direction we want to go. It does not scale.

> 
> 
> 2. Flex-algo is not a replacement for SRTE. The problem that you are
> trying to solve can be solved by SRTE with the usage of the L2 Adj-SIDs.
> 
> *[PSF] Flex-algo is constraint based SPF, for the initial purpose, is 
> SID stack depth optimization for SR-TE path ? It's hard to convince 
> operators by just saying that "the problem is out the scope of 
> Flex-algo" when he has already selected Flex-algo *to reduce the number 
> of Adj-SIDs.**

##PP
Flex-algo is constraint based SPF, but so far based on L3 link 
information only.

> 
> 
> 3. Usage of the L2 link data for flex-algo path computation is much more
> complex than defining the L-flag in the FAD. You would need to deal with
> things like:
> 
> a) conflicting information in L3 and L2 link information
> b) missing information in L3 or L2 link information
> 
> *[PSF] Yes, more computation rules need be added based on the existing 
> ones defined in draft-ietf-lsr-flex-algo. I think it's no more complex 
> than Flex-algo itself.*

##PP
the question is how much extra complexity do we want to add for the 
benefit it brings.

We need to consider how frequent is the use case that you describe 
present in the field and whether existing mechanisms like SRTE, or usage 
of L3 links instead if L2 bundles in such case, are not sufficient to 
address the problem.

The fact that it is possible to address the problem by flex-algo does 
not mandate the usage of it.

thanks,
Peter

> 
> 
> which would require to define a strict path computation preference rules
> and conflict resolutions that all routers would need to follow. I would
> argue that this is much easier to be done with SRTE, where the logic to
> select the path is a local matter compared to consistency in path
> selection that is required for distributed calculation used by flex-algo.
> 
> *[PSF] Unfortunately we are now in the context of Flex-algo, not SR-TE.*
> 
> 
> thanks,
> Peter
> 
> 
> 
> 
> ___
> Lsr 

Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles

[Peter Psenak]

Hi Shaofu,

please see inline (##PP):

On 12/03/2021 04:26, peng.sha...@zte.com.cn wrote:


Hi Peter,


Thanks for your important comments.

It seems that we have a consensus that the use-case described in the 
draft is valid.


I've heard some people say that flex-algo has already supported this 
l2-bundles scenario, no additional definition is needed. This seems 
that, from the view of some people, the use-case need to be solved 
through flex-algo itself.


##PP
no, flex-algo does not have any support for l2-bundles at this point.



The solution currently described in this document may not be mature, but 
the direction may not be wrong ?


##PP
as I expressed earlier, my preference would be to keep the flex-algo 
being based on L3 link information only and not to use L2 link 
information during the flex-algo computation. There are other ways to 
solve your problem. But I will let the WG to discuss and decide.





Others please see inline [PSF].


Regards,

PSF


原始邮件
*发件人：*PeterPsenak
*收件人：*lsr@ietf.org;
*日 期 ：*2021年03月09日 18:08
*主 题 ：**[Lsr] draft-peng-lsr-flex-algo-l2bundles*
Dear authors,

here are couple of comments to draft-peng-lsr-flex-algo-l2bundles:

1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only
uses L3 link information for path computation. This is consistent with
the regular Algo 0 path computation. My preference would be to keep it
that way.

*[PSF] There maybe one way not to violate this rule, but more complex. *

*[PSF] Currently for an L3 link there are multiple Application specific 
attributes, is it possible for an application (such as Flex-algo) there 
are multiple APP Instance specific attributes ? For example, an 
L2-bundle interface can have multiple Flex-algo APP instance delay 
metric, for algorithm-128 the delay metric is 10ms (exactly get from the 
dynamic detection of member link 1), for algorithm-129 the delay metric 
is 20ms (exactly get from the dynamic detection of member link 2), for 
algorithm-0 the delay metric get from the dynamic detection of bundles 
itself.** However I don't like the this way. Other ways?*


##PP
what you are proposing above is a per flex-algo ID link attributes, but 
I don't believe that is the direction we want to go. It does not scale.





2. Flex-algo is not a replacement for SRTE. The problem that you are
trying to solve can be solved by SRTE with the usage of the L2 Adj-SIDs.

*[PSF] Flex-algo is constraint based SPF, for the initial purpose, is 
SID stack depth optimization for SR-TE path ? It's hard to convince 
operators by just saying that "the problem is out the scope of 
Flex-algo" when he has already selected Flex-algo *to reduce the number 
of Adj-SIDs.**


##PP
Flex-algo is constraint based SPF, but so far based on L3 link 
information only.





3. Usage of the L2 link data for flex-algo path computation is much more
complex than defining the L-flag in the FAD. You would need to deal with
things like:

a) conflicting information in L3 and L2 link information
b) missing information in L3 or L2 link information

*[PSF] Yes, more computation rules need be added based on the existing 
ones defined in draft-ietf-lsr-flex-algo. I think it's no more complex 
than Flex-algo itself.*


##PP
the question is how much extra complexity do we want to add for the 
benefit it brings.


We need to consider how frequent is the use case that you describe 
present in the field and whether existing mechanisms like SRTE, or usage 
of L3 links instead if L2 bundles in such case, are not sufficient to 
address the problem.


The fact that it is possible to address the problem by flex-algo does 
not mandate the usage of it.


thanks,
Peter




which would require to define a strict path computation preference rules
and conflict resolutions that all routers would need to follow. I would
argue that this is much easier to be done with SRTE, where the logic to
select the path is a local matter compared to consistency in path
selection that is required for distributed calculation used by flex-algo.

*[PSF] Unfortunately we are now in the context of Flex-algo, not SR-TE.*


thanks,
Peter




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo

[Peter Psenak]

Hi Jie,

please see inline:

On 12/03/2021 09:03, Dongjie (Jimmy) wrote:

Hi Peter,

Thanks for your comments. Please see some replies inline:


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Tuesday, March 9, 2021 5:46 PM
To: lsr@ietf.org
Subject: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo

Dear authors,

here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:

1. whether we want to flood VTN specific link data in IGPs or not is something
that deserves its own discussion.


IGP as one option can be used to distribute the VTN specific link information 
among network nodes, and some of these nodes could further distribute this 
information to a network controller using BGP-LS. This is similar to the 
distribution and collection of the TE link attributes of the underlay network.


I would say the need to distribute VTN specific link information 
requires a broader discussion. We already advertise per instance, per 
area, per topology, per application link attributes. Adding yet another 
dimension needs a careful thinking.






2. Nevertheless, the proposed encoding does not seem to be a fortunate one:

a) it hijacks the L2 bundle member TLV for VTN data. I don't see the need for
that.


It is considered as one option to advertise the VTN specific link information 
when Flex-Algo ID is re-used to identify a VTN, as there is no existing 
mechanism to advertise per-Flex-Algo link attributes (this is a difference 
between MT and Flex-Algo). And based on the L2 bundle mechanism, only minor 
extension is needed.


the fact that there are no link attributes per each Flex-algo ID is a 
feature, not a miss.





b) the proposed mechanism to associate the VTN specific link data with the VTN
itself by the use of the link affinities is a very user unfriendly way of doing 
it. If
the VTN need only the low latency optimization, provisioning additional
affinities seems like a unnecessary provisioning price that would need to be 
paid
by the user for the encoding deficiency. You want to flood the VTN specific link
data, put the VTN ID in it.


A VTN is associated with not only the metric types defined in the Flex-Algo, it 
is also associated with a subset of network resources. Thus different VTNs with 
low latency optimization may need to correlate with different set of resources 
for packet forwarding, hence different Admin Groups are needed to distinguish 
the different set of link attributes of a L3 link. Using Admin Group (link 
affinity) to correlate the link attributes with a Flex-Algo is the mechanism 
introduced in the Flex-Algo base document, this document tries to reuse the 
existing mechanisms when possible.


not really. Flex-algo specification does not make any correlation 
between any link attribute and Flex-algo ID. It can not, as the same 
link attributes may be used by many Flex-Algo IDs. Flex-algo uses link 
attributes during calculation but these attributes are not tight to any 
specific Flex-algo ID.


thanks,
Peter




Introducing a VTN-ID is another option, which would require a little more 
extensions. That mechanism is described in draft-dong-lsr-sr-for-enhanced-vpn, 
which is targeted to provide a more scalable solution with the additional 
protocol extensions.

Hope this provides some background about this design.

Best regards,
Jie



thanks,
Peter




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Hi Shraddha,

On 11/03/2021 19:16, Shraddha Hegde wrote:

I agree problem is valid for networks that use summarization and leaking for 
inter-domain connectivity.
However, I don't think the solution space has to be in IGP.
There are various different ways the problem could be solved.
A network could deploy egress protection [RFC 8679] or anycast based egress 
protection
[draft-hegde-rtgwg-egress-protection-sr-networks] which will ensure packets 
aren't dropped
Due to remote PE node failure. This mechanism is faster compared to other 
possible
Solutions  because if addresses failure  at the PLR and provides protection.


egress protection is one way of solving the problem. It has its own 
issues though - it requires the service SIDs to be in sync between 
multiple PEs which is not a trivial thing to do and maintain. Especially 
with the per CE allocation scheme and large scale on top.


Ingress PE "PIC" like convergence has proved its value and if an 
efficient IGP solution can be found to provide a similar mechanism in 
combination with the summarization, I have no doubts users would like that.


A combination of both is possible as well.

thanks,
Peter



Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Tuesday, March 9, 2021 5:07 PM
To: Robert Raszuk 
Cc: Gyan Mishra ; Aijun Wang ; Aijun Wang 
; Tony Li ; lsr ; Acee Lindem (acee) 
; draft-wang-lsr-prefix-unreachable-annoucement 

Subject: Re: [Lsr] 
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[External Email. Be cautious of content]


Robert,

On 09/03/2021 12:20, Robert Raszuk wrote:


  > In addition you may have a hierarchical RR, which would still
involve  > BGP signalling.

Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.


  > because BGP signalling is prefix based and as a result slow.
+
  > that is the whole point, you need something that is prefix independent.

BGP can be easily setup in prefix independent way today.

Example 1:

If session to PE1 goes down, withdraw all RDs received from such PE.


still dependent on RDs and BGP specific. We want app independent way of 
signaling the reachability loss. At the end that's what IGPs do without a 
presence of summarization.

Again, I'm not advocating the solution proposed in 
draft-wang-lsr-prefix-unreachable-annoucement. I'm just saying the problem 
seems valid  and IGP based solution is not an unreasonable thing to consider if 
a reasonable one can be found.



Example 2:

Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If
PE


there is no LSP in SRv6.

Peter


goes down withdraw it. IGP can still signal summary no issue as no
inet.3 route.

Best,
R.


On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak mailto:ppse...@cisco.com>> wrote:

 Hi Robert,

 On 09/03/2021 12:02, Robert Raszuk wrote:
  > Hey Peter,
  >
  > Well ok so let's forget about LDP - cool !
  >
  > So IGP sends summary around and that is all what is needed.
  >
  > So the question why not propage information that PE went down in
 service
  > signalling - today mainly BGP.

 because BGP signalling is prefix based and as a result slow.

  >
  >  >   And forget BFD, does not scale with 10k PEs.
  >
  > You missed the point. No one is proposing full mesh of BFD sessions
  > between all PEs. I hope so at least.
  >
  > PE is connected to RRs so you need as many BFD sessions as RR to
 PE BGP
  > sessions.

 that can be still too many.
 In addition you may have a hierarchical RR, which would still involve
 BGP signalling.

 Once that session is brought down RR has all it needs to
  > trigger a message (withdraw or implicit withdraw) to remove the
  > broken service routes in a scalable way.

 that is the whole point, you need something that is prefix independent.

 thanks,
 Peter

  >
  > Thx,
  > R.
  >
  > PS. Yes we still need to start support signalling of
 unreachability in
  > BGP itself when BGP is used for underlay but this is a bit
 different use
  > case and outside of scope of LSR
  >
  >
  > On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak mailto:ppse...@cisco.com>
  > >> wrote:
  >
  > Robert,
  >
  > On 09/03/2021 11:47, Robert Raszuk wrote:
  >  >  > You’re trying to fix a problem in the overlay by
 morphing the
  >  > underlay.  How can that seem like a good idea?
  >  >
  >  > I think this really nails this discussion.
  >  >
  >  > We have discussed this before and while the concept of
 signalling
  >  > unreachability does seem useful such signalling should be done
  > where it
  >  > belongs.
  >  >
  >  > Here clearly we are 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[bruno.decraene]

Peter, Alvaro

> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, March 11, 2021 11:47 AM

[...]

> > ...
> > 221 4.3.  Maximum H.Encaps MSD Type
> >
> > 223    The Maximum H.Encaps MSD Type specifies the maximum number
> of SIDs
> > 224    that can be included as part of the "H.Encaps" behavior as defined
> in
> > 225    [I-D.ietf-spring-srv6-network-programming].
> >
> > [nit] s/included/pushed   That is the terminology used in rfc8986.
> 
> ##PP
> fixed.
> 
> >
> >
> > ...
> > 229       If the advertised value is zero or no value is advertised
> > 230       then the router can apply H.Encaps only by encapsulating
> > 231       the incoming packet in another IPv6 header without SRH
> > 232       the same way IPinIP encapsulation is performed.
> >
> > 234       If the advertised value is non-zero then the router supports both
> > 235       IPinIP and SRH encapsulation subject to the SID limitation
> > 236       specified by the advertised value.
> >
> > [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say 
> > this:
> >
> >     The push of the SRH MAY be omitted when the SRv6 Policy only contains
> >     one segment and there is no need to use any flag, tag or TLV.
> >
> > Suggestion (to replace the last two paragraphs)>
> >      If the advertised value is zero or no value is advertised then the
> >      headend can apply an SR Policy that only contains one segment, by
> >      omitting the SRH push.
> >
> >      A non-zero SRH Max H.encaps MSD indicates that the headend can push
> >      an SRH up to the advertised value.
> 
> ##PP
> done, but used "insert" instead of "push".

In SRv6, "Insert" has been used with a different meaning (SRH insertion without 
IP encapsulation) and hence is very connoted. So I would prefer if we could 
avoid the term "insert", to avoid both misunderstanding and ambiguities. 

I'm not sure how many/which  :s/push/insert  you are referring to as I'm seen 3 
 "push". I'll assume you meant the 3 of them. I would suggest the following 
change, but any other formulation would probably work for me.

OLD: The push of the SRH MAY be omitted
NEW: The SRH MAY be omitted

OLD: by omitting the SRH push.
NEW by omitting the SRH.

OLD: the headend can push an SRH up to the advertised value.
NEW: the headend can perform IP encapsulation with an SRH containing up to MSD 
SIDs.
(or may be: up to this number of SIDs)



[...]


> 245 SRH Max End D Type: 45
> 
> 247 If the advertised value is zero or no value is advertised
> 248 then it is assumed that the router cannot apply
> 249 "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
> 250 contains an SRH.

Since I've started, I'll continue to nick pick.

"assume" does not seem like the right term when talking about an explicit 
signalling.
I would suggest
OLD: then it is assumed that the router cannot apply
NEW: then the router cannot apply


*3 (in §4.1, §4.2, §4.4)


Thank you,
--Bruno

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo

[Dongjie (Jimmy)]

Hi Peter,

Thanks for your comments. Please see some replies inline:

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Tuesday, March 9, 2021 5:46 PM
> To: lsr@ietf.org
> Subject: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo
> 
> Dear authors,
> 
> here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:
> 
> 1. whether we want to flood VTN specific link data in IGPs or not is something
> that deserves its own discussion.

IGP as one option can be used to distribute the VTN specific link information 
among network nodes, and some of these nodes could further distribute this 
information to a network controller using BGP-LS. This is similar to the 
distribution and collection of the TE link attributes of the underlay network. 

> 2. Nevertheless, the proposed encoding does not seem to be a fortunate one:
> 
> a) it hijacks the L2 bundle member TLV for VTN data. I don't see the need for
> that.

It is considered as one option to advertise the VTN specific link information 
when Flex-Algo ID is re-used to identify a VTN, as there is no existing 
mechanism to advertise per-Flex-Algo link attributes (this is a difference 
between MT and Flex-Algo). And based on the L2 bundle mechanism, only minor 
extension is needed. 

> b) the proposed mechanism to associate the VTN specific link data with the VTN
> itself by the use of the link affinities is a very user unfriendly way of 
> doing it. If
> the VTN need only the low latency optimization, provisioning additional
> affinities seems like a unnecessary provisioning price that would need to be 
> paid
> by the user for the encoding deficiency. You want to flood the VTN specific 
> link
> data, put the VTN ID in it.

A VTN is associated with not only the metric types defined in the Flex-Algo, it 
is also associated with a subset of network resources. Thus different VTNs with 
low latency optimization may need to correlate with different set of resources 
for packet forwarding, hence different Admin Groups are needed to distinguish 
the different set of link attributes of a L3 link. Using Admin Group (link 
affinity) to correlate the link attributes with a Flex-Algo is the mechanism 
introduced in the Flex-Algo base document, this document tries to reuse the 
existing mechanisms when possible.

Introducing a VTN-ID is another option, which would require a little more 
extensions. That mechanism is described in draft-dong-lsr-sr-for-enhanced-vpn, 
which is targeted to provide a more scalable solution with the additional 
protocol extensions. 

Hope this provides some background about this design. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr