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

[Aijun Wang]

Hi, Shraddha:

I think Anycast protection mechanism is valid but it requires the deployment of 
anycast address for each multi-home pair services("The number of anycast 
loopbacks on a given node will be equal to the number of such {primary, 
protector} pairs a node belongs to."), and another thing is that they are 
applying only the SR-based service network.

Peter has mentioned some other scenarios(mainly tunnel services) at 
https://mailarchive.ietf.org/arch/msg/lsr/lz0FeTvu8OsYIYAJ83eYspmH7B8/
PUA messages can be used to trigger the tunnel switchover, besides the egress 
node/link protection.

Best Regards

Aijun Wang
China Telecom


-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Shraddha Hegde
Sent: Friday, March 12, 2021 2:16 AM
To: Peter Psenak ; 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

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.


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  > 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  
>  > >> wrote:
>  >
>  > Robert,
>  >
>  > On 

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

[peng.shaofu]

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. 

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




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?




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.




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.




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-draft-peng-lsr-algorithm-related-adjacency-sid

[peng.shaofu]

Hi Peter,






Agree, that is an important use case. We will add it to the next version.






Regards,


PSF










原始邮件



发件人：PeterPsenak
收件人：陈然00080434;tonysi...@gmail.com;
抄送人：lsr@ietf.org;
日 期 ：2021年03月11日 17:57
主 题 ：Re: [Lsr] draft-draft-peng-lsr-algorithm-related-adjacency-sid


Hi Ran, Tony,

I believe the primary use case for algorithm specific adj-SID is for the 
protected Adj-SID. The backup path of such Adj-SID follows the algo 
specific constraints.

thanks,
Peter




On 11/03/2021 09:51, chen@zte.com.cn wrote:
> Hi Tony,
> 
> Thanks for your comments. The reason why this draft is proposed is that:
> 
> Currently, the current FA draft only defines that the algorithm 
> identifier is included as part of a  Prefix-SID advertisement,that maybe 
> not satisfy some scenarios where multiple algorithm share the same link 
> resource.
> 
>  For example, an SR-TE policy may be instantiated within specific 
> Flex-algo plane, i.e.,the SID list requires to include algorithm related 
> SIDs.  An algorithm-unware Adjacency-SID included in the SID list can 
> just steer the packet towards the link, but can not apply different QoS 
> policy for different algorithm.
> 
>   Another example is that the TI-LFA backup path computed in 
> Flex-algo plane may also contain an algorithm-unware Adjacency-SID, 
> which maybe also used in other SR-TE instance that carries other service.
> 
>  This document complement that the algorithm identifier can be also 
>   included as part of an Adjacency-SID advertisement for SR-MPLS.
> 
> 
> Best Regards,
> 
> Ran
> 
> 

___
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

[Shraddha Hegde]

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.


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  > 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  
>  > >> 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 talking about faster connectivity
> restoration
>  > for
>  >  > overlay services so it naturally belongs in overlay.
>  >  >
>  >  > It could be a bit misleading as this is today underlay which
>  > propagates
>  >  > reachability of PEs and overlay relies on it. And to scale,
>  >  > summarization is used hence in the underlay, failing
> remote PEs
>  > remain
>  >  > reachable. That however in spite of 

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

[Acee Lindem (acee)]

Hi Gyan,

I guess you didn’t understand my first PUA question. See inline.

From: Gyan Mishra 
Date: Monday, March 8, 2021 at 8:11 PM
To: Acee Lindem 
Cc: Aijun Wang , 
draft-wang-lsr-prefix-unreachable-annoucement 
, lsr 
Subject: Re: 
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05



On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as a WG member:

Hi Gyan,

The first question is how do you know which prefixes within the summary range 
to protect? Are these configured? Is this half-assed best-effort protection 
where you protect prefixes within the range that you’ve installed recently? 
Just how does this work? It is clearly not specified in the draft.
 Gyan>  All prefixes within the summary range are protected see section 4.


   [RFC7794] and 
[I-D.ietf-lsr-ospf-prefix-originator]
 draft both define

   one sub-tlv to announce the originator information of the one prefix

   from a specified node.  This draft utilizes such TLV for both OSPF

   and ISIS to signal the negative prefix in the perspective PUA when a

   link or node goes down.



   ABR detects link or node down and floods PUA negative prefix

   advertisement along with the summary advertisement according to the

   prefix-originator specification.  The ABR or ISIS L1-L2 border node

   has the responsibility to add the prefix originator information when

   it receives the Router LSA from other routers in the same area or

   level.



Acee> So, the ABR will only know about missing prefixes that it has recently 
received? What if the prefix is already missing when the ABR establishes 
adjacencies on the path to the PE? What if the prefix is being permanently 
taken out of service – then this negative advertisement will persist 
permanently. What if there is an unintentional advertisement in the summary 
range and it is withdrawn? How do you decide whether or not to protect a prefix 
with in the range?









When the ABR or ISIS L1-L2 border node generates the summary

   advertisement based on component prefixes, the ABR will announce one

   new summary LSA or LSP which includes the information about this down

   prefix, with the prefix originator set to NULL.  The number of PUAs

   is equivalent to the number of links down or nodes down.  The LSA or

   LSP will be propagated with standard flooding procedures.



   If the nodes in the area receive the PUA flood from all of its ABR

   routers, they will start BGP convergence process if there exist BGP

   session on this PUA prefix.  The PUA creates a forced fail over

   action to initiate immediate control plane convergence switchover to

   alternate egress PE.  Without the PUA forced convergence the down

   prefix will yield black hole routing resulting in loss of

   connectivity.



   When only some of the ABRs can't reach the failure node/link, as that

   described in Section 
3.2,
 the ABR th.at can reach the PUA prefix

   should advertise one specific route to this PUA prefix.  The internal

   routers within another area can then bypass the ABRs that can't reach

   the PUA prefix, to reach the PUA prefix.

The second comment is that using the prefix-originator TLV is a terrible choice 
of encoding. Note that if there is any router in the domain that doesn’t 
support the extension, you’ll actually attract traffic towards the ABR 
blackholing it.
 Gyan> I will work with the authors to see if their is any alternative PUA 
process to signal and detect the failure in case prefix originator TLV is not 
supported.
Acee> Note that in the case of OSPFv3, the prefix originator TLV is a Sub-TLV 
of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA. If 
there are any OSPFv3 routers in the domain that don’t support this 
functionality and receive traffic for the protected prefix, they will actually 
route it towards the blackhole.

Further, I think your example is a bit contrived. I’d hope that an OSPF area 
with “thousands” of summarized PE addresses wouldn’t be portioned by a single 
failure as in figure 1 in the draft and your slides. I also that the option of 
a backbone tunnel between the ABRs was removed from the draft since it 
diminished the requirement for this functionality.
 Gyan> This is a real world Metro access edge example as the impact is 
customers that have LSP built to the down egress PE that has not failed over.  
In this scenario their is a Primary and Backup PE per Metro edge which is 
typical for an operator.

The workaround used today is to flood all /32 next hop prefixes and not take 
advantage of summarization.  This draft makes RFC 5283 inter area FEC binding 
now viable for operators.
Acee> Or add a reliable intra-area link between your ABRs. 

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[联通集团中国联通研究院-本部]

Hi, all

This document provides useful information about how existing IS-IS TLVs can be 
used together to deliver SR based VTN.
I support its adoption as an informational document.

Best regards,
Pang Ran

发件人： Acee Lindem (acee)
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org
主题： [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Alvaro,

thanks for the review, please see inline (##PP):

On 26/02/2021 19:19, Alvaro Retana wrote:

Dear authors:

Please find below my review of this document.  I appreciate you and
the WG discussing the details, but there is more work needed to be
done before starting the IETF LC (details inline).

Just one high-level comment: It is not clear to me why all the
behaviors from rfc8986 are not covered in this document.  If some are
not applicable, or are covered elsewhere, please explain in the text.


##PP
not all behaviors from rfc8986 are applicable to IGPs. Section 10 
("Advertising Endpoint Behaviors") lists the ones that are applicable to 
ISIS.





Thanks!

Alvaro.

[Line numbers from idnits.]


...
16  Abstract

18     Segment Routing (SR) allows for a flexible definition of end-to-end
19     paths by encoding paths as sequences of topological sub-paths, called
20     "segments".  Segment routing architecture can be implemented over an
21     MPLS data plane as well as an IPv6 data plane.  This draft describes
22     the IS-IS extensions required to support Segment Routing over an IPv6
23     data plane.

[nit] s/Segment routing architecture/The Segment routing architecture


##PP
fixed



[nit] s/This draft/This document


##PP
fixed




...
108 1.  Introduction
...
119    The network programming paradigm
120    [I-D.ietf-spring-srv6-network-programming] is central to SRv6.  It
121    describes how any behavior can be bound to a SID and how any network
122    program can be expressed as a combination of SIDs.

[major] s/[I-D.ietf-spring-srv6-network-programming]/[RFC8986]/g


##PP
replaced all references to RFC8986



...
131    This document defines one new top level IS-IS TLV and several new IS-
132    IS sub-TLVs.

134    The SRv6 Capabilities sub-TLV announces the ability to support SRv6.

136    Several new sub-TLVs are defined to advertise various SRv6 Maximum
137    SID Depths.

139    The new SRv6 Locator top level TLV announces SRv6 locators - a form
140    of summary address for the set of topology/algorithm specific SIDs
141    instantiated at the node.

143    The SRv6 End SID sub-TLV, the SRv6 End.X SID sub-TLV, and the SRv6
144    LAN End.X SID sub-TLV are used to advertise which SIDs are
145    instantiated at a node and what Endpoint behavior is bound to each
146    instantiated SID.

[nit] There is some repetition in the last few paragraphs.  You talk
about the new work, the the TLV, sub-TLVs, TLV again, and then the
sub-TLVs.  A little consolidation would make this part read better.


##PP
Reordered and got rid of one of the paragraphs.





148 2.  SRv6 Capabilities sub-TLV

150    A node indicates that it supports the SR Segment Endpoint Node
151    functionality as specified in [RFC8754] by advertising a new SRv6
152    Capabilities sub-TLV of the router capabilities TLV [RFC7981].

[minor] What about the functionality in rfc8986?  I'm assuming that
you want the nodes advertising this new sub-TLV to support both.  It
may be implicit, but please make it explicit.


##PP
there are many behaviors specified in rfc8986, and we are not making 
that part of the capability. So we can not say the ISIS SRv6 capability 
means the support of entire  rfc8986.





[minor] "router capabilities TLV [RFC7981]"  What should be the
flooding scope of the TLV that includes this new sub-TLV?


##PP
It's up to the originator to set the S bit or not. We are not limiting 
it here.





...
159       0                   1                   2                   3
160        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

[nit] Please align the numbering.  There's one other occurrence in this section.


##PP
done




...
180            O-flag: If set, the router supports use of the O-bit
181            in the Segment Routing Header(SRH) as defined in
182            [I-D.ietf-6man-spring-srv6-oam].

[nit] s/Segment Routing Header(SRH)/Segment Routing Header (SRH)


##PP
fixed




[major] Please ask IANA to set up a registry for the Flags.


##PP
Les has started a separate thread with you on this point. I will wait 
till that discussion is closed.





184 3.  Advertising Supported Algorithms

186    SRv6 capable router indicates supported algorithm(s) by advertising
187    the SR Algorithm TLV as defined in [RFC8667].

[nit] s/SRv6 capable router/An SRv6 capable router


##PP
fixed



[minor] s/SR Algorithm TLV/SR Algorithm sub-TLV


##PP
fixed




...
200 4.1.  Maximum Segments Left MSD Type

202    The Maximum Segments Left MSD Type specifies the maximum value of the
203    "SL" field [RFC8754] in the SRH of a received packet before applying
204    the Endpoint behavior associated with a SID.

[minor] s/specifies/signals/g


#PP
fixed



[minor] Please expand SL.


##PP
done




206       SRH Max SL Type: 41

208   

Re: [Lsr] draft-draft-peng-lsr-algorithm-related-adjacency-sid

[Peter Psenak]

Hi Ran, Tony,

I believe the primary use case for algorithm specific adj-SID is for the 
protected Adj-SID. The backup path of such Adj-SID follows the algo 
specific constraints.


thanks,
Peter




On 11/03/2021 09:51, chen@zte.com.cn wrote:

Hi Tony,

    Thanks for your comments. The reason why this draft is proposed is that:

    Currently, the current FA draft only defines that the algorithm 
identifier is included as part of a  Prefix-SID advertisement,that maybe 
not satisfy some scenarios where multiple algorithm share the same link 
resource.


     For example, an SR-TE policy may be instantiated within specific 
Flex-algo plane, i.e.,the SID list requires to include algorithm related 
SIDs.  An algorithm-unware Adjacency-SID included in the SID list can 
just steer the packet towards the link, but can not apply different QoS 
policy for different algorithm.


      Another example is that the TI-LFA backup path computed in 
Flex-algo plane may also contain an algorithm-unware Adjacency-SID, 
which maybe also used in other SR-TE instance that carries other service.


     This document complement that the algorithm identifier can be also 
  included as part of an Adjacency-SID advertisement for SR-MPLS.



Best Regards,

Ran




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

[Lsr] draft-draft-peng-lsr-algorithm-related-adjacency-sid

[chen.ran]

Hi Tony, 


   Thanks for your comments. The reason why this draft is proposed is that:


   Currently, the current FA draft only defines that the algorithm identifier 
is included as part of a  Prefix-SID advertisement,that maybe not satisfy some 
scenarios where multiple algorithm share the same link resource.  


For example, an SR-TE policy may be instantiated within specific Flex-algo 
plane, i.e.,the SID list requires to include algorithm related SIDs.  An 
algorithm-unware Adjacency-SID included in the SID list can just steer the 
packet towards the link, but can not apply different QoS policy for different 
algorithm. 


 Another example is that the TI-LFA backup path computed in Flex-algo plane 
may also contain an algorithm-unware Adjacency-SID, which maybe also used in 
other SR-TE instance that carries other service.

This document complement that the algorithm identifier can be also  
included as part of an Adjacency-SID advertisement for SR-MPLS.






Best Regards,


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