[Lsr] FW: BGP policies and "typed" SAFI

[Alexander Vainshtein]

Re-sending with the correct address...

Regards,
Sasha

From: Alexander Vainshtein
Sent: Wednesday, July 3, 2024 4:57 PM
To: i...@ietf.com
Cc: rt...@ietf.org
Subject: BGP policies and "typed" SAFI

Hi all,
I have a question about usage of BGP policies for "typed" SAFI in MP-BGP.

These days there are already quite a few "typed" SAFI, i.e., SAFI in which the 
NLRI of the route includes the route type followed by  the type-specific data.

Known cases include:

*   MCAST-VPN [RFC6514<https://datatracker.ietf.org/doc/html/rfc6514>]

*   MCAST-VPLS [RFC7117<https://datatracker.ietf.org/doc/html/rfc7117>]

*   EVPN [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>]

*   BGP-LS [RFC7752<https://datatracker.ietf.org/doc/html/rfc7752>]

*   CAR [Color-aware routing 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-10>].




It seems that the current definitions of BGP policies (e.g., see the BGP YANG 
Model<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-17> draft) 
do not provide ability to define conditions that would, when applied to a 
specific SAFI with "typed" NLRI, identify NLRI of specific type. One example 
could be a rule that would be applied to EVPN Type 5 (IP Prefix) routes and 
check their destination IP Prefix bin the same way destination IP prefixes can 
be checked for, say, VPNv4 or VPNv6 routes.

I wonder if the corresponding extension would be of any interest to the WG.


Regards, and lots of thanks in advance,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

Re: [Lsr] [spring] Shepherd's Review of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Alexander Vainshtein]

Hi,
I have looked up the resource-aware segments draft, and commented on its 
intended status.

My guess (FWIW) that if it is changed from “Standards Track” to 
“Informational”, the chances of its not being progressed – and the associated 
risks for this draft – would be minimal.

Regards,
Sasha

From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Saturday, January 20, 2024 6:05 AM
To: Chongfeng Xie ; Acee Lindem 
; lsr ; teas ; spring 

Subject: [EXTERNAL] Re: [Lsr] [spring] Shepherd's Review of "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

Hi Acee and Chongfeng,

First of all, as a coauthor I support to progress this document to publication.

Please see some replies inline:


发件人：Chongfeng Xie mailto:chongfeng@foxmail.com>>
收件人：Acee Lindem mailto:acee.i...@gmail.com>>;lsr 
mailto:lsr@ietf.org>>;teas 
mailto:t...@ietf.org>>;spring 
mailto:spr...@ietf.org>>
时 间：2024-01-20 10:44:46
主 题：Re: [Lsr] [spring] Shepherd's Review of "Applicability of IS-IS 
Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" 
- draft-ietf-lsr-isis-sr-vtn-mt-06

Hi Acee,
Many thanks for your review and suggestions. I agree with them and will update 
the draft accordingly.
Please see some further replies inline [Chongfeng]:


From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Acee Lindem
Sent: Saturday, January 20, 2024 2:42 AM
To: Lsr mailto:lsr@ietf.org>>; 
t...@ietf.org; spr...@ietf.org
Subject: [spring] Shepherd's Review of "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06

Speaking as WG Member and Document Shepherd:


I have reviewed the document and have three comments.

  1. The document can go forward implying that 
draft-dong-lsr-sr-enhanced-vpn-10 is the accepted solution for supporting 
higher scale of NRPs. While the reference is informative, the text implies 
this. I’d remove the reference altogether and this is reflected in my comments.
[Chongfeng]: This is OK, we will follow this change in next revision.

  2. To support NRPs in IS-IS, three pieces are required - IS-IS SR (MPLS 
and SRv6), IS-IS Multi-topology, and the SR resource-aware segment. The latter 
is not being progressed in SPRING yet. If it is not accepted, the draft will be 
stranded on awaiting publication. I’ve added the SPRING WG to the to list.
[Chongfeng] Understood. Resource-aware segments is a WG document and IMO it has 
been stable for a while, hopefully it will progress quickly in SPRING.
[Jie] Yes the resource-aware segments draft is stable and the plan is to move 
it to WG last call soon.

  3. There is design principle phrasing in 
draft-ietf-teas-nrp-scalability-03 which discourage the usage of “any” 
IGP-based solution (as Les commented). If you read the entire document, this is 
not the case and I’d suggest these principles be qualified to match the intent. 
  Since there are common authors on both documents, I’d hope this could be 
accomplished.
[Chongfeng] I will leave this to the co-author of the nrp-scalability draft to 
comment, personally I agree with your reading of that document.
[Jie] Speaking as coauthor of the NRP scalability draft, the intention of the 
design principle section is to show that there are possible limitations in 
control protocols in supporting a large number of NRPs, and some optimization 
needs to be considered, while discouraging the usage of “any” IGP-based 
solution is not the purpose.  Also, that text is still open for further 
refinement.

See the attached diff for editorial comments and addressing #1.
[Chongfeng] Thanks a lot for providing the diff.

Speaking as LSR WG Co-chair:

Of these comments, #1 is easy to remedy and #3 is on the other TEAS document. 
IMO, #2 remains the only potential blocker to moving forward with publication. 
I’d solicit others opinions on this point. While 
draft-ietf-spring-resource-aware-segments-08 simply defines the semantics for 
resource-aware segments, it is not certain that it will go forward and it seems 
to be critical to draft-ietf-lsr-isis-sr-vtn-mt.
[Chongfeng] Understood. It would be efficient if both documents could move 
forward in parallel.
[Jie] Agree, that would be perfect.
Best regards,
Jie

Thanks,
Acee


Best regards
Chongfeng



> On Jan 8, 2024, at 5:50 PM, Acee Lindem 
> mailto:acee.i...@gmail.com>> wrote:
>
> This begins a two week LSR Working Group last call for the “Applicability of 
> IS-IS Multi-Topology (MT) for Segment Routing based Network Resource 
> Partition (NRP)”. Please express your support or objection prior to Tuesday, 
> January 23rd, 2024.
>
> Thanks,
> Acee

___
spring mailing list
spr...@ietf.org
https://www.ietf.org/mailman/listinfo/spring


Discla

[Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

[Alexander Vainshtein]

Hi,
Just repeating my comment at the mike:

The draft does not explain how packet loss on a link is measured.

If this measurement is based on real traffic, excluding the link from the 
topology for certain flexible algorithms may result in the packet loss going 
down and the link becoming eligible for traffic again.

For this scheme to work, link loss measurement should be done in a way that 
does not depend on the amount of customer traffic crossing the link.

I also think that, even with such a scheme, some kind of hysteresis mechanism 
is required to prevent link being frequently excluded and admitted back if the 
packet loss rate fluctuates around the threshold level,


My 2c,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [EXTERNAL] RtgDir Last Call review: draft-ietf-lsr-isis-fast-flooding

[Alexander Vainshtein]

Loa and all,
I've read the draft, and found what looks as an obvious typo in the following 
sentence in Section 8 (highlighted):

In the absence of cryptographic authentication, as IS-IS does not run over IP 
but directly over the link layer, it's considered difficult to inject false 
SNP/IHH without having access to the link layer.

It should be:

In the absence of cryptographic authentication, as IS-IS does not run over IP 
but directly over the link layer, it's considered difficult to inject false 
SNP/IIH without having access to the link layer.

Lots of thanks to the authors for a very readable document and to Loa for an 
excellent review.

Regards,
Sasha

From: Lsr  On Behalf Of Loa Andersson
Sent: Saturday, October 7, 2023 7:32 PM
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-lsr-isis-fast-flooding@ietf.org; 
lsr-chairs ; lsr@ietf.org; l...@pi.nu
Subject: [EXTERNAL] [Lsr] RtgDir Last Call review: 
draft-ietf-lsr-isis-fast-flooding

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see 
https://wiki.ietf.org/en/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lsr-isis-fast-flooding (the current version is -05)
Reviewer: Loa Andersson
Review Date: 2023-10-08
IETF LC End Date:
Intended Status: Experimental

Summary:

This document is basically ready for publication; I only found one issue
- the number of authors listed.

Document Overview:
Current Link State Protocol Data Unit (PDU) flooding rates are much
slower than what modern networks can support. The use of IS-IS at
larger scale requires faster flooding rates to achieve desired
convergence goals. This document discusses the need for faster
flooding, the issues around faster flooding, and some example approaches
to achieve faster flooding. It also defines protocol extensions
relevant to faster flooding.

Comments:

The draft is well-written and easy to read. I gone over the IANA
Considerations and allocations, and not found anything that need to be
addressed.

Major Issues:

Number of authors: There are 7 authors, that is more the the "allowed" 5
authors.

I have no background why there 7 authors listed, this has to be
addressed in some way:

- reduce the number of authors to five

- keep the number of authors at seven, and the Shepherd will have to
address this in the SWU,

I have put this as a "major issue" since I don't know where to put it.

My personal opinion is that anyone that has contributed text to the
document, and participated in the authors discussions, should be listed
as an author.

"No minor issues found."

Nits:

The nits-tool only finds a Miscellaneous warning:

-- The document date (5 September 2023) is 32 days in the past. Is this
intentional?

This warning is a bit annoying since it is impossible to avoid.

I have not found any other nits.


/Loa


--
Loa Andersson email: l...@pi.nu
Senior MPLS Expert loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

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

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [EXTERNAL] [Errata Verified] RFC9350 (7406)

[Alexander Vainshtein]

Not the first (and probably not the last) time when popular acronyms are 
expanded incorrectly☹.

Regards,
Sasha

-Original Message-
From: Lsr  On Behalf Of RFC Errata System
Sent: Thursday, April 13, 2023 4:56 PM
To: ba...@arrcus.com; ppse...@cisco.com; shrad...@juniper.net; 
cfils...@cisco.com; ketant.i...@gmail.com; arkadiy.gu...@edwardjones.com
Cc: j...@juniper.net; i...@ietf.org; lsr@ietf.org; i...@iana.org
Subject: [EXTERNAL] [Lsr] [Errata Verified] RFC9350 (7406)

The following errata report has been verified for RFC9350, "IGP Flexible 
Algorithm". 

--
You may review the report below and at:
https://clicktime.symantec.com/15siKzMC9jj8jC2zyM8hd?h=dKfd46HiL2okSiYgEgfsFVjG4aGlV1yI3HIDZsOs5ac=&u=https://clicktime.symantec.com/15siKzMC9om4kanQosqPR?h=nWGSZ_ak5M_fey85dGz-FjV7KFy4mjPLQ5izk4_ULcE=&u=https://www.rfc-editor.org/errata/eid7406

--
Status: Verified
Type: Editorial

Reported by: Barry Friedman  Date Reported: 2023-03-28 
Verified by: John Scudder (IESG)

Section: 5.1

Original Text
-
The IS-IS FAD sub-TLV MAY be advertised in a Label Switched Path (LSP) of any 
number.

Corrected Text
--
The IS-IS FAD sub-TLV MAY be advertised in a Link State PDU (LSP) of any number.

Notes
-
I assume LSP is meant to refer to the PDU carrying the FAD, not a Label 
Switched Path.

--
RFC9350 (draft-ietf-lsr-flex-algo-26)
--
Title   : IGP Flexible Algorithm
Publication Date: February 2023
Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. 
Gulko
Category: PROPOSED STANDARD
Source  : Link State Routing
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://clicktime.symantec.com/15siFA9uh83YKFD5RnjZ1?h=-Qe38i2RvlLD_MhiqSadgJmgYF602PgrW-Cd9ix8P5s=&u=https://clicktime.symantec.com/15siFA9uhC5ULdxVGKSEo?h=B6rcLRI7y8CvhvdAmqiG6yTwvIS28UE1Ve9ORH2D4Kk=&u=https://www.ietf.org/mailman/listinfo/lsr

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Change of email address

[Alexander Vainshtein]

Dear colleagues,
Following the acquisition of my employer - ECI Telecom, by Ribbon, starting 
from 09-Jun-20 all the mails I will send to IETF will use 
alexander.vainsht...@rbbn.com as my 
address.

I will still be receiving emails addressed to 
alexander.vainsht...@ecitele..com (at 
least for the time being).

I will re-subscribe to all the IETF mailing lists using my new email once it 
becomes operational.

Regards, and apologies for possible inconvenience,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A question about draft-ietf-lsr-flex-algo

[Alexander Vainshtein]

Hi Zhibo Hu,
Welcome to the club - I have already asked the same question and got a response 
from Peter.
You can find the relevant email thread 
here.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Lsr  On Behalf Of Huzhibo
Sent: Wednesday, June 3, 2020 3:07 PM
To: Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; draft-ietf-lsr-flex-a...@ietf.org
Subject: [Lsr] A question about draft-ietf-lsr-flex-algo

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG defines 
a group of risk-sharing link groups. It is generally used to prevent the 
primary and standby paths from passing the same risk-sharing link group .I 
don't know why a group of SRLG links should be excluded from the FlexAlgo 
calculation. What is its usecase?

Thanks

Zhibo Hu

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Alexander Vainshtein]

Peter.
Again lot of thanks.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: Peter Psenak  
Sent: Monday, May 4, 2020 11:06 AM
To: Alexander Vainshtein ; 
shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
arkadiy.gu...@thomsonreuters.com
Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
; Ron Sdayoor 
Subject: Re: SRLG usage in the IGP Flexible Algorithm draft

Hi Sasha,

On 03/05/2020 09:46, Alexander Vainshtein wrote:
> Peter,
> 
> Lots of thanks for a prompt response.
> 
> My reading of your response is as following:
> 
> There are two different ways in which SRLG information can be used 
> with Flexible Algorithms:
> 
> 1.In a context of a single Flexible Algorithm, it can be used for 
> computation of backup paths (e.g., as described in the TI-LFA draft).
> This usage does not require association of any specific SRLG with the 
> given Flexible Algorithm.
> 
> 2.In the context of multiple Flexible Algorithms it can be used for 
> creating disjoint sets of paths by pruning the links belonging to a 
> specific SRLG from the topology on which a specific Flexible Algorithm 
> computes its paths. This usage:
> 
> a.Extends the definition of the topology used by a given Flexible 
> Algorithm that can be defined using Admin groups (a.k.a. affinities)
> 
> b.Facilitates usage of already deployed SRLG configurations where such 
> configuration have been in place
> 
> c.Requires explicit association of a given Flexible Algorithm with a 
> specific set of SRLG as defined in the current Flex Algo draft.
> 
> The two usages mentioned above are strictly orthogonal.

yes, above is exactly right

> 
> If the understanding above is correct, it makes to me sense to add the 
> corresponding clarifying text to the draft.

sure, I will add it in a next version.

thanks,
Peter


> 
> Regards,
> 
> Sasha
> 
> Office: +972-39266302
> 
> Cell:  +972-549266302
> 
> Email:   alexander.vainsht...@ecitele.com
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Friday, May 1, 2020 12:57 PM
> To: Alexander Vainshtein ;
> shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
> arkadiy.gu...@thomsonreuters.com
> Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
> ; Ron Sdayoor 
> 
> Subject: Re: SRLG usage in the IGP Flexible Algorithm draft
> 
> Alexander,
> 
> On 30/04/2020 17:21, Alexander Vainshtein wrote:
> 
>  > Hi all,
> 
>  >
> 
>  > I have a question about the proposed usage of SRLG in the IGP 
> Flexible
> 
>  > Algorithm
> <https://clicktime.symantec.com/3Wn8dBNRoEXXTU1kJz6RrsR6H2?u=https%3A%
> 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-flex-algo-07>
> draft.
> 
>  >
> 
>  > This usage is defined Section 12 of the draft with the reference to
> 
>  > the SRLG exclude rule as following:
> 
>  >
> 
>  >
> 
>  >
> 
>  >    2.  Check if any exclude SRLG rule is part of the
> 
>  > Flex-Algorithm
> 
>  >
> 
>  >    definition.  If such exclude rule exists, check if the link 
> is
> 
>  >
> 
>  >    part of any SRLG that is also part of the SRLG exclude rule.
> 
>  > If
> 
>  >
> 
>  >    the link is part of such SRLG, the link MUST be pruned from 
> the
> 
>  >
> 
>  >    computation.
> 
>  >
> 
>  > This looks effectively undistinguishable from the usage of the 
> exclude
> 
>  > Admin groups rule as described in the same Section 12 of the draft:
> 
>  >
> 
>  >    1.  Check if any exclude rule is part of the Flex-Algorithm
> 
>  >
> 
>  >    definition.  If such exclude rule exists, check if any color
> 
>  > that
> 
>  >
> 
>  >    is part of the exclude rule is also set on the link.  If 
> such a
> 
>  >
> 
>  >    color is set, the link MUST be pruned from the computation.
> 
>  >
> 
>  >  From my POV, with such a definition, there is no need in the
> 
>  > dedicated “Exclude SRLG” rule as part of the specification of the
> 
>  > Flexible Algorithm, since such the SRLG Exclude rule can be 
> replaced
> 
>  > with a matching Exclude All rule  using Admin groups.
> 
> there is one very important point. Maintaining the affinities is 
> operationally complex. Some networks have already deployed SRLGs. If 
> SRLG exclude with flex-algo gives people what they want, asking them 
> to deploy affinities would be redundant. That's the main point.
> 
> Simple use case:

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Alexander Vainshtein]

Peter,

Lots of thanks for a prompt response.



My reading of your response is as following:

There are two different ways in which SRLG information can be used with 
Flexible Algorithms:

1.   In a context of a single Flexible Algorithm, it can be used for 
computation of backup paths (e.g., as described in the TI-LFA draft). This 
usage does not require association of any specific SRLG with the given Flexible 
Algorithm.

2.   In the context of multiple Flexible Algorithms it can be used for 
creating disjoint sets of paths by pruning the links belonging to a specific 
SRLG from the topology on which a specific Flexible Algorithm computes its 
paths. This usage:

a.   Extends the definition of the topology used by a given Flexible 
Algorithm that can be defined using Admin groups (a.k.a. affinities)

b.   Facilitates usage of already deployed SRLG configurations where such 
configuration have been in place

c.   Requires explicit association of a given Flexible Algorithm with a 
specific set of SRLG as defined in the current Flex Algo draft.

The two usages mentioned above are strictly orthogonal.



If the understanding above is correct, it makes to me sense to add the 
corresponding clarifying text to the draft.



Regards,

Sasha



Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@ecitele.com



-Original Message-
From: Peter Psenak 
Sent: Friday, May 1, 2020 12:57 PM
To: Alexander Vainshtein ; 
shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
arkadiy.gu...@thomsonreuters.com
Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
; Ron Sdayoor 
Subject: Re: SRLG usage in the IGP Flexible Algorithm draft



Alexander,



On 30/04/2020 17:21, Alexander Vainshtein wrote:

> Hi all,

>

> I have a question about the proposed usage of SRLG in the IGP Flexible

> Algorithm 
> <https://clicktime.symantec.com/3Wn8dBNRoEXXTU1kJz6RrsR6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-flex-algo-07>
>  draft.

>

> This usage is defined Section 12 of the draft with the reference to

> the SRLG exclude rule as following:

>

>

>

>2.  Check if any exclude SRLG rule is part of the

> Flex-Algorithm

>

>definition.  If such exclude rule exists, check if the link is

>

>part of any SRLG that is also part of the SRLG exclude rule.

> If

>

>the link is part of such SRLG, the link MUST be pruned from the

>

>computation.

>

> This looks effectively undistinguishable from the usage of the exclude

> Admin groups rule as described in the same Section 12 of the draft:

>

>1.  Check if any exclude rule is part of the Flex-Algorithm

>

>definition.  If such exclude rule exists, check if any color

> that

>

>is part of the exclude rule is also set on the link.  If such a

>

>color is set, the link MUST be pruned from the computation.

>

>  From my POV, with such a definition, there is no need in the

> dedicated “Exclude SRLG” rule as part of the specification of the

> Flexible Algorithm, since such the SRLG Exclude rule can be replaced

> with a matching Exclude All rule  using Admin groups.



there is one very important point. Maintaining the affinities is operationally 
complex. Some networks have already deployed SRLGs. If SRLG exclude with 
flex-algo gives people what they want, asking them to deploy affinities would 
be redundant. That's the main point.



Simple use case:



I have two SRLGs in the network. For some specific traffic I want to send the 
data via two independent streams. I want to avoid single SRLG failure to affect 
both streams. I define two flex-algos, each one excluding one SRLG. No need to 
define extra affinities. This is btw not an academical example, this has been 
requested by real users.





>

> I also think that such a usage of SRLG does not fit the needs of the

> TI-LFA

> <https://clicktime.symantec.com/3GhKPQ2JAgebW7vLidLjXRx6H2?u=https%3A%

> 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtgwg-segment-routing-ti-lfa-0

> 3> draft that considers an SRLG as a resource that fails when any of

> the links/nodes comprising it fails. E.g., it says in Section 2:

>

> The Point of Local Repair (PLR), S, needs to find a node Q (a

> repair

>

> node) that is capable of safely forwarding the traffic to a

>

> destination D affected by the failure of the protected link L, a

> set

>

> of links including L (SRLG), or the node F itself.  The PLR also

>

> needs to find a way to reach Q without being affected by the

>

> convergence state of the nodes over the paths it wants to use to

>

> reach Q: the PLR needs a loop-free path to reach Q.



I see no conflict between the LFA draft and 

[Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Alexander Vainshtein]

Hi all,
I have a question about the proposed usage of SRLG in the IGP Flexible 
Algorithm draft.

This usage is defined Section 12 of the draft with the reference to the SRLG 
exclude rule as following:



  2.  Check if any exclude SRLG rule is part of the Flex-Algorithm

  definition.  If such exclude rule exists, check if the link is

  part of any SRLG that is also part of the SRLG exclude rule.  If

  the link is part of such SRLG, the link MUST be pruned from the

  computation.

This looks effectively undistinguishable from the usage of the exclude Admin 
groups rule as described in the same Section 12 of the draft:


  1.  Check if any exclude rule is part of the Flex-Algorithm

  definition.  If such exclude rule exists, check if any color that

  is part of the exclude rule is also set on the link.  If such a

  color is set, the link MUST be pruned from the computation.

>From my POV, with such a definition, there is no need in the dedicated 
>"Exclude SRLG" rule as part of the specification of the Flexible Algorithm, 
>since such the SRLG Exclude rule can be replaced with a matching Exclude All 
>rule  using Admin groups.

I also think that such a usage of SRLG does not fit the needs of the 
TI-LFA 
draft that considers an SRLG as a resource that fails when any of the 
links/nodes comprising it fails. E.g., it says in Section 2:


   The Point of Local Repair (PLR), S, needs to find a node Q (a repair

   node) that is capable of safely forwarding the traffic to a

   destination D affected by the failure of the protected link L, a set

   of links including L (SRLG), or the node F itself.  The PLR also

   needs to find a way to reach Q without being affected by the

   convergence state of the nodes over the paths it wants to use to

   reach Q: the PLR needs a loop-free path to reach Q.



To me this suggests that SRLGs are only relevant when computing backup paths 
for specific failures, e.g., an LFA for failure of a link hat belongs to a 
specific SRLG must be computed in the topology from which all the links 
belonging to the same SRLG are pruned. This understanding matches RFC 4090 that 
states in Section 6.2 "Procedures for Backup Path Computation":



  - The backup LSP cannot traverse the downstream node and/or link

whose failure is being protected against.  Note that if the PLR

is the penultimate hop, node protection is not possible, and

only the downstream link can be avoided.  The backup path may be

computed to be SRLG disjoint from the downstream node and/or

link being avoided.



If SRLGs are only relevant for computation of backup paths, it is not clear to 
me if they should be part of the definition of a specific Flexible Algorithm.



What, if anything, did I miss?



Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

[Alexander Vainshtein]

Support.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Wednesday, June 12, 2019 3:05 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps ; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Subject: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv.

https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/

Please express your support or non-support.

Authors: Please indicate your knowledge of any IPR related to this work to the 
list as well.

Thanks,
Chris & Acee.


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___

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

Re: [Lsr] [spring] Adjacency SID and Passive Interface

[Alexander Vainshtein]

Hi all,
The life span of an unprotected Adj-SID matches the life span of the 
corresponding IGP adjacency. This means that there can be no Adj-SIDs on 
passive IGP interfaces because no IGP adjacencies are formed across thesd 
interfaces.

Inter-AS interfaces can be associated with BGP Peer Segment IDs as described in 
 the BGP Egress Peer Engineering (EPE) draft.

Hopefully this helps.

Thumb typed by Sasha Vainshtein


From: spring  on behalf of Christian Franke 

Sent: Friday, May 10, 2019 11:40:11 AM
To: olivier.dug...@orange.com; SPRING; LSR
Subject: Re: [spring] [Lsr] Adjacency SID and Passive Interface

On 5/10/19 9:58 AM, olivier.dug...@orange.com wrote:
> In the current state of Segment Routing drafts, do you think it is possible 
> to advertise
> Adjacency SID on such passive or inter-domain interfaces or do we need to 
> specify this behaviour
> in a new draft ?
>
> For me I don't see anything in the drafts that prohibits this kind of 
> advertisement, but perhaps I'm wrong.

My understanding is that the SID is specific to an adjacency and
advertised in IS-IS in either TLV 22, 222, 23, 223.

As adjacencies will not be formed on a passive interface, an adjacency
SID should not be advertised for the passive interface.

I might also be wrong here, though.

All Best,
Chris

___
spring mailing list
spr...@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

[Alexander Vainshtein]

Alvaro, Ahmed and all,
As the twice RTG-DIR reviewer of this draft I should probably have noticed this 
earlier, but...

I fully agree with Alvaro that the drafts that define SR extensions to IS-IS 
and OSPF do not say anything about these protocols installing SR-related 
forwarding entries in the MPLS data plane. What's more, I do not think that 
such functionality should be specified in these drafts. From my POV, whether 
SR-related forwarding entries are installed in the MPLS DP by SR extension to 
the IGP, or by a different entity is a local implementation issue.  I do not 
think there is any way for an external observer to decide whether these 
forwarding entries are installed by SR extension to IGP or by some other 
internal entity. 

I am aware of some SR-MPLS implementations where SR-related forwarding entries 
are installed in the MPLS DP by dedicated internal entities and not by SR 
extension to IGP. So far this fact did not affect in any way successful 
participation of these implementations in public interoperability tests. 

Regards, and apologies for missing this important point in my reviews,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: spring  On Behalf Of Ahmed Bashandy
Sent: Tuesday, April 16, 2019 6:14 PM
To: Alvaro Retana ; The IESG 
Cc: draft-ietf-spring-segment-routing-m...@ietf.org; spr...@ietf.org; 
spring-cha...@ietf.org; Shraddha Hegde 
Subject: Re: [spring] Alvaro Retana's Discuss on 
draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

thanks a lot for the comments (very clear and to the point)

I am taking a look right now and will start discussion with authors of the IGP 
drafts.

Ahmed



On 4/10/19 1:25 PM, Alvaro Retana via Datatracker wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-spring-segment-routing-mpls-19: Discuss
>
> 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 IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpl
> s/
>
>
>
> --
> DISCUSS:
> --
>
> (1) This first point is a cross-document DISCUSS.  In short, the 
> assumptions in this document about what an MCC is responsible for are 
> not in line with the corresponding IGP drafts for OSPF [1][2] and 
> IS-IS [3].  This misalignment must be resolved before any of these documents 
> are published.
>
> [Note: I'll start a thread with the corresponding WGS, Authors, 
> Shepherds, Chairs and ADs.  Let's please discuss this point there.]
>
> This document uses the following definition in §2: "We call "MPLS 
> Control Plane Client (MCC)" any control plane entity installing 
> forwarding entries in the MPLS data plane.  IGPs with SR extensions...are 
> examples of MCCs."
>
> The focus of the IGP drafts is on the transport of the SR information, 
> and not on other functions (see below).  Which component is 
> responsible for what is the point that needs clarification -- either 
> in this document, the IGP drafts, or both.
>
> These are some specific cases:
>
> (1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following 
> rules MUST be applied by the MCC when calculating the MPLS label value 
> corresponding the SID index value "I"."  There's nothing in the IGP 
> extension documents that point at this set of rules, and only a 
> passing reference in the OSPF documents about outgoing labels.
>
> (1.2) §2.5 (Incoming Label Collision) also assumes more functions from 
> an MCC than what the IGP documents do.  For example: "Within an MCC, 
> apply tie-breaking rules to select one FEC only and assign the label to it."
>
> (1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for 
> downloading the correct label value to FIB"...in this case not just 
> calculating the label, but installing it in the FIB.
>
> (1.4) §2.10.1: "The method by which the MCC on router "R0" determines 
> that PUSH or CONTINUE operation must be applied using the SID "Si" is 
> beyond the scope of this document. An example of a method to determine 
> the SID "Si" for PUSH operation is the case where IS-IS 
> [I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS 
> draft (or the OSPF ones, for that matter) don't talk about how to 
> determine the operation
> -- if that is out of scope of this document, then where is it specified?
>
> (1.5) From §2:
>
> An implementation SHOULD check that an IGP node-SID is not associated
> with a prefix that is owned by more than one router 

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

[Alexander Vainshtein]

Les,
Lots of thanks, makes sense to me.

Thumb typed by Sasha Vainshtein


From: Les Ginsberg (ginsberg) 
Sent: Tuesday, March 5, 2019 10:48:43 PM
To: Alexander Vainshtein
Cc: lsr@ietf.org; spr...@ietf.org; 
draft-ietf-isis-segment-routing-extensions@ietf.org; Peter Psenak (ppsenak)
Subject: RE: [spring] FlexAlgo and Global Adj-SIDs

Sasha -

Although you raise a valid issue, I am not feeling any urgency here i.e., 
although the local protected use case is valid I don't see it as operationally 
critical.
However, that's just my opinion.

If you want to pursue this I think you could raise the issue in either LSR or 
SPRING (or both).
The gap in the architecture documents is less important than coming to 
consensus on the importance of the use case.  If there is consensus to address 
this then I think deciding what documents need updating will just follow 
logically.

Make sense to you?

   Les


> -Original Message-
> From: Alexander Vainshtein 
> Sent: Tuesday, March 05, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) 
> Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing-
> extensions@ietf.org; Peter Psenak (ppsenak) 
> Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
>
> Les,
> Lots of thanks for a prompt response.
>
> I fully understand that the current SR extension drafts are too far advanced
> for any significant changes.
>
> I also understand that Algo-specific Adj-SIDs require an update to RFC 8402
> because today it does not recognize any such entities.
> Therefore the discussion of use cases should probably start in the SPRING
> WG while effective the result would be "just" new Sub-TLV in IS-IS and OSPF
> with the actual work coming to the LSR WG.
>
> Any ideas as to what would be the best way to start this kind of discussions?
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>
>
> -----Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, March 5, 2019 6:37 PM
> To: Alexander Vainshtein ; Peter
> Psenak (ppsenak) 
> Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing-
> extensions@ietf.org
> Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
>
> Sasha -
>
> draft-ietf-isis-segment-routing-extensions is currently in AD review - and the
> companion OSPF document has already been approved and is waiting for a
> dependent draft to progress before publication as an RFC.
>
> It is too late to make significant changes.
>
> Further, while I agree with both your description and Peter's response,
> agreeing that this "could" be done is not equivalent to having consensus that
> it "should" be done.
> I think a more complete consideration of the deployment cases and the
> usefulness of such an extension should be discussed by the WG before we
> decide that we actually want to define such an extension.
>
>   Les
>
>
> > -Original Message-
> > From: Alexander Vainshtein 
> > Sent: Tuesday, March 05, 2019 8:29 AM
> > To: Peter Psenak (ppsenak) 
> > Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing-
> > extensions@ietf.org
> > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
> >
> > Peter,
> > Lots of thanks for a prompt and very encouraging response.
> >
> > Do you think that the new Algo specific Adj-SID sub-TLV could be added
> > to the current IS-IS segment Routing Extensions draft, or should be
> > handled in a small dedicated document?
> >
> > Regards, and lots of thanks in advance, Sasha
> >
> > Office: +972-39266302
> > Cell:  +972-549266302
> > Email:   alexander.vainsht...@ecitele.com
> >
> > -Original Message-
> > From: Peter Psenak 
> > Sent: Tuesday, March 5, 2019 5:28 PM
> > To: Alexander Vainshtein 
> > Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing-
> > extensions@ietf.org
> > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs
> >
> > Hi Sasha,
> >
> > On 02/03/2019 18:57 , Alexander Vainshtein wrote:
> > > Peter,
> > > Lots of thanks for a prompt and hivhly informative response.
> > >
> > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are
> > > local
>
> __
> _
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

[Alexander Vainshtein]

Les,
Lots of thanks for a prompt response.

I fully understand that the current SR extension drafts are too far advanced 
for any significant changes.

I also understand that Algo-specific Adj-SIDs require an update to RFC 8402 
because today it does not recognize any such entities.
Therefore the discussion of use cases should probably start in the SPRING WG 
while effective the result would be "just" new Sub-TLV in IS-IS and OSPF with 
the actual work coming to the LSR WG. 

Any ideas as to what would be the best way to start this kind of discussions? 

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, March 5, 2019 6:37 PM
To: Alexander Vainshtein ; Peter Psenak 
(ppsenak) 
Cc: lsr@ietf.org; spr...@ietf.org; 
draft-ietf-isis-segment-routing-extensions@ietf.org
Subject: RE: [spring] FlexAlgo and Global Adj-SIDs

Sasha -

draft-ietf-isis-segment-routing-extensions is currently in AD review - and the 
companion OSPF document has already been approved and is waiting for a 
dependent draft to progress before publication as an RFC.

It is too late to make significant changes.

Further, while I agree with both your description and Peter's response, 
agreeing that this "could" be done is not equivalent to having consensus that 
it "should" be done.
I think a more complete consideration of the deployment cases and the 
usefulness of such an extension should be discussed by the WG before we decide 
that we actually want to define such an extension.

  Les


> -Original Message-
> From: Alexander Vainshtein 
> Sent: Tuesday, March 05, 2019 8:29 AM
> To: Peter Psenak (ppsenak) 
> Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing- 
> extensions@ietf.org
> Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
> 
> Peter,
> Lots of thanks for a prompt and very encouraging response.
> 
> Do you think that the new Algo specific Adj-SID sub-TLV could be added 
> to the current IS-IS segment Routing Extensions draft, or should be 
> handled in a small dedicated document?
> 
> Regards, and lots of thanks in advance, Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> -----Original Message-
> From: Peter Psenak 
> Sent: Tuesday, March 5, 2019 5:28 PM
> To: Alexander Vainshtein 
> Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing- 
> extensions....@ietf.org
> Subject: Re: [spring] FlexAlgo and Global Adj-SIDs
> 
> Hi Sasha,
> 
> On 02/03/2019 18:57 , Alexander Vainshtein wrote:
> > Peter,
> > Lots of thanks for a prompt and hivhly informative response.
> >
> > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are 
> > local

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___

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

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

[Alexander Vainshtein]

Peter,
Lots of thanks for a prompt and very encouraging response.

Do you think that the new Algo specific Adj-SID sub-TLV could be added to the 
current IS-IS segment Routing Extensions draft, or should be handled in a small 
dedicated document?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: Peter Psenak  
Sent: Tuesday, March 5, 2019 5:28 PM
To: Alexander Vainshtein 
Cc: lsr@ietf.org; spr...@ietf.org; 
draft-ietf-isis-segment-routing-extensions@ietf.org
Subject: Re: [spring] FlexAlgo and Global Adj-SIDs

Hi Sasha,

On 02/03/2019 18:57 , Alexander Vainshtein wrote:
> Peter,
> Lots of thanks for a prompt and hivhly informative response.
>
> It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local.
> The relevant use case could be a protected local Adj-SID that is used 
> in a SR-TE LSP that has been set up with some constraints in mind. 
> These constraints would be preserved when the protected adjacency in 
> question is UP, but could be violated when it fails and the shortest 
> path to the node at the remote end of adjacency is used.

yes, this is a possible use case. This would require a new Algo specific 
Adj-SID sub-TLV to be defined. This could be done.

thanks,
Peter



>
> Local protected Adj-SIDs for sure have bern implemented, so this looks 
> like a more relevant use case than global adjacencies to me.
>
> What do you think?
>
> Regards, and lots of thanks in advance,
>
> Thumb typed by Sasha Vainshtein
>
> --
> --
> *From:* Peter Psenak 
> *Sent:* Thursday, February 28, 2019 9:56:49 PM
> *To:* Alexander Vainshtein;
> draft-ietf-isis-segment-routing-extensi...@ietf.org
> *Cc:* lsr@ietf.org; spr...@ietf.org
> *Subject:* Re: [spring] FlexAlgo and Global Adj-SIDs
>
> Hi Alexander,
>
> On 28/02/2019 19:19 , Alexander Vainshtein wrote:
>> Dear colleagues,
>>
>> I have a question regarding global Adj-SIDs in 
>> draft-ietf-isis-segment-routing-extensions.
>>
>>
>>
>> Section 3.4 of RFC 8402 <https://tools.ietf.org/html/rfc8402>  
>> defines definition and handling of global Adj-SIDs.
>>
>> The relevant text is given below:
>>
>>
>>
>> 
>>
>>Similarly, when using a global Adj-SID, a packet injected anywhere
>>
>>within the SR domain with a segment list {SNL}, where SNL is a 
>> global
>>
>>Adj-SID attached by node N to its adjacency over link L, will be
>>
>>forwarded along the shortest path to Nand then be switched by N,
>>
>>without any IP shortest-path consideration, towards link L.
>>
>> ...
>>
>>The use of global Adj-SID allows to reduce the size of the segment 
>> list
>>
>>When expressing a path at the cost of additional state (i.e., the 
>> global
>>
>>Adj-SID will be inserted by all routers within the area in their
>>
>>forwarding table).
>>
>> 
>>
>>
>>
>> The definition of the Adjacency Segment Identifier Sub-TLV in Section
>> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it 
>> allows advertisement of global Adj-SIDs.
>>
>> These advertisements can be associated with a specific IGP adjacency 
>> and, in multi-topology scenarios, a specific topology. But it is not 
>> associated with any specific algorithm since the default algorithm 
>> for reaching the advertising node is implicitly assumed in full 
>> alignment with RFC 8402.
>>
>>
>>
>> My question is about the situation in which multiple algorithms are 
>> supported by the routers in the SR domain, so that each node 
>> advertises a dedicated Node SID for each of these algorithm.
>>
>> In this scenario, the operator can set up a SR-TE LSP that meets 
>> specific constraints (incorporated in one of these algorithms, see 
>> IGP Flexible Algorithm 
>> <https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-01> draft) by 
>> using Node SIDs that have been advertised with the corresponding 
>> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used 
>> (e.g., for reducing the label stack depth) in this situation.
>>
>> I wonder if the possibility to advertise global Adj-SID (that can be 
>> considered as replacing a combination of the Node SID of the 
>> advertising node and one of its local Adj-SIDs) as associated with a 
>> specific algorithm has ever been considered?
>
> to be honest, it has been 

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

[Alexander Vainshtein]

Peter,
Lots of thanks for a prompt and hivhly informative response.

It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local.
The relevant use case could be a protected local Adj-SID that is used in a 
SR-TE LSP that has been set up with some constraints in mind. These constraints 
would be preserved when the protected adjacency in question is UP, but could be 
violated when it fails and the shortest path to the node at the remote end of 
adjacency is used.

Local protected Adj-SIDs for sure have bern implemented, so this looks like a 
more relevant use case than global adjacencies to me.

What do you think?

Regards, and lots of thanks in advance,

Thumb typed by Sasha Vainshtein


From: Peter Psenak 
Sent: Thursday, February 28, 2019 9:56:49 PM
To: Alexander Vainshtein; draft-ietf-isis-segment-routing-extensi...@ietf.org
Cc: lsr@ietf.org; spr...@ietf.org
Subject: Re: [spring] FlexAlgo and Global Adj-SIDs

Hi Alexander,

On 28/02/2019 19:19 , Alexander Vainshtein wrote:
> Dear colleagues,
>
> I have a question regarding global Adj-SIDs in
> draft-ietf-isis-segment-routing-extensions.
>
>
>
> Section 3.4 of RFC 8402 <https://tools.ietf.org/html/rfc8402>  defines
> definition and handling of global Adj-SIDs.
>
> The relevant text is given below:
>
>
>
> 
>
>Similarly, when using a global Adj-SID, a packet injected anywhere
>
>within the SR domain with a segment list {SNL}, where SNL is a global
>
>Adj-SID attached by node N to its adjacency over link L, will be
>
>forwarded along the shortest path to Nand then be switched by N,
>
>without any IP shortest-path consideration, towards link L.
>
> ...
>
>The use of global Adj-SID allows to reduce the size of the segment list
>
>When expressing a path at the cost of additional state (i.e., the global
>
>Adj-SID will be inserted by all routers within the area in their
>
>forwarding table).
>
> 
>
>
>
> The definition of the Adjacency Segment Identifier Sub-TLV in Section
> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it
> allows advertisement of global Adj-SIDs.
>
> These advertisements can be associated with a specific IGP adjacency
> and, in multi-topology scenarios, a specific topology. But it is not
> associated with any specific algorithm since the default algorithm for
> reaching the advertising node is implicitly assumed in full alignment
> with RFC 8402.
>
>
>
> My question is about the situation in which multiple algorithms are
> supported by the routers in the SR domain, so that each node advertises
> a dedicated Node SID for each of these algorithm.
>
> In this scenario, the operator can set up a SR-TE LSP that meets
> specific constraints (incorporated in one of these algorithms, see IGP
> Flexible Algorithm
> <https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-01> draft) by
> using Node SIDs that have been advertised with the corresponding
> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used
> (e.g., for reducing the label stack depth) in this situation.
>
> I wonder if the possibility to advertise global Adj-SID (that can be
> considered as replacing a combination of the Node SID of the advertising
> node and one of its local Adj-SIDs) as associated with a specific
> algorithm has ever been considered?

to be honest, it has been not.

The usage of the global Adj-SID has not been widely considered due to
the additional forwarding entries it requires on rest of the routers in
the area. Not sure if there are implementations of the global ADj-SID
out there.

If you believe this is important, we can certainly addressed that in a
small draft.

thanks,
Peter




>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
>
> ___
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and
> then delete the original
> and all copies thereof.
> ___
>
>
> ___
> spring mailing list
> spr...@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and wh

[Lsr] FlexAlgo and Global Adj-SIDs

[Alexander Vainshtein]

Dear colleagues,
I have a question regarding global Adj-SIDs in 
draft-ietf-isis-segment-routing-extensions.

Section 3.4 of RFC 8402  defines 
definition and handling of global Adj-SIDs.
The relevant text is given below:


   Similarly, when using a global Adj-SID, a packet injected anywhere
   within the SR domain with a segment list {SNL}, where SNL is a global
   Adj-SID attached by node N to its adjacency over link L, will be
   forwarded along the shortest path to N and then be switched by N,
   without any IP shortest-path consideration, towards link L.


   The use of global Adj-SID allows to reduce the size of the segment list

   When expressing a path at the cost of additional state (i.e., the global

   Adj-SID will be inserted by all routers within the area in their

   forwarding table).


The definition of the Adjacency Segment Identifier Sub-TLV in Section 2.2.1 of 
the draft matches the behavior defined in RFC 8402, i.e., it allows 
advertisement of global Adj-SIDs.
These advertisements can be associated with a specific IGP adjacency and, in 
multi-topology scenarios, a specific topology. But it is not associated with 
any specific algorithm since the default algorithm for reaching the advertising 
node is implicitly assumed in full alignment with RFC 8402.

My question is about the situation in which multiple algorithms are supported 
by the routers in the SR domain, so that each node advertises a dedicated Node 
SID for each of these algorithm.
In this scenario, the operator can set up a SR-TE LSP that meets specific 
constraints (incorporated in one of these algorithms, see IGP Flexible 
Algorithm draft) by 
using Node SIDs that have been advertised with the corresponding algorithm and 
local Adj-SIDs. However, global Adj-SIDs cannot be used (e.g., for reducing the 
label stack depth) in this situation.
I wonder if the possibility to advertise global Adj-SID (that can be considered 
as replacing a combination of the Node SID of the advertising node and one of 
its local Adj-SIDs) as associated with a specific algorithm has ever been 
considered?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Alexander Vainshtein]

Hi all,
I concur with Adrian: polucy-based routing is quite different from MTR that 
uses DSCP to map a packet to a specifuc totology and/or from using DSCP for 
selecting a dedicated queue for a packet.

My 2c.

Thumb typed by Sasha Vainshtein


From: Lsr  on behalf of adr...@olddog.co.uk 

Sent: Monday, November 19, 2018 3:08:52 PM
To: 'Acee Lindem (acee)'; 'Dongjie (Jimmy)'; 'Les Ginsberg (ginsberg)'; 
'Toerless Eckert'; lsr@ietf.org
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

I think that this thread keeps mixing concepts. As Acee says, using DSCP to 
select a topology is feasible. Similarly, using DSCP to govern access to / 
usage of resources is a thing (as Jeff said for slicing, and as other have said 
for queues, etc.)

But that is a far thing from policy-based routing which is, erm, something else 
altogether.

Adrian

-Original Message-
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 19 November 2018 12:49
To: Dongjie (Jimmy) ; Les Ginsberg (ginsberg) 
; Toerless Eckert ; lsr@ietf.org
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Hi Jie,

Actually, the usage of DSCP to steer traffic onto a topology was specified in 
RFC 4915. However, this required an ecosystem to provision and mark traffic as 
it ingressed the OSPF MT routing domain (which was not specified). We (Cisco) 
had an implementation in the mid-2000s but it really didn't get a lot of 
deployment or implementation by other vendors.

Thanks,
Acee

On 11/19/18, 4:55 AM, "Lsr on behalf of Dongjie (Jimmy)"  wrote:

Hi Les,

Thanks for the summary and citations.

To my understanding, although DSCP based steering could be used in 
multi-topology scenarios, such usage is not defined in IETF specifications. 
Actually there can be many ways of choosing which topology is used for the 
forwarding of a particular packet. Thus the relationship between DSCP and MT is 
not that tightly coupled.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
> Sent: Thursday, November 15, 2018 12:41 PM
> To: Toerless Eckert ; lsr@ietf.org
> Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q
>
> Toerless -
>
> It's pretty hard to understand the context for your email.
>
> What leads you to believe that any of the MT specifications you mention 
say
> anything normative about DSCP and topologies??
>
> RFC4915 does not mention DSCP at all - but does make the statement:
>
> https://tools.ietf.org/html/rfc4915#section-3.8
> "It is outside of the scope of this document to specify how the
>information in various topology specific forwarding structures are
>used during packet forwarding or how incoming packets are associated
>with the corresponding topology."
>
> RFC 5120 does mention DSCP, but only as an example of something that 
"could"
> be used to determine on what topology a packet should be forwarded.
>
> RFC 7722 also mentions DSCP as an example, but there is a statement in 
Section
> 3:
>
> "It is assumed, but
>outside the scope of this specification, that the network layer is
>able to choose which topology to use for each packet"
>
> IGP WGs have never attempted to recommend (let alone normatively define)
> any relationship between DSCP and MT.
>
> ???
>
>Les
>
> > -Original Message-
> > From: Lsr  On Behalf Of Toerless Eckert
> > Sent: Wednesday, November 14, 2018 6:29 PM
> > To: lsr@ietf.org
> > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> >
> > Whats the current best guidance on using DSCP for selection of path,
> > specifically for selection of topology with MTR (RFCs 4915, 5120, 7722) 
?
> >
> > My understanding from history is that this looked like a good idea to
> > customers first, but when implementations became available, customers
> > really did not want to implement it because of the overloading of DSCP
> > between QoS and routing and the resulting management complexity.
> >
> > Has the idea of using DSCP for path selection been re-introduced in
> > any later work like flex-Algos ?
> >
> > If there could be rough consensus that this is in general a bad idea,
> > i wonder if it would be appropriate to have a short normative document
> > from LSR defining that the use of DSCP for topology selection is
> > historic and not recommended anymore and make this an update to above
> > three RFCs, maybe also pointing out that there are other methods to
> > select a topology and those remain viable:
> >
> > I specifically would not like to see the actual MTR RFCs to be changed
> > in status, because MTR actually does work quite well and is supported
> > in products an

Re: [Lsr] A question about Mirror SID and its advertisement using IS-IS

[Alexander Vainshtein]

Les,
Lots of thanks for a prompt response.
The proposed text looks fine to me.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, June 19, 2018 11:00 PM
To: Alexander Vainshtein ; 
draft-ietf-isis-segment-routing-extensions@ietf.org
Cc: Michael Gorokhovsky ; spr...@ietf.org; 
lsr@ietf.org
Subject: RE: A question about Mirror SID and its advertisement using IS-IS

Sasha -

Thanx for pointing this out.

Up until V13 of the draft the SID/Label Binding TLV had multiple use cases and 
there was introductory text in Section 2.4 which described these use cases.
All use cases other than SRMS were removed in V13 (principally the ERO types) 
as they were not in use and the introductory text was removed.

Support for Mirror SID was restored in V14 (thanx to Chris Bowers) but we never 
updated the introductory text in Section 2.4 to reflect this.

Attached are proposed diffs to address this gap. Hopefully this will resolve 
the issue for you.

   Les


From: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>
Sent: Tuesday, June 19, 2018 7:27 AM
To: 
draft-ietf-isis-segment-routing-extensions@ietf.org<mailto:draft-ietf-isis-segment-routing-extensions@ietf.org>
Cc: Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
spr...@ietf.org<mailto:spr...@ietf.org>; l...@ietf..org<mailto:lsr@ietf.org>
Subject: A question about Mirror SID and its advertisement using IS-IS

Hi all,
I have a question about Mirror SID as defined in the SR 
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
draft and its advertisement defined in the IS-IS extensions for 
SR<https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/>
 draft.

Mirror SID is defined in Section 5.1 of the SR Architecture draft as following:
5.1<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-5.1>.
  IGP Mirroring Context Segment


   One use case for a Binding Segment is to provide support for an IGP
   node to advertise its ability to process traffic originally destined
   to another IGP node, called the Mirrored node and identified by an IP
   address or a Node-SID, provided that a "Mirroring Context" segment be
   inserted in the segment list prior to any service segment local to
   the mirrored node.

   When a given node B wants to provide egress node A protection, it

   advertises a segment identifying node's A context.  Such segment is

   called "Mirror Context Segment" and identified by the Mirror SID.



   The Mirror SID is advertised using the binding segment defined in SR

   IGP protocol extensions 
[I-D.ietf-isis-segment-routing-extensions<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#ref-I-D.ietf-isis-segment-routing-extensions>]
 .



   In the event of a failure, a point of local repair (PLR) diverting

   traffic from A to B does a PUSH of the Mirror SID on the protected

   traffic.  B, when receiving the traffic with the Mirror SID as the

   active segment, uses that segment and processes underlying segments

   in the context of A.

Please note that these definitions do not mention SR Mapping Server or any such 
thing.

At the same time, the IS-IS Extensions for SR draft only mentions mirror 
context in Section 2.4 that says:

2.4<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#section-2.4>.
  SID/Label Binding TLV





   The SID/Label Binding TLV MAY be originated by any router in an IS-IS

   domain.



   The SID/Label Binding TLV is used to advertise prefixes to SID/Label

   mappings.  This functionality is called the Segment Routing Mapping

   Server (SRMS).  The behavior of the SRMS is defined in

   
[I-D.ietf-spring-segment-routing-ldp-interop<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#ref-I-D.ietf-spring-segment-routing-ldp-interop>].

2.4.1<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#section-2.4.1>.
  Flags





   Flags: 1 octet field of following flags:



0 1 2 3 4 5 6 7

   +-+-+-+-+-+-+-+-+

   |F|M|S|D|A| |

   +-+-+-+-+-+-+-+-+



   where:



  F-Flag: Address Family flag.  If unset, then the Prefix carries an

  IPv4 Prefix.  If set then the Prefix carries an IPv6 Prefix.



  M-Flag: Mirror Context flag.  Set if the advertised SID

  corresponds to a mirrored context.  The use of the M flag is

  described in 
[I-D.ietf-spring-segment-routing<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#ref-I-D.ietf-spring-segment-routing>].



This seems to imply that mirrored context is related to the SRMS - but, to the 
best of my understanding, these are completely unrelated.
Please note also that the SR Architecture draft says th

[Lsr] A question about Mirror SID and its advertisement using IS-IS

[Alexander Vainshtein]

Hi all,
I have a question about Mirror SID as defined in the SR 
Architecture 
draft and its advertisement defined in the IS-IS extensions for 
SR
 draft.

Mirror SID is defined in Section 5.1 of the SR Architecture draft as following:
5.1.
  IGP Mirroring Context Segment


   One use case for a Binding Segment is to provide support for an IGP
   node to advertise its ability to process traffic originally destined
   to another IGP node, called the Mirrored node and identified by an IP
   address or a Node-SID, provided that a "Mirroring Context" segment be
   inserted in the segment list prior to any service segment local to
   the mirrored node.

   When a given node B wants to provide egress node A protection, it

   advertises a segment identifying node's A context.  Such segment is

   called "Mirror Context Segment" and identified by the Mirror SID.



   The Mirror SID is advertised using the binding segment defined in SR

   IGP protocol extensions 
[I-D.ietf-isis-segment-routing-extensions]
 .



   In the event of a failure, a point of local repair (PLR) diverting

   traffic from A to B does a PUSH of the Mirror SID on the protected

   traffic.  B, when receiving the traffic with the Mirror SID as the

   active segment, uses that segment and processes underlying segments

   in the context of A.

Please note that these definitions do not mention SR Mapping Server or any such 
thing.

At the same time, the IS-IS Extensions for SR draft only mentions mirror 
context in Section 2.4 that says:

2.4.
  SID/Label Binding TLV





   The SID/Label Binding TLV MAY be originated by any router in an IS-IS

   domain.



   The SID/Label Binding TLV is used to advertise prefixes to SID/Label

   mappings.  This functionality is called the Segment Routing Mapping

   Server (SRMS).  The behavior of the SRMS is defined in

   
[I-D.ietf-spring-segment-routing-ldp-interop].

2.4.1.
  Flags





   Flags: 1 octet field of following flags:



0 1 2 3 4 5 6 7

   +-+-+-+-+-+-+-+-+

   |F|M|S|D|A| |

   +-+-+-+-+-+-+-+-+



   where:



  F-Flag: Address Family flag.  If unset, then the Prefix carries an

  IPv4 Prefix.  If set then the Prefix carries an IPv6 Prefix.



  M-Flag: Mirror Context flag.  Set if the advertised SID

  corresponds to a mirrored context.  The use of the M flag is

  described in 
[I-D.ietf-spring-segment-routing].



This seems to imply that mirrored context is related to the SRMS - but, to the 
best of my understanding, these are completely unrelated.
Please note also that the SR Architecture draft says that the Mirroring Context 
SID is a segment that identifies the node, and not any prefix. And, of course 
the SR Architecture draft does not describe usage of any flags.

What (if anything) did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr