Re: [spring] Will CSPF be affected by ISIS Overload bit ...?

[stephane.litkowski]

Hi,

Speaking as a big user of OL bit for ops and design purpose, yes CSPF needs to 
take it into account.

Brgds,

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Girish Pattanaik
Sent: Wednesday, December 19, 2018 19:12
To: spring@ietf.org
Cc: Girish Pattanaik
Subject: [spring] Will CSPF be affected by ISIS Overload bit ...?

Hi All,

My self Girish Pattanaik, am working as a Techlead in IPI India.

As we know Today, the use cases of the O bit in ISIS have evolved beyond its 
original meaning and intention. Its widely used by administrators .As per 
understanding setting overload bit on transit  will only affect the SPF 
calculation on head end,
So now point is, will it also affect the CSPF calculation?, And if not then how 
will we handle this overload bit  scenario for CSPF.?

I didn’t find this any such scenario has mentioned  in your current draft, so 
mailing you to get the appropriate answer for this.




Cheers!!
Girish Pattanaik


..

_

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

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

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

Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

As mentioned, you could not be aware of all the constraints that we have and 
BGP 3107 is not an option.
Note that this kind of redistribution can even happen within a single AS. We 
had some OSPF domain prefixes leaked in the ISIS L2 in the past in a single AS. 
Nothing prevents this design to come back again.

From: 徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Tuesday, November 20, 2018 09:35
To: spring; Aijun Wang; LITKOWSKI Stephane OBS/OINIS; l...@ietf.org
Cc: spring@ietf.org
Subject: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

If I understood it correctly, draft-wang-lsr-ospf-prefix-originator-ext-00 is 
an OSPF counterpart of RFC7794 from the perspective of correlation of prefixes 
and their originator in the inter-area scenario. As such, these two drafts are 
useful for the usage of ELC in the inter-area scenario.

As for the inter-AS scenario, IMHO, BGP LSP over SR LSP is the best choice. In 
other words, I doubt the necessity of advertising the ELC across ASes VIA IGP 
REDISTRIBUTION.

Best regards,
Xiaohu
--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 14:52
To:Aijun Wang ; stephane.litkow...@orange.com 
; l...@ietf.org 
Cc:spring@ietf.org 
Subject:Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Aijun –

In the inter-AS case, what is needed is to know ELC of the originating node. 
Simply knowing who the originator of an advertisement is not sufficient.

If ELC is advertised as a node capability, then a controller with access to 
BGP-LS database for both ASs could determine ELC by piecing together the node 
capability advertisement and the prefix advertisement w originating router-id.

But what Stephane has proposed for the inter-AS case is a way to know ELC in 
the absence of a controller.
This means nodes in AS #1 need to have ELC capability info for nodes in AS #2.
As there is no way to redistribute IGP Node Capability advertisements between 
different IGP instances, the alternative is to advertise ELC associated with a 
prefix advertisement since the prefix advertisement can be redistributed 
between IGP instances.
Knowing the originator of the prefix is necessary, but it is not sufficient.

Hope this is clear.

Les



From: Aijun Wang 
Sent: Monday, November 19, 2018 10:41 PM
To: Les Ginsberg (ginsberg) ; 
stephane.litkow...@orange.com; l...@ietf.org
Cc: spring@ietf.org
Subject: 答复: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi, Les and Stephane:

https://tools.ietf.org/html/draft-wang-lsr-ospf-prefix-originator-ext-00 is 
trying to solve what you are concerning for.
As you said, ELC/ERLD are functionally node capabilities, but when we try to 
send traffic, we should consider the prefixes itself.
The above draft proposal to add prefix originator to address this. After 
getting this information, the receiver can then build the relationship between 
prefixes and ELC/ERLD.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2018年11月20日 2:00
收件人: stephane.litkow...@orange.com; 
l...@ietf..org
抄送: spring@ietf.org
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: l...@ietf.org
Cc: spring@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per 

Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

We can’t for some internal design/security reasons.

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Tuesday, November 20, 2018 09:10
To: spring; Lsr; l...@ietf.org
Cc: spring@ietf.org
Subject: Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Why not directly use the BGP over SR model just like the BGP over LDP model?

Best regards,
Xiaohu

--
From:stephane.litkowski 
Send Time:2018年11月20日(星期二) 15:20
To:徐小虎(义先) ; Lsr ; 
l...@ietf.org 
Cc:spring@ietf.org 
Subject:Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

The use case is without TE. And this is how network designs are working today, 
and I do not see any valid reason to complexify and change the existing designs 
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is 
quite simple.

Brgds,

From:徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; l...@ietf.org
Cc: spring@ietf.org
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

IMHO, it seems a little bit odd to support inter-AS TE scenarios in the absence 
of a controller. If the inter-AS scenario is not for the TE purpose, would the 
(inter-AS) BGP-initiated LSP over (intra-AS) SR-initiated LSP be good enough 
(just like what we have done before in the LDP era, i.e., the BGP-initiated LSP 
over LDP-initiated LSP)?

Best regards,
Xiaohu

--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 02:00
To:stephane.litkow...@orange.com ; l...@ietf.org 

Cc:spring@ietf.org 
Subject:Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr  On Behalf Of stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: l...@ietf.org
Cc: spring@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not 

Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

Hi all,

The use case is without TE. And this is how network designs are working today, 
and I do not see any valid reason to complexify and change the existing designs 
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is 
quite simple.

Brgds,

From: 徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; l...@ietf.org
Cc: spring@ietf.org
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

IMHO, it seems a little bit odd to support inter-AS TE scenarios in the absence 
of a controller. If the inter-AS scenario is not for the TE purpose, would the 
(inter-AS) BGP-initiated LSP over (intra-AS) SR-initiated LSP be good enough 
(just like what we have done before in the LDP era, i.e., the BGP-initiated LSP 
over LDP-initiated LSP)?

Best regards,
Xiaohu

--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 02:00
To:stephane.litkow...@orange.com ; l...@ietf.org 

Cc:spring@ietf.org 
Subject:Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr  On Behalf Of stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: l...@ietf.org
Cc: spring@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not involved in the signaling of the binding 
SID, there is nothing to do in these drafts.


Let us know your comments/feedback on this proposal so we can progress these 
documents.

Brgds,

Stephane


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 

[spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn't found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not involved in the signaling of the binding 
SID, there is nothing to do in these drafts.


Let us know your comments/feedback on this proposal so we can progress these 
documents.

Brgds,

Stephane


_

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

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

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

Re: [spring] Is TI-LFA compatible with the default SR algorithm?

[stephane.litkowski]

Hi Sasha,

Could you elaborate on :" I strongly suspect that it is not so, and that these 
mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an 
example that confirms this suspicion.)" ?

Thanks,


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, June 13, 2018 17:00
To: draft-bashandy-rtgwg-segment-routing-ti-lfa.auth...@ietf.org
Cc: Stewart Bryant; Michael Gorokhovsky; 
draft-ietf-spring-segment-routing.auth...@ietf.org; spring@ietf.org; 
rt...@ietf.org
Subject: [spring] Is TI-LFA compatible with the default SR algorithm?

Hi all,
I have looked up Section 3.1.1 "Prefix-SID Algorithm" of the Segment Routing 
Architecture 
draft (already In the RFC Editor queue) and found there the following statement 
(the relevant part is highlighted):

This document defines two algorithms:

   o  "Shortest Path": this algorithm is the default behavior.  The
  packet is forwarded along the well-known ECMP-aware SPF algorithm
  employed by the IGPs.  However it is explicitly allowed for a
  midpoint to implement another forwarding based on local policy.
  The "Shortest Path" algorithm is in fact the default and current
  behavior of most of the networks where local policies may override
  the SPF decision.

   o  "Strict Shortest Path (Strict-SPF)": This algorithm mandates that
  the packet is forwarded according to ECMP-aware SPF algorithm and
  instructs any router in the path to ignore any possible local
  policy overriding the SPF decision.  The SID advertised with
  Strict-SPF algorithm ensures that the path the packet is going to
  take is the expected, and not altered, SPF path.  Note that Fast
  Reroute (FRR) [RFC5714] mechanisms 
are still compliant with the
  Strict Shortest Path.  In other words, a packet received with a
  Strict-SPF SID may be rerouted through a FRR mechanism.

At the same time, the TI-LFA 
draft
 discusses protection of active Prefix-SIDs (e.g., in Section 3 that discusses 
P-Space and Q-space) but, to the best of my understanding, does not mention 
algorithms that form the context of these SIDs.

My question to the authors of the TI-LFA draft is:

Are the mechanisms defined in the draft (and examples discussed in Section 4) 
applicable to Prefix-SIDs associated with the default forwarding algorithm as 
defined in the Segment Routing Architecture draft?

I strongly suspect that it is not so, and that these mechanisms are only 
compatible with the Strict-SPF. (Actually, I can provide an example that 
confirms this suspicion.)

Do I miss something substantial here?

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.
___

_

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

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

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

Re: [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

[stephane.litkowski]

Hi,

As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD means 
that the node is defacto ELC (so advertising ELC separately is not necessary):

" The Entropy Readable Label Depth (ERLD) is defined as the number of
   labels a router can both:

   a.  Read in an MPLS packet received on its incoming interface(s)
   (starting from the top of the stack).

   b.  Use in its load-balancing function.

   The ERLD means that the router will perform load-balancing using the
   EL label if the EL is placed within the ERLD first labels.
"

"
To advertise an ERLD value, a SPRING router:

   o  MUST be entropy label capable and, as a consequence, MUST apply
  the dataplane procedures defined in [RFC6790].

   o  MUST be able to read an ELI/EL which is located within its ERLD
  value.

   o  MUST take into account this EL in its load-balancing function.
"


Brgds,


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter 
(Nokia - BE/Antwerp)
Sent: Wednesday, June 13, 2018 11:10
To: Ketan Talaulikar (ketant); i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are 
signaled for ISIS, OSPF and BGP-LS. 

If the WG's can manage to agree upon a decision (option1/2/3 or 4), then next, 
have a look into how to encode the TLV so that we have a clean technological 
solution space.

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 10:45
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

In that case, I concur with you that option (2) is better than the others. My 
only difference in opinion is that ERLD not have its own separate TLV but 
instead get advertised as a new MSD sub-type - it is just a different encoding.

Thanks,
Ketan

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)  
Sent: 13 June 2018 13:55
To: Ketan Talaulikar (ketant) ; i...@ietf.org; l...@ietf.org; 
spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding seems to make little sense and only bring confusion 
>(router/controller implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion)
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2))
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators
* most simple solution for implementers (routers and controller)
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 

Re: [spring] IPR Poll for draft-ietf-spring-segment-routing-mpls

[stephane.litkowski]

Hi,

I'm not aware of any IPR

From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, May 24, 2018 19:28
To: SPRING WG List; draft-ietf-spring-segment-routing-m...@ietf.org
Subject: IPR Poll for draft-ietf-spring-segment-routing-mpls

Hi SPRING WG,

In parallel to the WGLC for draft-ietf-spring-segment-routing-mpls, we would 
like to poll for IPR.

If you are aware of IPR that applies to draft-ietf-spring-segment-routing-mpls 
please respond to this email. If you are aware of IPR, please indicate whether 
it has been
disclosed in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 
provide more details).

If you are an *author or contributor* please respond to this email regardless 
of whether or not you're aware of any IPR. If you are not an author or 
contributor, please explicitly respond only if you are aware of IPR that has 
not yet been disclosed.

This document will not advance until IPR confirmations have been received from 
all authors and contributors.

Thanks,
Bruno & Rob.


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

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

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

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

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

[stephane.litkowski]

Support

Not aware of any IPR


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, May 16, 2018 17:20
To: SPRING WG List
Subject: [spring] Working Group Adoption Call for 
draft-filsfils-spring-segment-routing-policy

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-filsfils-spring-segment-routing-policy. Please indicate your support, or 
otherwise, for adopting this draft as a working group item by 30th May 2018. We 
are particularly interested in hearing from working group members that are not 
co-authors of this draft.

As part of the discussions of adopting this draft into SPRING with the ADs and 
chairs of other WGs, there are a number of requests to the authors.

1. Please clarify in the text traffic steering with "SR policy" and its 
relationship to other traffic engineering functions. It seems to me that this 
work is generally describing how one selects and steers traffic into policies, 
rather than path calculation. Additional clarification of whether this is the 
case (or not), would be welcome to ensure that the relationship with other work 
is clear. We would ask the authors to consider whether sections 14.1-14.4 are 
required scope of this document.

2.. Consider what the core content of this document is, and how it can be make 
as concise and clear as possible. There are some specific suggestions that can 
be made here, but we would like to see this discussed with the working group.

Additionally, there are currently 17 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others.. An approach to achieving this would be to list ~2 
editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this document. 
We will need all 17 authors to confirm their IPR position on this document.

Thanks,
Bruno & Rob.

_

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

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

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

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

Hi Daniel,

You may need to introduce new hardware as well for SRTE to handle the number of 
labels to push.
If your hardware is flexible (network processors), there is a chance that it 
can also handle NSH.

Now if you want just to use SR policies to perform a kind of service chaining, 
is there something really specific to develop ? Can’t you do this today with 
the “existing” SRTE machinery and SIDs that are available: you need Node-SID 
for transport compression, and a SID to forward to the VNF (similar to the EPE 
SID).

Brgds,

Stephane


From: Bernier, Daniel [mailto:daniel.bern...@bell.ca]
Sent: Wednesday, March 21, 2018 00:53
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; 
LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian 
Farrel
Cc: mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


+1 to Jim and Avinash



Same challenge on our side.



Our network is built upon a MPLS data plane. My current "network appliances" 
are connected to MPLS devices and service instantiation done through static 
pseudowires. It will be easier for me to introduce SRTE policy capabilities 
through software upgrades instead of certifying and introducing new hardware to 
enable a newer encap.



And by the time we get to leverage contextual metadata between functions, most 
probably, these will have also evolved (micro-services, hw/sw disaggregation) 
and new ways of conveying that metadata will have been proposed.



Thanks,



PS: I am also wondering why it is so badly seen to look at alternatives to NSH 
SFC while at the same time we introduce new WG to discuss DC routing (RIFT, 
LSVR, ...). If we accept multiplicity in that space, and I think we should, 
then we should allow it in chain composition and programming.



Cheers,



Daniel Bernier




From: mpls > on behalf of 
mohamed.boucad...@orange.com 
>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, 
Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; b...@ietf.org; 
s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

You said that you “simply need SR to realize the chain”, but actually if you 
want a path to be steered relying upon some information conveyed in the packet 
and to invoke specific SFs, then you need to define the structure of such 
information and its meaning.

That is another piece of specification work to be yet done if you want it to be 
part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; 
Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; BOUCADAIR Mohamed 
IMT/OLN >; 
UTTARO, JAMES >; Henderickx, Wim (Nokia - 
BE/Antwerp) >; Robert 
Raszuk >; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your 

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

For simple service chains, policy routing works fine as well (this was what was 
used before bess-service-chaining has come). It becomes a nightmare when the 
service chains are complex.

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com]
Sent: Tuesday, March 20, 2018 11:35
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR 
Mohamed IMT/OLN; Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; b...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim whats wrong with this draft:
https://tools.ietf.org/html/draft-ietf-bess-service-chaining-04

It provides simple service chaining using MPLS techniques


From: "UTTARO, JAMES" >
Date: Tuesday, 20 March 2018 at 11:30
To: Stephane Litkowski 
>, 
"LINGALA, AVINASH" >, "mohamed. 
boucadair" >, 
"Henderickx, Wim (Nokia - BE/Antwerp)" 
>, Robert Raszuk 
>, Adrian Farrel 
>
Cc: mpls >, SPRING WG List 
>, 
"s...@ietf.org" >, 
"b...@ietf.org" >
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; BOUCADAIR Mohamed 
IMT/OLN >; 
UTTARO, JAMES >; Henderickx, Wim (Nokia - 
BE/Antwerp) >; Robert 
Raszuk >; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; b...@ietf.org; 
s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever 

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; b...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; b...@ietf.org; 
s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are 
requirements/constraints/new practices/new OAM procedures that need to be 
supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES 

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

Hi,

I’m worrying that MPLS based SFCs may slowdown implementations of NSH.
Vendors have usually a limited bandwidth to implement new features especially 
when the dataplane is involved. I would personally prefer to get the resources 
allocated to NSH rather than MPLS based SFCs.
This is not just a matter of operator preference, as if vendor#1 prioritizes 
MPLS SFC and vendor#2 prioritizes NSH, multiple operators may get stuck for a 
while when operating a multivendor network.

Whatever the encaps is, the operational team will have to ramp up on the SFC 
architecture and on the associated controlplane. The encaps/dataplane is a 
small part of the operational side.

I’m personally in favor to focus on NSH even if I’m an MPLS geek. We already 
have running SFCs that are based on bess-service-chaining as an interim 
solution.


Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 14:25
To: UTTARO, JAMES; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian 
Farrel
Cc: mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are 
requirements/constraints/new practices/new OAM procedures that need to be 
supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation 

Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

[stephane.litkowski]

Hi Les,

I think there is a fundamental disagreement here.
"SR Global Block (SRGB): local property of an SR node.  In the MPLS
   architecture, SRGB is the set of local labels reserved for global
   segments."

We agree that the SRGB is a per node property, but a per node+per protocol SRGB 
is still compliant with this and there was a consensus on the list to let 
implementations having a per protocol SRGB configuration on each node (this was 
reflected in the YANG model).

"An IGP-Prefix segment is an IGP segment attached to an IGP prefix.
   An IGP-Prefix segment is global (unless explicitly advertised
   otherwise) within the SR/IGP domain."

This statement clearly mentions the IGP domain as the boundary...

"In the context of an instance and a topology, multiple Prefix-SID's
   MAY be allocated to the same IGP Prefix as long as the algorithm
   value is different in each one."

This also mentions that the statement is limited to a particular IGP instance 
and topology and does not imply anything for cross instances...

Honestly when the architecture document was written, it was with only a single 
IGP instance/domain in mind...


Brgds,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, August 02, 2017 20:06
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; 
spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Stephane -

I think it is important to look at conflict resolution in the context of the SR 
architecture. Much of what you discuss below is inconsistent with the SR 
architecture and as a result it creates new problems that actually don't need 
to be solved.
Let me see if I can get us back on the same page.

As previously quoted,  
https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.txt Section 
2:
 (emphasis added)

"SR Global Block (SRGB): local property of an SR node.  In the MPLS
   architecture, SRGB is the set of local labels reserved for global
   segments."

>From the same draft, Section 3 we have other relevant statements:

"An IGP-Prefix segment is an IGP segment attached to an IGP prefix.
   An IGP-Prefix segment is global (unless explicitly advertised
   otherwise) within the SR/IGP domain."

"In the context of an instance and a topology, multiple Prefix-SID's
   MAY be allocated to the same IGP Prefix as long as the algorithm
   value is different in each one."

There are a number of conclusions which follow from these statements.

1)An SRGB is a node property, it is NOT a per protocol property

2)The SID associated with a prefix is a property of the prefix, not the 
protocol which advertises it.

3)One - and only one - SID is associated with a given prefix/algorithm

4)The SR architecture is NOT defining a per protocol forwarding plane - it is 
defining an SR forwarding plane

If we try to support per protocol SRGBs and allow per protocol SID assignments, 
this leads to a number of problems, some of which you have mentioned in your 
posts.
By far the biggest issue is that if we allow per protocol SID assignments, then 
we are actually REQUIRED to support non-overlapping per protocol SRGBs, which 
in turn means that we are REQUIRED to support multiple incoming labels for the 
same prefix.

This follows because a node has no way to determine which protocol will provide 
the winning route on its neighbors. It would therefore have to program all of 
the SIDs which the neighbor might use to forward traffic.
This in turn leads to the requirement for per protocol non-overlapping SRGBs 
because if we allow the same SID to be used for different prefixes so long as 
the advertising protocols are different, we then have to have a way of mapping 
that same SID to two different local labels. The only way to guarantee that is 
possible is to have per protocol non-overlapping SRGBs.

All of this is in conflict with the SR architecture as per the excerpts I have 
quoted above - which is why the conflict resolution drafts specifies


· one conflict resolution database populated by advertisements provided 
by all protocols/SRMSs.

· SRGB inconsistency detection on a per node basis

If there is concern that the current language in the draft is not explicit 
enough, I am happy to work on adding clarifying language.
But it is crucial to understand and agree that the choice to use a protocol 
independent database and per node SRGB is required by the SR Architecture.

A few more comments inline...


From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Wednesday, August 02, 2017 1:09 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; 
spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

No it's not, it's definitely not enough precise.

Telling that you include 

Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

[stephane.litkowski]

Hi,

In the current version of the draft, conflict evaluation does not look at the 
SRGB, it only looks at SIDs.
In any case, in the given example, there is a prefix conflict => multiple 
SIDs/labels associated to a single prefix.

>From an LFIB point of view, as per the current draft, only a single entry will 
>be installed as the others will be inactive in the mapping DB.
I agree that in this example two LFIB entries may be installed but this 
requires:

-  a per protocol conflict resolution to let one entry per protocol to 
be active.

-  managing SRGB overlap between protocols: specifications define that 
SRGB advertisement cannot overlap within a protocol, but not across protocols. 
It is obvious that an implementation must avoid to advertise overlapping SRGBs 
between two protocols (e.g. OSPF [1000,2000] and IS-IS [1200,2200]), but I do 
not think we mandate this somewhere (we do it inside a particular protocol 
instance) => I think we need to take care of this in any case as even if two 
SIDs are different, the resulting labels may be equal in case of SRGB overlap.

Brgds,


From: Dirk Goethals [mailto:dirk.goeth...@nokia.com]
Sent: Wednesday, August 02, 2017 10:38
To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); DECRAENE Bruno 
IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Hi,

N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.
IMHO, there is no real conflict as both SRGB are disjoint, so why
not proving both entries in LFIB?
Dirk
Op 2/08/2017 om 10:08 schreef 
stephane.litkow...@orange.com:
No it's not, it's definitely not enough precise.

Telling that you include all the entries (from all protocols) in the conflict 
resolution does not mean that cross protocol info may be used when programming 
the FIB. That's a different story.

And speaking as an operator, from a troubleshooting point of view it becomes a 
nightmare when you use some information coming from the protocol and some other 
informations coming from another source of information.

So let's say that I have two concurrent routes for a prefix on a node N:

OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1)
ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2)

N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.
N has the following SID mappings:
OSPF mappings:
(192,10.0.0.1/32,100,1,0,0)
(128,10.0.0.1/32,200,300,0,0)

ISIS mappings:
(192,10.0.0.1/32,300,1,0,0)
(128,10.0.0.1/32,400,300,0,0)


So to program the LFIB on N, I will take the ISIS route which is the active 
route in the RIB. I will so consider the ISIS SRGB of N but from a conflict 
resolution point of view, I will use the OSPF advertisement 
(192,10.0.0.1/32,100,1,0,0)

So my LFIB entry will be:
Inlabel: 2100, swap 2100 via Te0/2

In addition to that, the draft proposes a lower preference for BGP mappings, 
which introduces a hierarchy between protocols like a protocol preference.

Where is the global logic here ? It is really weird to retrieve some SR 
information from one protocol, and some others from another protocol.

I think we are touching things here that are not clearly defined by the 
architecture: the multi protocol behavior has never been clearly described, so 
we probably need to think about it and define something before rushing on the 
conflict resolution.

I see two main approaches:

a)  We can consider that OSPF-SR extensions and the regular OSPF protocol 
used for routing as completely separate things (same for IS-IS). So OSPF-SR 
extensions are considered as a label distribution protocol like LDP is. As LDP, 
it requires some routing informations to be used (that may come from the OSPF 
routing protocol or even IS-IS). So SR builds a kind of label information base 
(LIB) like LDP and then the routing process combines the LIB info with the 
active route to build the FIB entry. This approach is similar to what you try 
to achieve except that I suppose here that all the SR informations should come 
from a single source (so if we pick a binding from OSPF, we consider to use the 
OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, 
BGP-SR, even possibly LDP, we also need to create a preference mechanism 
between the protocols here as we do for the routing table. In such a scenario, 
when doing an IGP migration, I need to migrate the label distribution protocol 
part and also the routing protocol part possibly in multiple steps (by using 
preferences on each side). We need to define how we can distribute SR 
informations from one protocol to the other.



In this approach, using the example above, we should program this entry in the 
LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes 
from the IS-IS active route)


b)  We can consider another approach where the SR informations are tied 
with the routing protocol. When multiple 

Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

[stephane.litkowski]

Hi,

I think there is a misunderstanding on what the text says:
“  A first protection strategy consists in excluding any local repair
   but instead use end-to-end path protection where each SPRING path is
   protected by a second disjoint SPRING path.  In this case local
   protection MUST NOT be used.
“

The text presents a design option which is to use end-to-end path protection 
and prevent any local-repair. In this option (the text mention: “In this 
case”), for sure, we need to prohibit local protection as this is the 
requirement of this design option.

Now if you want to combine end-to-end protection + local protection, that’s up 
to you and that’s another design option. IMO, I would not push for this 
combined design as it brings more complexity rather than solving problems, but 
it’s a personal design opinion.

Brgds,


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, May 16, 2017 10:29
To: Stefano Previdi (sprevidi)
Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand; Ron Sdayoor; 
Rotem Cohen
Subject: Re: [spring] A belated comment on end-to-end path protection in 
draft-ietf-spring-resiliency-use-cases



Regards,
Sasha

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

From: Alexander Vainshtein
Sent: Tuesday, May 16, 2017 11:28 AM
To: 'Stefano Previdi (sprevidi)' >
Cc: 
draft-ietf-spring-resliency-use-ca...@ietf.org;
 spring@ietf.org; Shell Nakash 
>; Michael 
Gorokhovsky 
>; Sidd 
Aanand >; Ron Sdayoor 
>; Rotem Cohen 
>
Subject: RE: [spring] A belated comment on end-to-end path protection in 
draft-ietf-spring-resiliency-use-cases


Stefano,

Lots of thanks for a prompt response.



A couple of short comments if you do not mind:



Using 2119 language in a "use cases" document:

1.   Going back to the source I see that “MUST NOT… mean that the 
definition is an absolute prohibition of the specification”

2.   I agree that the use case document defines which scenarios should be 
addressed, but I do not see how it can impose an absolute prohibition on a 
certain scenario.



Little sense link protection has in the case of path protection:

1.   This was definitely correct for traditional traffic engineering 
because the “shortest traffic paths” (e.g., LDL PSPs) could be easily 
differentiated from the “engineered traffic paths”.

2.   In addition, traditional local protection (e.g., MPLS FRR using 
RSVP-TE) could deal with link and node failures regardless of whether the 
failed link or node appeared in the ERO of the protected path.

3.   IMHO and FWIW, with SR  the situation is quite different:

o   The shortest traffic paths not only coexist with engineered traffic paths: 
the latter are in many cases “tunneled” within the former.

o   Path protection cannot be applied to shortest traffic paths so they must 
rely on local protection

o   Local protection in the case of failure of a node or link that appears in 
the ERO of an engineered SR path is highly non-trivial at best, so path 
protection for the engineered LSPs looks like a preferred solution to me.

I fully agree with you that the operators deploying SR should provide feedback 
on this point based on actual operational experience.

Meanwhile I doubt that a priori declaring some use cases as absolutely 
prohibited is the right thing to do.



My 2c,

Sasha



Office: +972-39266302

Cell:  +972-549266302

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





-Original Message-
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein 
>
Cc: 
draft-ietf-spring-resliency-use-ca...@ietf.org;
 spring@ietf.org; Shell Nakash 
>; Michael 
Gorokhovsky 
>; Sidd 
Aanand >; Ron Sdayoor 
>; Rotem Cohen 
>
Subject: Re: [spring] A belated comment on end-to-end path protection in 
draft-ietf-spring-resiliency-use-cases





> On May 11, 2017, at 12:04 PM, Alexander 

Re: [spring] RtgDir review: draft-ietf-spring-resiliency-use-cases-08

[stephane.litkowski]

Hi Stefano,

Speaking as doc Shepherd, I do not see in the V09, how you are addressing Lou's 
point about 1:1 and 1+1 protection in the Section 2.
I think it make sense to add a simple explicit statement that  SPRING should 
support both approach. It is partially addressed by " The two paths may be used 
concurrently or as a primary and backup
   path where the secondary path is used when the primary failed." 
But the "concurrently" word is IMO ambiguous as it could mean 1+1 scheme or 
ECMP like behavior.

Brgds,


-Original Message-
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
Sent: Friday, April 28, 2017 12:54
To: Lou Berger
Cc: rtg-...@ietf.org; rtg-...@ietf.org; 
draft-ietf-spring-resiliency-use-cases@ietf.org; spring@ietf.org
Subject: Re: RtgDir review: draft-ietf-spring-resiliency-use-cases-08

Hi Lou,

thanks for the comment. I integrated them in the new version I’ll submit asap.

Thanks.
s.


> On Apr 24, 2017, at 6:15 PM, Lou Berger  wrote:
> 
> 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 
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/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-spring-resiliency-use-cases-08
> Reviewer: Lou Berger
> Review Date: April 24
> Intended Status: Informational
> 
> Summary:
> 
>I have some minor comments about this document that I think would 
> be good, but not necessary, to be resolved before publication.
> 
> Comments:
> 
> This document is concise and clear.  I only have minor/nit level 
> issues that could be addressed before publication, but I don't think 
> it critical as the document is being published as Informational.
> 
> Major Issues:
> 
>   No major issues found.
> 
> Minor Issues:
> 
> - Section 2 mentions reversion, while sections 3 and 4 do not.
>  This leaves reversion requirements open to interpretation.
>  I suggest explicitly stating if reversion is a required  option or 
> not in sections 3 and 4 as well.
> 
> - Section 2 mentions 1:1 style path protection.  Past/other work  on 
> protection also allowed for / uses 1+1 style protection.  Is
>  1+1 intentionally omitted? If not, I suggest allowing for it.
> 
> Nits:
> 
>>  referred to as local protection techniques or Fast Reroute  
>> techniques.
> 
> References should be provided for each technique.
> 
>>   It is essential that the primary and backup path benefit from an end-
>>   to-end liveness monitoring/verification.  The method and mechanisms
>>   that provide such liveness check are outside the scope of this
>>   document.
> 
> Given the importance of liveness monitoring, I think it would be worth 
> mentioned an example of such.
> 
> That's it!
> Lou
> 


_

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

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

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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[stephane.litkowski]

Support

-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@nokia.com] 
Sent: Friday, January 27, 2017 12:05
To: spring@ietf.org
Cc: draft-ietf-spring-segment-routing-m...@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Hello Working Group,

This email starts a 2-week Working Group Last Call on
draft-ietf-spring-segment-routing-mpls-06 [1].

¤ Please read the document if you haven't read the most recent version yet, and 
send your comments to the list, no later than the *12th of February*.
Note that this is *not only* a call for comments on the document; it is also a 
call for support (or not) to publish this document as a Proposed Standard RFC.

¤ We have already polled for IPR knowledge on this document and all Authors 
have replied.
IPR exists against this document and has been disclosed [2].

Thank you

M

---
[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
[2]
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-spring-segment-routing-mpls

_

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

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

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

Re: [spring] Issue with path protection for SR-TE LSPs

[stephane.litkowski]

Hi,

As Stefano mentioned, as it's a use case and requirement draft, we do not have 
to talk about solutions, and about issues in using one or other mechanism.
Such considerations about using or not some particular SIDs to fill the "path 
must not be protected by any local repair" constraint are up to a solution 
draft and not this document. Regarding this document, the requirement is clear 
: " SPRING architecture MUST provide a way to compute paths that MUST
  NOT be protected by local repair techniques", that's all we can expect 
from this document.

Best Regards,

Stephane


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, September 27, 2016 12:22
To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem Cohen
Subject: Re: [spring] Issue with path protection for SR-TE LSPs

Stefano, Bruno and all,
Lots of thanks for detailed responses that, frankly, now go much deeper than my 
original question.

My concern was about combining "regular" prefix SIDs advertised with the 
default algorithm and path protection for SR LSPs.
To the best of my understanding, within his, admittedly limited, scope:
- there is no way to guarantee that Main and Protection paths will remain 
disjoint following some topology changes in the network
- if some local protection for these SIDs is enabled in the network, there is 
no way to guarantee that it will not affect some segments of such LSPs.

To the best of my understanding, Stefano's answers says that you can use some 
"special" prefix-SIDs (e.g., marking them as not protecting, advertising tem 
with some non-default algorithm etc.). I have no problem with these answers - 
but from my POV they are out of the narrow scope of my original questions. 
I do not think that this draft should list any specific solutions. But maybe it 
should say that "the default prefix-SIDs" (i.e. prefix-SIDs advertised with the 
default algorithm etc.) should not be used in specification of SR-LSPs 
employing the path protection scheme?

Regards,
Sasha

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

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, September 27, 2016 12:08 PM
To: Stefano Previdi (sprevidi) 
Cc: spring@ietf.org; Alexander Vainshtein ; 
Shell Nakash ; Michael Gorokhovsky 
; 
draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer 
; Rotem Cohen 
Subject: Re: [spring] Issue with path protection for SR-TE LSPs

Hi Stefano,

> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: 
> Tuesday, September 27, 2016 10:53 AM
> 
 > > On Sep 27, 2016, at 9:50 AM, bruno.decra...@orange.com wrote:
 > >
 > > Hi Stefano,
 > >
 > > As an individual contributor, please find a comment inline  > >  > >> 
 > > From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: 
 > > Monday,  > September 26, 2016 11:22 AM  > >>  > >>   > >>  > >> 
 > >  > >>> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi) 
 > >  wrote:
 > >>>
 > >>> Hi Sasha,
 > >>>
 > >>> sorry for being late. See below.
 > >>>
 > >>>
 >  On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein  > >> 
 >   wrote:
 > 
 >  Hi all,
 >  I have read the SR Resiliency Use Cases draft and I have an issue with 
 >  the path  > >> protection use case.
 > 
 >  The draft defines this use case with the following 
 >  constrains/qualifiers (quoting  > from  > >> Section 2):
 >  · The operator configures two SPRING paths T1 and T2 from A to Z
 >  · Initially, the customer traffic (e.g., PW traffic) is sent 
 >  from A to Z via T1. When
 > >> T1 fails, the traffic is sent via T2.
 >  · The two paths are made disjoint using the SPRING architecture
 >  · The two configured paths T1 and T2 MUST NOT benefit from 
 >  local protection
 > 
 >  The draft does not go into any detail regarding the type of segments 
 >  that the  > operator  > >> uses when specifying T1 and T2, and the 
 >  example given in the draft can be interpreted  > in  > >> two ways:
 >  · T1 and T2 are specified using only adjacency SID
 >  · T1 and T2 are specified using node SIDs (or a mix of node 
 >  SIDs and adjacency
 > >> SIDs).
 > >>>
 > >>>
 > >>> this is intentional.
 > >>>
 > >>> It’s a use case draft where we describe the various protection 
 > >>> requirements and  > >> strategies for protection.
 > >>>
 > >>> It has never been intended to describe a specific solution.
 > >>>
 

[spring] REMINDER : Shepherd's review of draft-ietf-spring-resiliency-use-cases

[stephane.litkowski]

Hi Authors,

Could you please check the comment's below so we can continue to progress the 
document ?

Thanks !

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, August 22, 2016 15:14
To: draft-ietf-spring-resiliency-use-ca...@ietf.org
Cc: spring@ietf.org; rt...@ietf.org
Subject: [spring] Shepherd review of draft-oetf-spring-resiliency-use-cases

Hi,

I have been selected as Shepherd for this document, and as part of my review I 
have several comments that you will find below :

General :
Is it a requirement document ? If yes, it would be good to mention it. The 
document states requirements multiple times.


Abstract :
The abstract is really short, would be good to enhance it with what is exactly 
described.

In Section 1, there should be an issue with the XML file as the hypertext link 
is missing at : "We discuss two different approaches to provide ..., in Section 
3". Hyperlink missing for "Section 3".

In Section 2,
It would be good to state in the example that the paths must not be protected 
by any local repair techniques. Example : "The two paths are made disjoint 
using the SPRING architecture and must not be protected by any local repair 
techniques".

As a requirement, the two paths must be disjoint (link or node, or srlg), this 
has some impacts on the path expression : using a node-SID would be a bad idea 
as there is no guarantee. It would be good to mention that the solution must 
take care of this.

It would be easier to state that path T1 is primary and T2 is backup instead of 
: "When T1 is  up, the packets of the PW are sent on T1".
Why not using the following text :
"T1 is programmed as primary forwarding entry while T2 is a backup entry. In 
nominal state, PW traffic is carried over T1. When T1 fails, the PW traffic is 
switched on T2".
Before telling that the solution for end-to-end liveness is out of scope, it 
would be good to state that it is mandatory to have such mechanism to make the 
solution work. Is it a SPRING path liveness check or service liveness check ?  
It would be good to tell who is in charge of the detection and path switchover 
? is it LSP ingress, is it a node outside SPRING network ? If there are 
multiple options, please tell it.

I would propose to change the last sentence to highlight the two requirements 
in case we need SPRING path liveness check :
"From a SPRING viewpoint, the SPRING architecture MUST provide end-to-end 
liveness check of SPRING based LSPs. In addition, it MUST provide a way to 
create LSPs that must not be protected by local repair techniques."

Globally this section looks confusing to me. End to end protection could be 
achieved in multiple ways, for example :
- Having a dumb network that only provides disjoint non protected path and 
having end-to-end probes at service level that would help an external component 
to switchover traffic. Provider network is not aware of the protection done. In 
your figure we can add A' and Z', and we establish two disjoint LSPs (A->Z and 
A'->Z'). Customer is dual meshed to A/A' and Z/Z' and is managing liveness 
check and switchover (network is not involved).
- Having primary/backup like approach : two disjoint LSPs from A->Z , A 
programs one in FIB. A provides OAM on the LSP. When primary LSP fails, the 
second one is installed in FIB.
- Having FRR like approach : two disjoint LSPs from A->Z , A programs both in 
FIB in a FRR like fashion. A provides aggressive OAM on the LSPs to enable 
traffic switchover in a very short time.

The current text is not really clear on the proposed approach. Maybe another 
one ?


Section 3
s/the backup path computation should/the backup path computation SHOULD/
s/in any topology/in any topology./
s/by the IGP/by the IGP./

Section 3.1
"ending at the protected nexthop", that's true only for link protection, but 
not possible in case of node protection. This sentence is a generic one and is 
not specific to link protection case.
I cannot parse : "so as to bypass the failed component ..."
I would propose something like :
"One way to provide local repair is to enforce a failover along the shortest 
path around the protected component. In case of link protection,  the point of 
local repair will create a bypass avoiding the protected link and merging back 
to primary path at the nexthop. In case of node protection, the bypass will 
avoid the protected node and merge back to primary path at the next-nexthop."
What about SRLG case ?

"In our example, C protects Z", protects for what ? link / node /srlg failure ? 
proposed text : "In our example, C protects destination Z for a failure CD link"

"that it initially reaches via CD", yes and also using CH because of ECMP, it 
would be better to change the example to disable ECMP. There are multiple ECMPs 
that would not help the reading. Even A as ECMP to Z.


Section 3.2
"providing a repair for the destination based on shortest path state for that 
destination". Why using 

Re: [spring] draft-ietf-spring-conflict-resolution

[stephane.litkowski]

Hi Les,

Administrative distance (protocol preference) has always been used in router 
implementation for a while. Yes inconsistent configuration of admin distance 
can cause routing issues (loops or whatever ...). I'm not sure we can really 
bypass it ...
Regarding the preference algorithm, the SRMS weight must also need to be taken 
into account (as stated by Stefano, the conflict draft will need to be updated 
accordingly). We may be able to put it just after PFX > SRMS.

One other point regarding the draft is that it must be stated clearly that the 
different approach presented cannot be mixed in a network deployment, otherwise 
inconsistent behavior may occur.

The last point, as Bruno, from an operational network perspective, I'm more in 
favor to push the ignore overlap only rather than the quarantine which could 
break forwarding to a lot of destinations.

Best Regards,

Stephane


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, June 29, 2016 18:19
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

Bruno -


From: bruno.decra...@orange.com 
[mailto:bruno.decra...@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution

Hi Les,

IINM, I've not seen the follow up on one of my below questions.
So let me restate a comment:

The SR-MPLS SID conflicts algo requires that all nodes consider the same 
mapping advertisements.
How is this ensured, if it indifferently considers advertisements from all 
protocols, while some nodes could participate only in a subset of the 
protocols? e.g. OSPF only routers would consider a different set of information 
compared to OSPF+IS-IS routers.

[Les:] If you run multiple protocol instances (whether multiple instances of 
the same protocol or instances of different protocols) then you need to insure 
that at least one of the two conditions below is true:

· All routers receive the equivalent set of advertisements

· There are no conflicts :)

One way of insuring the first point is to exclusively use a mapping server to 
advertise SIDs, configure your SRMS entries in a protocol independent manner, 
and insure that the SRMS advertisements are sent in all of the protocol 
instance specific sub-domains.

If the intent is to deliberately use different labels in the forwarding plane 
for the same destination depending upon which protocol advertised the prefix, 
this introduces a number of new requirements - not the least of which is 
duplicate entries for the same prefix in the forwarding plane.  As has been 
discussed publicly in a different thread, there are cases (e.g. merging two 
networks) were such a requirement may exist - but it is the exception rather 
than the rule and as it consumes more resources in the forwarding plane and 
introduces implementation complexity independent of conflict resolution it is 
not the primary case the draft focuses on. Nevertheless, this is a case which 
the draft will address in the next revision. We stopped short of that in this 
revision because we felt there were enough substantive changes and points on 
which consensus is still a work in progress that it would not be the optimal 
way forward.

Thinking more about this, I guess that this is only important for the entries 
which are inserted in the forwarding plane. Hence, in case of conflict between 
protocols, I think that the preference algorithm should take into account the 
protocol preference (aka administrative distance).

[Les:] As admin distance is neither an attribute of SRMS entries nor guaranteed 
to be consistent on all routers for all prefixes this is not a desirable 
approach.

I'm also not sure to see why is the problem different compared to 
Multi-Topology. Could you please elaborate?
[Les:] I am unclear what your question is. Are you asking why we need different 
SIDs in different topologies? Please clarify.

Les


Thanks,
Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

Les,

Thanks for your reply.
Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution

Bruno -

Inline.

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

Hi,

As an individual contributor, please 

Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call

[stephane.litkowski]

+1

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, April 14, 2016 09:51
To: spring@ietf.org
Subject: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call

Dear WG,

As we discussed at our meeting last week, working group adoption has been 
requested for draft-ginsberg-spring-conflict-resolution.
Please reply to the list with your comments, including although not limited to 
whether or not you support adoption.

Thanks,

--John and Bruno



_

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

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

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

_

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

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

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

Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

[stephane.litkowski]

Hi Les,

BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid.

IMO, as I already pointed,  it would be easier to handle it a single document 
rather than in the protocol docs. Moreover we will have the sender part in many 
docs, and the receiver part in the spring-conflict-resolution draft.

Best Regards,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, January 13, 2016 17:50
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other 
drafts

(Changed the subject a bit)

Here is my proposal as regards the need to update other SR related drafts 
regarding handling invalid SRGBs.

1)No need for any change to SR architecture draft.

2) What is already in 
https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt
Section 3.1

"The originating router MUST NOT advertise overlapping ranges.

   When a router receives multiple overlapping ranges, it MUST conform
   to the procedures defined in
   [I-D.ginsberg-spring-conflict-resolution]."

We need to add equivalent language to:

https://www.ietf.org/id/draft-ietf-ospf-ospfv3-segment-routing-extensions-04.txt
Section 3.2

and

https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-06.txt
Section 3.2

This makes the conflict resolution draft the authoritative document and no 
additional changes to other SR documents will be needed in the future no matter 
what changes occur in the conflict resolution draft.

   Les




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 06, 2016 9:22 PM
To: bruno.decra...@orange.com; LITKOWSKI 
Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Bruno (AKA Mr. co-chair :)) -

Please do not worry. IETF process will be followed whatever the changes may be.

At the moment I have not decided whether to recommend changes to the 
architecture doc - or the protocol docs - or both. I will likely consult w the 
authors of those drafts first to see what seems to make sense. Then the 
proposed changes will - as always - be presented to the WG.

   Les


From: bruno.decra...@orange.com 
[mailto:bruno.decra...@orange.com]
Sent: Wednesday, January 06, 2016 10:05 AM
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Les,



[SLI] I'm was not suggesting to use only Adj-SID ... as I also do not see a 
real use case for that. I'm just saying that the specification does not prevent 
it. So may be let's prevent it ...so we can update the architecture document 
saying that advertising a valid SRGB is a must. There is something wrong to me 
here, because we will state that a node with invalid SRGB will be treated as 
non SR capable while the architecture does not forbid to not have a SRGB and 
does not say anything on how the architecture works with no SRGB (we can only 
guess that only Adj-SID can be used).


[Les2:] OK good - I think we agree on this point also. What is needed is to 
ensure that there is appropriate language in the SR architecture draft and/or 
the protocol drafts to specify how receiving an invalid SRGB affects the 
interpretation of "SR-MPLS capability".

As of today, the SR architecture has passed WG Last Call and his pending 
shepherd write up. Are you saying that there is a need to introduce technical 
change in the SR architecture?

[Les2:] I will take an action item to follow up on that with the various draft 
authors.

Before introducing such technical change in the document, draft authors would 
need to discuss them in the WG. Thanks.



-- Bruno


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 9:30 PM
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; 
spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Stephane -

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, January 05, 2016 12:45 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; 
spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Hi Les,

Pls find more inline.


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 00:34
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; 
spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Stephane -

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: 

Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

[stephane.litkowski]

[Les:] Just to be sure I understand you, you are advocating putting the SRGB 
sender behavior specification in draft-ginsberg-spring-conflict-resolution as 
well as the receiver behavior?
Sender behavior HAS to be specified in the protocol documents as it describes 
the normative behavior of the protocols.

[SLI] Well that's a point of view, but in this case the receiver side has also 
to be in the protocols. All depends of the responsibility : is it a protocol 
related responsibility or not or a more global architectural requirement that 
all the protocols will need defacto to fill.


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 14, 2016 10:21
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other 
drafts

Stephane -

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Thursday, January 14, 2016 12:27 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other 
drafts

Hi Les,

BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid.

[Les:] Perhaps. The BGP draft contains a reference to the OSPF draft as regards 
SRGB (see Section 4.3) - this might suffice -  but in principle I agree with 
you that we need to ensure that all protocols reference the common conflict 
resolution document. The authors of the BGP draft should indicate what language 
they believe is needed there.

IMO, as I already pointed,  it would be easier to handle it a single document 
rather than in the protocol docs. Moreover we will have the sender part in many 
docs, and the receiver part in the spring-conflict-resolution draft.



Inclusion of the sender behavior in draft-ginsberg-spring-conflict-resolution 
would then be redundant. I generally resist this because I think one of two 
things can happen:

1)The text is - either due to different wording or different context - subject 
to a different interpretation.
2)The text is entirely redundant

I am open to adding the (redundant) sender text - but I would prefer not to do 
so.

   Les


Best Regards,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, January 13, 2016 17:50
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other 
drafts

(Changed the subject a bit)

Here is my proposal as regards the need to update other SR related drafts 
regarding handling invalid SRGBs.

1)No need for any change to SR architecture draft.

2) What is already in 
https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt
Section 3.1

"The originating router MUST NOT advertise overlapping ranges.

   When a router receives multiple overlapping ranges, it MUST conform
   to the procedures defined in
   [I-D.ginsberg-spring-conflict-resolution]."

We need to add equivalent language to:

https://www.ietf.org/id/draft-ietf-ospf-ospfv3-segment-routing-extensions-04.txt
Section 3.2

and

https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-06.txt
Section 3.2

This makes the conflict resolution draft the authoritative document and no 
additional changes to other SR documents will be needed in the future no matter 
what changes occur in the conflict resolution draft.

   Les




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 06, 2016 9:22 PM
To: bruno.decra...@orange.com; LITKOWSKI 
Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Bruno (AKA Mr. co-chair :)) -

Please do not worry. IETF process will be followed whatever the changes may be.

At the moment I have not decided whether to recommend changes to the 
architecture doc - or the protocol docs - or both. I will likely consult w the 
authors of those drafts first to see what seems to make sense. Then the 
proposed changes will - as always - be presented to the WG.

   Les


From: bruno.decra...@orange.com 
[mailto:bruno.decra...@orange.com]
Sent: Wednesday, January 06, 2016 10:05 AM
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Les,



[SLI] I'm was not suggesting to use only Adj-SID ... as I also do not see a 
real use case for that. I'm just saying that the specification does not prevent 
it. So may be let's prevent it ...so we can update the architecture document 
saying that advertising a valid SRGB is a must. There is something wrong to me 
here, because we will state 

Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

[stephane.litkowski]

Hi Stefano,

My worry is that tomorrow we will have a new protocol, and this KEY piece may 
be forgotten because nothing tells that this is required... and this is a cross 
protocol behavior that we want.
I'm fine to have it in the protocol as far as we have a more global document 
telling that all the protocols MUST follow this rule and IMO the architecture 
document is a good place. Now taking into account, that the arch doc is almost 
closed (even not yet completely), I'm fine also to have this statement in the 
conflict-resolution draft. This is a really small addition and my preference is 
clearly to update the arch doc.

The receiver side for the SRGB part is per protocol as the consensus was in the 
thread that cross validation for SRGB is not necessary. We must not mix topic, 
here the topic is where do we put the sender and receiver behaviors for the 
SRGB validation. SID conflicts is another subject that we also need to discuss 
: but let's close this one first.

I would also say that both sender and receiver parts are key, and I would not 
give any priority to one over the other except if now vendors stop to produce 
buggy codes ;)


Best regards,

Stephane



-Original Message-
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
Sent: Thursday, January 14, 2016 17:08
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other 
drafts

Hi Stephane,

to me it’s perfectly fine to have the sender behavior described in the protocol 
because this is the critical part of the whole game. 

If all implementations behave properly at the sender side, you won’t have any 
problem at the receiver side.

Also, the protocol-specific draft is the reference document for any implementor 
so it’s important to find all the necessary information so that routing updates 
are formatted properly.

Now, the receiver-side can be more complex because the receiver behavior may 
involve more than just one protocol. We will come to this when we will discuss 
SID allocation conflicts among protocols. Therefore, the receiver behavior must 
be described into a protocol-agnostic document.

s.



> On Jan 14, 2016, at 11:45 AM, stephane.litkow...@orange.com wrote:
> 
> [Les:] Just to be sure I understand you, you are advocating putting the SRGB 
> sender behavior specification in draft-ginsberg-spring-conflict-resolution as 
> well as the receiver behavior?
> Sender behavior HAS to be specified in the protocol documents as it describes 
> the normative behavior of the protocols.
>  
> [SLI] Well that’s a point of view, but in this case the receiver side has 
> also to be in the protocols. All depends of the responsibility : is it a 
> protocol related responsibility or not or a more global architectural 
> requirement that all the protocols will need defacto to fill. 
>  
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Thursday, January 14, 2016 10:21
> To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: 
> Updating other drafts
>  
> Stephane -
>  
> From: stephane.litkow...@orange.com 
> [mailto:stephane.litkow...@orange.com]
> Sent: Thursday, January 14, 2016 12:27 AM
> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: 
> Updating other drafts
>  
> Hi Les,
>  
> BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid.
>  
> [Les:] Perhaps. The BGP draft contains a reference to the OSPF draft as 
> regards SRGB (see Section 4.3) - this might suffice -  but in principle I 
> agree with you that we need to ensure that all protocols reference the common 
> conflict resolution document. The authors of the BGP draft should indicate 
> what language they believe is needed there.
>  
> IMO, as I already pointed,  it would be easier to handle it a single document 
> rather than in the protocol docs. Moreover we will have the sender part in 
> many docs, and the receiver part in the spring-conflict-resolution draft.
>  
>  
>  
> Inclusion of the sender behavior in draft-ginsberg-spring-conflict-resolution 
> would then be redundant. I generally resist this because I think one of two 
> things can happen:
>  
> 1)The text is – either due to different wording or different context – 
> subject to a different interpretation.
> 2)The text is entirely redundant
>  
> I am open to adding the (redundant) sender text – but I would prefer not to 
> do so.
>  
>Les
>  
>  
> Best Regards,
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Wednesday, January 13, 2016 17:50
> To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
> Cc: spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: 
> Updating other drafts
>  
> (Changed the 

Re: [spring] draft-ginsberg-spring-conflict-resolution

[stephane.litkowski]

Fully agree but this is not the choice that has been made at the beginning. Do 
you want to propose a change ?


From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, January 08, 2016 15:26
To: LITKOWSKI Stephane SCE/OINIS
Cc: Stewart Bryant; Les Ginsberg (ginsberg); spring@ietf.org; DECRAENE Bruno 
IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Stephane,

IP addresses are not used in path computation. Those are just leaves. You can 
easily compute topology by just using nodes and links without IP addresses. 
SIDs should have semantics similar to IP address but presence of one should not 
mandate or be in any way tight to the other.

Cheers,
R.


On Fri, Jan 8, 2016 at 3:09 PM, 
> wrote:
Why not ... but in this case why also having Node-SID bound to a prefix ? Today 
Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a 
prefix.
I agree that there is no real need to bind them to a prefix as long as we can 
still compute the path towards the SID (now we inherit IP path).

-Original Message-
From: Stewart Bryant 
[mailto:stewart.bry...@gmail.com]
Sent: Friday, January 08, 2016 14:52
To: LITKOWSKI Stephane SCE/OINIS
Cc: Robert Raszuk; Les Ginsberg (ginsberg); 
spring@ietf.org; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution



> On 8 Jan 2016, at 09:39, 
> > 
> > wrote:
>
> [SLI] Anycast SID is not a conflict because the IP prefix is the same.

Taking a long term view why conflate anycast SID with an IP address? SIDs are 
instructions not addresses, and we may wish to use them to instruct well known 
operation in the network.

Stewart
_

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

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


_

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

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

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

Re: [spring] draft-ginsberg-spring-conflict-resolution

[stephane.litkowski]

Hi Les,

Yes we come back to the Yang discussion :)
I think the text you pointed is no more valid, as the consensus was to 
authorize per protocol configuration as a feature. I think we missed to update 
this definition part when we updated the model.

Here is the augmentation for ISIS :

augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
/isis:isis:
   +--rw segment-routing
   |  +--rw enabled?boolean
   |  +--rw bindings
   | +--rw advertise
   | |  +--rw policies*   string
   | +--rw receive? boolean
   +--rw protocol-srgb {sr:protocol-srgb}?
  +--rw srgb* [lower-bound upper-bound]
 +--rw lower-bounduint32
 +--rw upper-bounduint32


Now, we may have some implementations using a common SRGB for all protocols, 
and some implementations that allows for per protocol SRGB. I would not go into 
the discussion on which one is an expection and which one is the most used 
(there are too few SR deployments today to say something about this and 
moreover they are tied to implementation limitations).

Anyway, as the choice of using one or the other option is a provider decision 
(design choice), I agree that it would be hard to guess from an implementation 
point of view what was the design choice and what consistency rule to apply (at 
least from a receiver point of view).

Best Regards,

Stephane


-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Thursday, January 07, 2016 18:14
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ginsberg-spring-conflict-resolution

Stephane -

I know that you are well versed in this issue from the discussion we had some 
time back on the SR YANG model. :-)

At that time we agreed that SRGB logically belongs at global scope - though 
there are some use cases where we may want per protocol SRGBs.

https://www.ietf.org/id/draft-ietf-spring-sr-yang-01.txt currently says 
(Section 3):

"SRGB (Segment Routing Global Block): Defines a list of label
  blocks represented by a pair of lower-bound/upper-bound labels.
  The SRGB is also agnostic to the control plane used.  So all
  routing-protocol instance will have to advertise the same SRGB."

This covers the vast majority of use cases (and lets please not use this thread 
to discuss the exception cases :-) ).

However, because we know there are use cases where the above may not be true, I 
would like not to prevent (or make more difficult) solutions to the cases where 
we need per protocol SRGBs. I think we get a significant benefit from doing per 
protocol validation - the implementation of that is much simpler than doing 
cross protocol validation - and we do not prevent the exception cases where we 
need per protocol SRGB from being supported in the future.

Does this seem fair to you?

   Les


> -Original Message-
> From: stephane.litkow...@orange.com
> [mailto:stephane.litkow...@orange.com]
> Sent: Thursday, January 07, 2016 8:13 AM
> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org
> Subject: RE: draft-ginsberg-spring-conflict-resolution
> 
> Hi,
> 
> [Les:] I am not proposing that we do cross-protocol validation of 
> SRGBs. This would indeed increase the complexity and I am not 
> convinced we would gain much.
> SID conflict detection is a different matter - there we do indeed want 
> to include all protocols.
> 
> [SLI] IMO, complexity of SRGB cross protocol validation  depends on 
> how the implementation is done. The SRGB may or may not really be 
> owned by the protocol directly. Protocol just do the advertisement, 
> but SRGB may be owned by SR that may do suballocation for a particular 
> protocol. That really depends on how it has been coded. I'm not sure 
> that in Cisco implementation that ISIS requests label range directly 
> from the label manager ? If "SR process" owns all the labels and just 
> receive requests from protocols to reserve a particular SRGB, it has 
> the global view and can manage overlap easily. For example, if user 
> tries to configure a BGP SRGB that overlaps with ISIS SRGB, it can be easily 
> refused by the SR process.
> 
> So we go back to the question of the requirements ... I think it would 
> be really helpful that the WG agree on the requirement before talking 
> about solutions.
> 
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Thursday, January 07, 2016 00:03
> To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
> Cc: spring@ietf.org
> Subject: RE: draft-ginsberg-spring-conflict-resolution
> 
> Bruno -
> 
> I think there are two questions for me below - look for my answers inline.
> Let me know if I missed anything.
> 
> > -Original Message-
> > From: bruno.decra...@orange.com
> [mailto:bruno.decra...@orange.com]
> > Sent: Wednesday, January 06, 2016 10:04 AM
> > To: LITKOWSKI Stephane SCE/OINIS
> > Cc: 

Re: [spring] draft-ginsberg-spring-conflict-resolution

[stephane.litkowski]

Hi Robert,

Regarding SRGB management, it’s really a design choice. There was already some 
discussion in the past.
If people/implementations uses a global SRGB which is agnostic to protocols, 
cross protocol validation does not really make sense.
If people/implementations uses per protocol SRGB, cross protocol validation 
makes sense.
I do not see a real use case for the partial overlapping between protocols.

I agree with you that using a common SRGB for all protocols works well and only 
SID conflict management in necessary in this case.

Brgds,

Stephane


From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, January 07, 2016 17:19
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Hi Stephane,

> For example, if user tries to configure a BGP SRGB that
> overlaps with ISIS SRGB

Can you elaborate why that would be a bad thing to have two protocols advertise 
even not partially overlapping but identical SRGB from a given node ?

Also while we are at the node doing the check during configuration let's do not 
forget that not all configurations these days are real time and inline. To add 
concepts of forward referencing are also used which may allow on purpose to 
configure overlapping blocks before even given IGP (or protocol in general) is 
activated on any interface.

Best,
r.













On Thu, Jan 7, 2016 at 5:12 PM, 
> wrote:
Hi,

[Les:] I am not proposing that we do cross-protocol validation of SRGBs. This 
would indeed increase the complexity and I am not convinced we would gain much.
SID conflict detection is a different matter - there we do indeed want to 
include all protocols.

[SLI] IMO, complexity of SRGB cross protocol validation  depends on how the 
implementation is done. The SRGB may or may not really be owned by the protocol 
directly. Protocol just do the advertisement, but SRGB may be owned by SR that 
may do suballocation for a particular protocol. That really depends on how it 
has been coded. I'm not sure that in Cisco implementation that ISIS requests 
label range directly from the label manager ? If "SR process" owns all the 
labels and just receive requests from protocols to reserve a particular SRGB, 
it has the global view and can manage overlap easily. For example, if user 
tries to configure a BGP SRGB that overlaps with ISIS SRGB, it can be easily 
refused by the SR process.

So we go back to the question of the requirements ... I think it would be 
really helpful that the WG agree on the requirement before talking about 
solutions.


-Original Message-
From: Les Ginsberg (ginsberg) 
[mailto:ginsb...@cisco.com]
Sent: Thursday, January 07, 2016 00:03
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: RE: draft-ginsberg-spring-conflict-resolution

Bruno -

I think there are two questions for me below - look for my answers inline.
Let me know if I missed anything.

> -Original Message-
> From: bruno.decra...@orange.com 
> [mailto:bruno.decra...@orange.com]
> Sent: Wednesday, January 06, 2016 10:04 AM
> To: LITKOWSKI Stephane SCE/OINIS
> Cc: spring@ietf.org; Les Ginsberg (ginsberg)
> Subject: RE: draft-ginsberg-spring-conflict-resolution
>
> Hi Stéphane,
>
> Many thanks for contributing on this subject and for your comments.
>
> Please see inline [Bruno]
> Les, there is a specific question for you at the penultimate comment.
>
> I'll send an updated text and diff in a few days, after considering
> comments from currently unread emails.
>
> Bruno
>
> > -Original Message-
> > From: LITKOWSKI Stephane SCE/OINIS
> > Sent: Monday, January 04, 2016 9:41 AM
> > To: DECRAENE Bruno IMT/OLN; spring@ietf.org; Les 
> > Ginsberg (ginsberg)
> > Subject: RE: draft-ginsberg-spring-conflict-resolution
> >
> > Hi Bruno,
> >
> > And best wishes all for this new year.
> >
> >
> > It seems that posting your txt back as attachment to the list does
> > not work so I will put my comments on the text directly in the email :
>
> [Bruno] sorry for the inconvenience. To avoid commenting twice, you
> could have copy / past the .txt attachment into the email body.
>
>
> > - In §2.2 : you keep the statement "The following ranges are used:"
> > empty, may be it would be better to change with something like :
> > "None of the ranges are used in this case"
>
> [Bruno] This is already spelled out lines above "In case of conflicts,
> all the ranges advertised are invalidated and dropped."
> But I see what you mean. On the other hand, the goal was to have a
> short summary to allow comparison between options.
> Currently I've changed to
> "The following ranges are used:

Re: [spring] draft-ginsberg-spring-conflict-resolution

[stephane.litkowski]

Why not ... but in this case why also having Node-SID bound to a prefix ? Today 
Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a 
prefix.
I agree that there is no real need to bind them to a prefix as long as we can 
still compute the path towards the SID (now we inherit IP path). 

-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
Sent: Friday, January 08, 2016 14:52
To: LITKOWSKI Stephane SCE/OINIS
Cc: Robert Raszuk; Les Ginsberg (ginsberg); spring@ietf.org; DECRAENE Bruno 
IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution



> On 8 Jan 2016, at 09:39,  
>  wrote:
> 
> [SLI] Anycast SID is not a conflict because the IP prefix is the same.

Taking a long term view why conflate anycast SID with an IP address? SIDs are 
instructions not addresses, and we may wish to use them to instruct well known 
operation in the network.

Stewart

_

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

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

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

Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

[stephane.litkowski]

Hi Les,

Happy new year.

I agree with your proposal.
The text must state that  there must be a local configuration mechanism that 
avoids sender to originate overlapping SRGB.
In this case, as you mention, if a router receives overlapping SRGB, this is a 
bad behavior and we cannot guess if the forwarding plane is correctly 
programmed or not on the originator, so it is better to avoid it.

Now regarding the sentence :" The originating router is considered to be 
incapable of supporting the SR-MPLS forwarding plane". Do we have something in 
the architecture document saying that advertising a SRGB is mandatory to use SR 
? Pure theorical example : what if someone wants only to use Adj-SIDs in SR 
network ? there is no need to advertise a SRGB. Stating that the node must be 
considered as non SR capable is strong, it will also prevent the usage of 
Adj-SID which will work well without SRGB. If we consider that having a SRGB is 
mandatory, we need to have this requirement in the architecture document.


Best regards,

Stephane


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, January 04, 2016 06:55
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY


One of the topics discussed in 
https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ is 
how to handle inconsistent SRGB advertisements from a given node.



The draft defines one possible solution -from Section 2:



" Each range is examined in the order it was advertised.  If it does

   not overlap with any advertised range which preceded it the

   advertised range is used.  If the range overlaps with any preceding

   range it MUST NOT be used and all ranges advertised after the first

   encountered overlapping range also MUST NOT be used."



This is one instance of a class of solutions which attempt to make use of part 
of the advertisements even when there is some inconsistency (overlap) in the 
set of SRGB ranges received. A more complete discussion of this class of 
solutions can be seen in 
https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many thanx to 
Bruno for writing this.



However, there is an alternative solution which was suggested (notably by Acee 
Lindem) after the draft was written. This alternative is to ignore the entire 
set of SRGB advertisements and treat the problematic router as if it were not 
SR MPLS capable. This alternative was discussed during the presentation in 
SPRING WG at IETF94 (see 
https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide 
#3).
  It is also discussed in Bruno's post 
(https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see Section 
2.2).



The basis of the alternative solution is that a correct implementation should 
never allow inconsistent SRGB ranges to be successfully configured (let alone 
advertised). So this is not a case of a misconfiguration - it is a case of a 
defective implementation. It  then seems appropriate to put the onus on the 
originating router to only send valid SRGB advertisements rather than forcing 
all the receivers to try to "correct" the invalid information in some 
consistent way. This has a number of advantages:



1.   It is by far the simplest to implement

2.   It isolates the router which is untrustworthy

3.   As the problem can only occur as a result of a defective 
implementation the behavior of the originating router is unpredictable - it is 
therefore safer not to use the information



It is worth noting that since the invalid advertisement is the result of some 
sort of defect in the originating router's implementation, it is not safe to 
assume that the source will actually be using the advertised SRGB in a manner 
consistent with the selective choice made by the receiving routers.



I therefore propose that the above quoted text from  
https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ be 
replaced with the following:



"The set of received ranges is examined . If there is overlap between any two 
of the advertised ranges the entire SRGB set is considered invalid and is 
ignored.

The originating router is considered to be incapable of supporting the SR-MPLS 
forwarding plane. Routers which receive an SRGB advertisement with overlapping 
ranges SHOULD report the occurrence."



Comments?



   Les



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant 

Re: [spring] SRGBs, indexes, and topologies within a domain

[stephane.litkowski]

Hi Les,

I completely agree that consensus is not achieved yet, no worry. The only 
consensus we have is on per IGP instance SRGB support.
But as the discussion moved to encoding issue, I just wanted to highlight that 
it may not be an issue.
Anyway, yes, we need to find a consensus.

Best Regards,

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Wednesday, August 26, 2015 19:08
To: LITKOWSKI Stephane SCE/IBNF; Peter Psenak (ppsenak); Pushpasis Sarkar; Uma 
Chunduri; Eric Rosen; SPRING WG
Subject: RE: [spring] SRGBs, indexes, and topologies within a domain

Stephane -

For IS-IS there is at least MT support for IPv6 and multicast.

But, I really think we are getting ahead of ourselves.

There is no consensus yet - there are simply advocates for two different 
positions.
Trying to talk about the mechanics of migration is premature. For now  it is 
sufficient for all parties to understand that existing code is not compatible w 
a per topology SRGB and changes will have to be made if that choice is made.

I would appreciate it if folks did not declare consensus until we have achieved 
it. :-)

   Les

 -Original Message-
 From: stephane.litkow...@orange.com
 [mailto:stephane.litkow...@orange.com]
 Sent: Wednesday, August 26, 2015 9:18 AM
 To: Peter Psenak (ppsenak); Pushpasis Sarkar; Les Ginsberg (ginsberg); 
 Uma Chunduri; Eric Rosen; SPRING WG
 Subject: RE: [spring] SRGBs, indexes, and topologies within a domain
 
 Hi,
 
 Just to know, is there some implementation today supporting MT for 
 SPRING ? The other point is : if yes, does someone use it in a live 
 network ? If no, there is no issue to change.
 I agree that a migration is not easy, but coming back to previous 
 sentence, honestly I think no one use MT SPRING today ... so no migration 
 expected.
 
 For algorithm, AFAIK, no one support multiple algorithm today, so we 
 can do what we want as far as it does not break algo#0 today.
 
 Stephane
 
 
 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Wednesday, August 26, 2015 17:40
 To: Pushpasis Sarkar; Les Ginsberg (ginsberg); LITKOWSKI Stephane 
 SCE/IBNF; Uma Chunduri; Eric Rosen; SPRING WG
 Subject: Re: [spring] SRGBs, indexes, and topologies within a domain
 
 Hi Pushpasis,
 
 On 8/26/15 16:44 , Pushpasis Sarkar wrote:
  Hi Les,
 
 
 
 
  On 8/26/15, 7:45 PM, Les Ginsberg (ginsberg) ginsb...@cisco.com
 wrote:
 
  Stephane -
 
  Implementations based on the drafts that currently exist advertise 
  a
 topology independent SRGB. A SID which is advertised in a specific MT 
 Prefix Reachability advertisement is interpreted as an index into the 
 topology independent SRGB. This is NOT compatible with an 
 implementation which is written assuming that a SID is an index into a 
 topology specific SRGB. So the introduction of topology specific SRGBs 
 would have to be supported network-wide before it could be deployed. 
 Sub-TLVs cannot resolve this incompatibility.
  [Pushpasis] What if we use the current SR-capability sub-TLVs only 
  for
 single topology deployments? And use a new MT-SR-Capability SubTLV for 
 MT deployments? Please note, I am not saying MT cannot be supported 
 with current SR-Cap SubTLV. It can be, but with the limitation (as I 
 like to see this
 cuurently) is that we MUST use separate SID-index for the same prefix 
 in separate topologies. If operator does not want to live with the 
 limitation then all the vendor implementations must implement the new 
 MT-SR-Cap SubTLV and make it happen. If the operator can live with the 
 implementation they continue with per-topology SID-index and single SRGB for 
 all topology.
 
 above would require vendors to implement both options. For operators 
 managing transitions between one option to the other would be difficult.
 Interoperability with the implementations that only support one option 
 would become problematic.
 
 Do we really want to create all this? Does the gain we would get with 
 per topo/algo SRGB justify all this, especially given that the gain is 
 not functional, but rather operational and fairly limited?
 
 thanks,
 Peter
 
 
  Thanks
  -Pushpasis
 
 
 __
 __
 _
 
 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
 exploites ou copies sans autorisation. Si vous avez recu ce message 
 par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
 que les pieces jointes. Les messages electroniques etant susceptibles 
 d'alteration, Orange decline toute responsabilite si ce message a ete altere, 
 deforme ou falsifie. Merci.
 
 This message and its attachments may contain confidential or 
 privileged information that may be protected by law; they should not 
 be distributed, used or copied without authorisation.
 If you have received 

Re: [spring] SRGBs, indexes, and topologies within a domain

[stephane.litkowski]

Hi,

Just to know, is there some implementation today supporting MT for SPRING ? The 
other point is : if yes, does someone use it in a live network ? If no, there 
is no issue to change.
I agree that a migration is not easy, but coming back to previous sentence, 
honestly I think no one use MT SPRING today ... so no migration expected.

For algorithm, AFAIK, no one support multiple algorithm today, so we can do 
what we want as far as it does not break algo#0 today.

Stephane


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, August 26, 2015 17:40
To: Pushpasis Sarkar; Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/IBNF; Uma 
Chunduri; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Pushpasis,

On 8/26/15 16:44 , Pushpasis Sarkar wrote:
 Hi Les,




 On 8/26/15, 7:45 PM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

 Stephane -

 Implementations based on the drafts that currently exist advertise a 
 topology independent SRGB. A SID which is advertised in a specific MT Prefix 
 Reachability advertisement is interpreted as an index into the topology 
 independent SRGB. This is NOT compatible with an implementation which is 
 written assuming that a SID is an index into a topology specific SRGB. So 
 the introduction of topology specific SRGBs would have to be supported 
 network-wide before it could be deployed. Sub-TLVs cannot resolve this 
 incompatibility.
 [Pushpasis] What if we use the current SR-capability sub-TLVs only for single 
 topology deployments? And use a new MT-SR-Capability SubTLV for MT 
 deployments? Please note, I am not saying MT cannot be supported with current 
 SR-Cap SubTLV. It can be, but with the limitation (as I like to see this 
 cuurently) is that we MUST use separate SID-index for the same prefix in 
 separate topologies. If operator does not want to live with the limitation 
 then all the vendor implementations must implement the new MT-SR-Cap SubTLV 
 and make it happen. If the operator can live with the implementation they 
 continue with per-topology SID-index and single SRGB for all topology.

above would require vendors to implement both options. For operators managing 
transitions between one option to the other would be difficult. 
Interoperability with the implementations that only support one option would 
become problematic.

Do we really want to create all this? Does the gain we would get with per 
topo/algo SRGB justify all this, especially given that the gain is not 
functional, but rather operational and fairly limited?

thanks,
Peter


 Thanks
 -Pushpasis


_

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

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

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

Re: [spring] SRGBs, indexes, and topologies within a domain

[stephane.litkowski]

Hi Peter,



There are some mix between SIDs and labels in your text.

Some comments inline



-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, August 26, 2015 10:43
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain



Hi Stephane,



On 8/26/15 09:46 , 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com wrote:

 Hi Peter,



 Yes I need to allocate a new SRGB, but my index space will be contiguous and 
 I will be able to use the index 51 in each scope.



configuration wise same can be achieved with the offsets - think of it as an 
internal SRGB local to the box. The only difference is what is advertised.





1. per topology SRGB



4 SRGBs:



100-149 topology 1

150-199 topology 2

200-249 topology 1

250-299 topology 2



prefix51, topology 1 - SID index 51 - SID 200 prefix51, topology 2 - SID index 
51 - SID 250

[SLI] I would more think about : prefix51, topology 1 - SID index 51 - label 
200 ; prefix51, topology 2 - SID index 51 - label 250



What is advertised:



4 SRGBs (as above), prefix51 SID index 51

[SLI] Agree



---



2. Per topology offset



SRGB 100-299



4 offsets (local to the box):



0-49 topology 1

50-99 topology 2

100-149 topology 1

150-199 topology 2



prefix51, topology 1 - SID index 51 - SID 200 prefix51, topology 2 - SID index 
51 - SID 250





[SLI] In this case that's no more an offset, it's more a range of indexes 
mapped to others.

It's different from Les's proposal  srgb offset topology 1 1000 which is just 
a simple ADD operation.

You are creating some indirection table (like for virtual memory management). 
It works, but adds some complexity to manage those indirections.

And so there will be two levels of indirection



Virtual index table for topology#1


Real index table


Label  range


[0-49]


[0-49]


[100-149]


[50-99]


[100-149]


[200-249]






Virtual index table for topology#2


Real index table


Label  range


[0-49]


[50-99]


[150-199]


[50-99]


[150-199]


[249-299]






Well, managing one level of indirection is already a boring thing from an 
operational point of view, adding such complex mapping would not ease it.

When you need to troubleshoot label values (some platforms still have 
programming issues unfortunately ...), it complexifies ...









What is advertised:



1 SRGB (as above), 2 prefix SIDs - 101, 151



thanks,

Peter









 -Original Message-

 From: Peter Psenak [mailto:ppse...@cisco.com]

 Sent: Wednesday, August 26, 2015 09:28

 To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar;

 SPRING WG

 Subject: Re: [spring] SRGBs, indexes, and topologies within a domain



 Hi Stephane,



 On 8/26/15 01:28 , 
 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com wrote:

 Hi Peter,



 As I already pointed to Les, using an offset creates some holes in index 
 space that we need to manage when extending a block.



 Let's say that we have SRGB [100-199] (to simplify) and you divide your 
 block in two so you will have topology #1 using [100-149] and topology #2 
 using [150-199] using an offset of 50.

 Now I need to add a 51th node in my network, I cannot use index 51 because 
 it will overlap with topology#2 :(, so I will need to skip indexes from 51 
 to 100, and restarts my numbering with index 101. This management of holes 
 is not automated.



 how is this different to the case where you have two per topology SRGBs of 
 100-149 and 150-199 and now you need 51st SID? It is exactly the same 
 problem. You need to allocate a new SRGB.



 thanks,

 Peter





 Best Regards,



 Stephane



 -Original Message-

 From: Peter Psenak [mailto:ppse...@cisco.com]

 Sent: Tuesday, August 25, 2015 13:18

 To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar;

 SPRING WG

 Subject: Re: [spring] SRGBs, indexes, and topologies within a domain



 Hi Stephane,



 On 8/25/15 12:58 , 
 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com wrote:

 Hi Peter,



 1. If a new topology is added by use of the MT features of an IGP,

 then a new set of prefix-SIDs must be provisioned.  This seems

 like a major provisioning task.  The alternative would be to have

 an SRGB per topology; then when you add a new topology, you only

 have one quantity to provision (or one per platform perhaps).  I

 hear some hand-waving about how easy it is to provision new

 prefix-SIDs for every new topology, but ...



 I will keep repeating myself that such provisioning can be made automatic, 
 so the above point is not really convincing to me.



 Could you explain how ? Based on past discussions, it does not seem to be 
 so easy.



 simply by associating an offset and size from SRGP on a per topology basis.



 Example:



 SRGB 1600-24000



 I would assume that when you start to assign your SIDs for the default 
 topology, 

Re: [spring] SRGBs, indexes, and topologies within a domain

[stephane.litkowski]

Hi Peter,

 1. If a new topology is added by use of the MT features of an IGP, 
 then a new set of prefix-SIDs must be provisioned.  This seems like a 
 major provisioning task.  The alternative would be to have an SRGB per 
 topology; then when you add a new topology, you only have one quantity 
 to provision (or one per platform perhaps).  I hear some hand-waving 
 about how easy it is to provision new prefix-SIDs for every new 
 topology, but ...

 I will keep repeating myself that such provisioning can be made automatic, so 
 the above point is not really convincing to me.

Could you explain how ? Based on past discussions, it does not seem to be so 
easy.


Best Regards,

Stephane



_

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

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

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

Re: [spring] New Version Notification for draft-ietf-spring-segment-routing-04.txt

[stephane.litkowski]

Hi Stefano,

The new text for anycast fits perfectly my previous comment.

Best Regards,

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stefano Previdi 
(sprevidi)
Sent: Friday, July 31, 2015 09:55
To: spring@ietf.org
Subject: [spring] Fwd: New Version Notification for 
draft-ietf-spring-segment-routing-04.txt

All,

in this version we added more clarifications on the anycast use-case.

Thanks.
s.


Begin forwarded message:

 From: internet-dra...@ietf.org
 Subject: New Version Notification for 
 draft-ietf-spring-segment-routing-04.txt
 Date: July 31, 2015 9:53:22 AM GMT+02:00
 To: Stefano Previdi sprev...@cisco.com, Rob Shakir r...@rob.sh, 
 Bruno Decraene bruno.decra...@orange.com, Stephane Litkowski 
 stephane.litkow...@orange.com, Clarence Filsfils 
 cfils...@cisco.com, Bruno Decraene bruno.decra...@orange.com, 
 Stefano Previdi sprev...@cisco.com, Clarence Filsfils 
 cfils...@cisco.com, r...@rob.sh r...@rob.sh, Stephane Litkowski 
 stephane.litkow...@orange.com
 
 
 A new version of I-D, draft-ietf-spring-segment-routing-04.txt
 has been successfully submitted by Stefano Previdi and posted to the 
 IETF repository.
 
 Name: draft-ietf-spring-segment-routing
 Revision: 04
 Title:Segment Routing Architecture
 Document date:2015-07-31
 Group:spring
 Pages:21
 URL:
 https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-04.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
 Htmlized:   
 https://tools.ietf.org/html/draft-ietf-spring-segment-routing-04
 Diff:   
 https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-04
 
 Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an ordered list of instructions, called
   segments.  A segment can represent any instruction, topological or
   service-based.  A segment can have a local semantic to an SR node or
   global within an SR domain.  SR allows to enforce a flow through any
   topological path and service chain while maintaining per-flow state
   only at the ingress node to the SR domain.
 
   Segment Routing can be directly applied to the MPLS architecture with
   no change on the forwarding plane.  A segment is encoded as an MPLS
   label.  An ordered list of segments is encoded as a stack of labels.
   The segment to process is on the top of the stack.  Upon completion
   of a segment, the related label is popped from the stack.
 
   Segment Routing can be applied to the IPv6 architecture, with a new
   type of routing extension header.  A segment is encoded as an IPv6
   address.  An ordered list of segments is encoded as an ordered list
   of IPv6 addresses in the routing extension header.  The segment to
   process is indicated by a pointer in the routing extension header.
   Upon completion of a segment, the pointer is incremented.
 
 
 
 
 
 Please note that it may take a couple of minutes from the time of 
 submission until the htmlized version and diff are available at 
 tools.ietf.org.
 
 The IETF Secretariat
 

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

_

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

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

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

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[stephane.litkowski]

Looks that consensus is for option#2, so let's move SRGB to protocol 
configuration.


From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi,

Architecturally I agree - label manager shouldn't care less how labels have 
been learnt
Operationally I'm strongly for #2, in case of ISIS possibly under AF.

Cheers,
Jeff

From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on 
behalf of Stephane Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com
Date: Wednesday, July 22, 2015 at 7:19 PM
To: spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

In the current version of the config Yang model for SR, the SRGB list is 
configured at SR top level, so it is agnostic to the routing protocol.
We had some comment in Dallas on difficulties that having common label range 
shared between protocols could lead to.
During discussion in our design team, some point was also raised on routing 
protocol migrations that may be safer using a per protocol SRGB (so 
configuration the SRGB at IGP level rather than globally).

We would like to hear from the WG about the preference and arguments for both 
approaches :
Approach 1) keep SRGB configuration at top level, and so routing protocols will 
share the same label space (today proposal)
Approach 2) move SRGB configuration to protocols, each routing protocol manages 
its own label space.

Thanks to provide your feedback in order to solve this issue and have a 
consensus.


[Orange logo]http://www.orange.com/

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
mobile: +33 6 37 86 97 52 
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

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

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

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

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[stephane.litkowski]

Hi all,

What if we keep the SRGB block config in segment-routing global module, and 
if we allow for YANG configuration of carving this block inside each protocol 
(maybe as a feature) ?

Stephane


From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
Sent: Friday, July 24, 2015 16:59
To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane 
SCE/IBNF; spring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Suggesting that the forwarding instruction (AKA label)  needs to be different 
depending on what protocol provided
the instruction is completely unnecessary - it simply wastes label space.

[Uma]: Les, No - I never suggested anything like that.
SRGB for a routing instance to be advertised should be part of the routing 
instance provisioning as far as the yang model is concerned.
Carving out the label space for SR is a local matter and agree, of course, this 
 can be done in so many ways through CLI, dynamically, statically etc...

--
Uma C.


_

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

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

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

Re: [spring] working group last call for draft-ietf-spring-segment-routing

[stephane.litkowski]

Hi Chairs,

I currently have some issue with the anycast section of the draft. Based on the 
discussion  we had during the WG session (through Pushpasis's presentation), it 
looks that the anycast section is not enough explained (what is the problem 
behind ...) and using a MUST for mandating common SRGB is too restrictive 
to me as it was decided by the WG to make the SR architecture working with 
different SRGB per node.
I'm completely in favor of using common SRGB between anycast nodes as short 
term solution if possible, but working on general solution is also necessary.

Some more explanations are necessary, and a recommendation rather than using a 
MUST would be better.

PS : also the anycast draft refers to N-bit unset which is an encoding 
reference and so does not really make sense in this draft, possible solutions :
- move the statement to ISIS and OSPF draft
- be more generic on explaining the constraint (no more reference to encoding)


Regards,

Stephane


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John G.Scudder
Sent: Wednesday, July 22, 2015 15:24
To: spring@ietf.org
Cc: isis...@ietf.org
Subject: [spring] working group last call for draft-ietf-spring-segment-routing

[re-send with correct address for isis-wg]

Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in 
replies per the reply-to):

As we discussed at the SPRING meeting yesterday, working group last call has 
been requested for draft-ietf-spring-segment-routing. Please reply to the list 
with your comments, including although not limited to whether or not you 
support advancing the document to RFC. Non-authors are especially encouraged to 
comment.

In consideration of the fact that a number of WG calls are going on 
concurrently, we will end the call on August 31, 2015. 

Authors, please indicate whether you are aware of any relevant IPR and if so, 
whether it has been disclosed. (Please do this even if you've done it before, 
thanks for your help.)

Thanks,

--Bruno and John

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

_

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

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

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

Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop

[stephane.litkowski]

Support, not aware of any IPR

-Original Message-
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of John G.Scudder
Sent: Wednesday, July 22, 2015 15:17
To: spring@ietf.org
Cc: m...@ietf.org
Subject: [mpls] working group adoption call for 
draft-filsfils-spring-segment-routing-ldp-interop

Dear WG,

As we discussed at our meeting yesterday, working group adoption has been 
requested for draft-filsfils-spring-segment-routing-ldp-interop. Please reply 
to the list with your comments, including although not limited to whether or 
not you support adoption. Non-authors are especially encouraged to comment.

In consideration of the fact that a number of WG calls are going on 
concurrently, we will end the call on August 31, 2015. 

Authors, please indicate whether you are aware of any relevant IPR and if so, 
whether it has been disclosed. Also, the length of the author list for this 
document greatly exceeds the maximum recommended. Assuming the document is 
adopted, the authors should be prepared to correct this when submitting as a WG 
document, ideally by reducing the list to simply the active editor(s) and 
making use of the contributors section for the full list.

Thanks,

--Bruno and John

P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to.
___
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_

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

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

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

[spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[stephane.litkowski]

Hi WG,

In the current version of the config Yang model for SR, the SRGB list is 
configured at SR top level, so it is agnostic to the routing protocol.
We had some comment in Dallas on difficulties that having common label range 
shared between protocols could lead to.
During discussion in our design team, some point was also raised on routing 
protocol migrations that may be safer using a per protocol SRGB (so 
configuration the SRGB at IGP level rather than globally).

We would like to hear from the WG about the preference and arguments for both 
approaches :
Approach 1) keep SRGB configuration at top level, and so routing protocols will 
share the same label space (today proposal)
Approach 2) move SRGB configuration to protocols, each routing protocol manages 
its own label space.

Thanks to provide your feedback in order to solve this issue and have a 
consensus.


[Orange logo]http://www.orange.com/

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
mobile: +33 6 37 86 97 52 
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com



_

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

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

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

Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt

[stephane.litkowski]

Hi Tarek,

I think per-prefix granularity is still possible.
Advertising a SRGB for a particular algorithm does not mean that all the 
prefixes advertised will be advertised for that particular algorithm.

I mean considering you have a network with node A ,B, C, D, each one 
advertising a loopback.
You want to run algo 0 between all routers, so each router advertises a SRGB 
for algo 0, and loopback address with SID is advertised with Algo 0 also.
Now you want to run algo 2 but only A and B requires communication between each 
other using algo 2. As C and D may be on the path from A to B, all routers 
requires supports of algo 2 and a new SRGB is provisioned on all routers 
corresponding to algo 2. But in term of SID advertisement, you may configure 
only A and B to advertise Algo2 for Loopback address (Algo is encoded in 
PrefixSID), so there would be only 2 new MPLS forwarding entries instead of 4.

Does it make sense ?

Stephane


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Tuesday, July 21, 2015 15:05
To: cbow...@juniper.net
Cc: spring@ietf.org
Subject: Re: [spring] New Version Notification for 
draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt

Hi Chris,

A possible limitation of advertizing per-alg SRGB is that a node will always 
assign/maintain as many SRGB-alg labels (on possibly all nodes) for a prefix 
without being able to control this on per-prefix if needed.
Are there are any considerations for this in your proposal?

Regards,
Tarek

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, June 24, 2015 6:03 PM
To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers; Pushpasis 
Sarkar; Hannes Gredler
Subject: New Version Notification for
draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt


A new version of I-D,
draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt
has been successfully submitted by Chris Bowers and posted to the IETF 
repository.

Name:   draft-bowers-spring-adv-per-algorithm-label-blocks
Revision:   01
Title:  Advertising Per-Algorithm Label Blocks
Document date:  2015-06-24
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-per-algorithm-
label-blocks-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-algorithm-labe
l-blocks/
Htmlized:   
https://tools.ietf.org/html/draft-bowers-spring-adv-per-algorithm-label-blo
cks-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-bowers-spring-adv-per-algorithm-lab
el-blocks-01

Abstract:
   Segment routing uses globally-known labels to accomplish destination-
   based forwarding along shortest paths computed using Dijkstra's
   algorithm with IGP metrics.  This draft discusses how to use segment
   routing to accomplish destination-based forwarding along paths
   computed using other algorithms and metrics.  In particular, the
   draft contrasts two different options for associating labels with
   different algorithms for computing forwarding next-hops.

   
   


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

_

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

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

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

Re: [spring] Conflicting MS entries

[stephane.litkowski]

Hi Uma, 

Pls find inline comments.


-Original Message-
From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
Sent: Tuesday, June 30, 2015 20:24
To: Aissaoui, Mustapha (Mustapha); DECRAENE Bruno IMT/OLN
Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis...@ietf.org list; 
Stefano Previdi (sprevidi)
Subject: RE: Conflicting MS entries

Installing multiple SIDs for the same prefix in the FWD is bit off topic though 
related to the point being discussed.

Have few questions here to answer the Conflicting MS Entries

1. Is it a valid configuration to  provision multiple global prefix SIDs for 
any prefix  ?
 It seems the consensus here is though one can do this there is no real use 
case.
[SLI] For local prefixes, I agree that there would be no use case for this (for 
now).
But two different nodes can advertise the same SID for different prefix, or 
advertise mapping entries for the same prefix (using different range semantics) 
with different SIDs and it s harder to detect.



2. Is it a valid configuration to host a prefix on two nodes with different 
global prefix SIDs?
 In the similar lines is it valid a configuration to host multiple MSes and 
advertise different global SID indices for the same prefix?
I failed to see any valid use case here too.
[SLI] Agree, but even if there is no use case, such configuration can be done 
by human error, so we need to have a consistent behavior.


3. Is it a valid configuration to host a connected or otherwise route on two 
nodes with same prefix SID?

To me answer for #1 and #2 is invalid.  
 #3 is valid and intention is to host a multi-homed prefix so that all nodes 
can  compute ECMP path or prefer lower cost path to one of the nodes.
[SLI] Agree, the inter-area case will also provide this kind of scenario.

I prefer staying out of defining any mechanism  which would be any ways  
indeterministic for invalid configurations. 

--
Uma C.


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha 
(Mustapha)
Sent: Wednesday, June 24, 2015 6:37 AM
To: bruno.decra...@orange.com
Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis...@ietf.org list; 
Stefano Previdi (sprevidi)
Subject: Re: [spring] Conflicting MS entries

Hi Bruno,
Indeed what you are describing would be similar to having tunnels to the same 
destination prefix resolved via two different protocols (LDP and SR). As you 
said, maybe I am just not seeing a use case for allowing this. I can however 
see that one can program two SIDs for the same prefix using two different SPF 
algorithms.

Regards,
Mustapha.

 -Original Message-
 From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
 bruno.decra...@orange.com
 Sent: Wednesday, June 24, 2015 3:38 AM
 To: Aissaoui, Mustapha (Mustapha)
 Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis...@ietf.org 
 list; Stefano Previdi (sprevidi)
 Subject: Re: [spring] Conflicting MS entries
 
 Hi Mustapha,
 
  From: Aissaoui, Mustapha (Mustapha)
  [mailto:mustapha.aissaoui@alcatel-
  lucent.com]
  Sent: Tuesday, June 23, 2015 10:34 PM
 
  Hi Bruno,
  I can see that one can program multiple SIDs if these are for routes 
  of the same prefix which are advertised in multiple ISIS instances 
  or in multiple topologies. But within a single instance and 
  topology, how do you reconcile the multiple MS entries with a single 
  active route to that
 destination prefix?
 
 I'm probably missing something, but I don't see a need to reconcile. I 
 see 2 LSPs and for each a (N:1) indirection between the (label, FEC
 element) and the IP FIB. A bit similar to multiple BGP routes using 
 the same IP prefix to resolve their BGP Next-Hop.
 
 e.g. MS advertises 2 SIDs for prefix1 -- (via SRGBs) 2 incoming  2 
 outgoings labels. LL1, LL2 for local/incoming labels. LN1, LN2 for 
 neighbor/outgoing label.
 IP FIB:
 Prefix1 -- eth1
 
 NHLFE:
 LFE1: eth1, swap LN1
 LFE2: eth1, swap LN2
 
 ILM:
 LL1 -- LFE1
 LL2 -- LFE2
 
 
 Looks also similar to the case where a node(LSR) is both SR  LDP and 
 for the same FEC element/IP prefix  gets 1 label from LDP and 1 from SR/MS.
 
 That being said, if we are all in favor of selecting a single MS 
 entry, the discussion is purely theoretical.
 
 /Bruno
 
  Mustapha.
 
   -Original Message-
   From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
   bruno.decra...@orange.com
   Sent: Tuesday, June 23, 2015 9:48 AM
   To: Aissaoui, Mustapha (Mustapha)
   Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis...@ietf.org 
   list; Stefano Previdi (sprevidi)
   Subject: Re: [spring] Conflicting MS entries
  
   Hi Mustapha,
  
   Thanks for the discussion. Please see inline.
  
From: Aissaoui, Mustapha (Mustapha) 
[mailto:mustapha.aissaoui@alcatel- lucent.com]  Sent: Friday, 
June 19, 2015 8:19 PM
   
Hi Stephane and Bruno,
I do not think programming multiple SIDs makes sense. While 
there are multiple MS prefix sub-TLVs, there is 

Re: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01

[stephane.litkowski]

Hi Bruno,

Support as author and I'm not aware of any IPR on this document


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, June 29, 2015 19:22
To: spring@ietf.org
Subject: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01

Hello working group,

This email starts a two-week poll on adopting draft-litkowski-spring-sr-yang-01 
as a working group item.
YANG Data Model for Segment Routing 
https://tools.ietf.org/html/draft-litkowski-spring-sr-yang-01

Please send comments to the list and state if you support adoption or not. In 
the latter case, please also state the reasons.

This poll runs until July 13 2015.


*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
this draft, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
*If you are listed as a document author or contributor* please respond to this 
email and indicate whether or not you are aware of any relevant IPR.
The draft will not be adopted until a response has been received from each 
author and contributor.
If you are not listed as an author or contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

Thank you
Bruno  John

_

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

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

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

_

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

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

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

Re: [spring] IETF-93 agenda topics

[stephane.litkowski]

Hi Bruno,

It would be good if we can have 10min to present the progress on SPRING Yang 
model. 

Thanks,

Stephane


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, June 22, 2015 20:41
To: spring@ietf.org
Subject: [spring] IETF-93 agenda topics

Folks,

The preliminary IETF agenda is available at: 
https://datatracker.ietf.org/meeting/93/agenda.html
As of today, SPRING will meet at IETF-93 on Tuesday, July 21, 2015, from 13:00 
to 15:00.  Please forward any SPRING agenda items you might have to John and 
me.  The deadline is Tuesday June 30 by 10:00 U.S. Eastern Time.  Priority will 
be given to those who get their requests in by the deadline, though if agenda 
space permits it we will consider requests gotten in before July 12.

We have a 2 hours slot. If requests exceed our slot, we'll give preference to 
work that directly advances the WG charter, especially charter items at risk of 
slipping, and to work that requires interactive discussion rather than status 
reports or presentations of results. Please keep in mind that the mailing list 
is always available for such reports and we encourage you to use it.

If you have previously presented on your topic at a SPRING meeting, please 
explain in your request what you hope to achieve with your presentation this 
time. If you have requested to present the same work at multiple WGs, please 
note this so that we can coordinate as needed.

You should plan to send your slides to John and me no later than 24 hours prior 
to the meeting, though again, earlier is better. If we don't have your slides 
by the deadline, you may lose your slot. Please number your slides for the 
benefit of remote attendees, and if you plan to use any fancy builds or 
transitions you must arrange this with us in advance -- otherwise you should 
assume your slides may be converted to PDF and presented from the PDF.

Finally, if you request an agenda slot, please do so by replying to this 
message, making sure to include both John and me in the To: or Cc: and don't 
change the subject line. Please include the name of the person who will be 
presenting and give an estimate for how much time you think you'll need 
(including Q/A).

Thanks,

-- Bruno  John


_

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

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

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

_

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

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

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

Re: [spring] Poll for adoption: draft-kumar-spring-sr-oam-requirement

[stephane.litkowski]

Support.

I'm not aware of any IPR on this document.


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Wednesday, June 10, 2015 17:06
To: spring@ietf.org
Subject: [spring] Poll for adoption: draft-kumar-spring-sr-oam-requirement

Hello working group,

This email starts a two-week poll on adopting 
draft-kumar-spring-sr-oam-requirement as a working group item.
OAM Requirements for Segment Routing Network
https://tools.ietf.org/html/draft-kumar-spring-sr-oam-requirement-03

Please send comments to the list and state if you support adoption or not (in 
the latter case, please also state the reasons).

This poll runs until 25/06/2015.


*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
this draft, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
*If you are listed as a document author or contributor* please respond to this 
email and indicate whether or not you are aware of any relevant IPR.
The draft will not be adopted until a response has been received from each 
author and contributor.
If you are not listed as an author or contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

Thank you
Bruno  John



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

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

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

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

Re: [spring] Conflicting MS entries

[stephane.litkowski]

Even if choosing any IP to MPLS entry does not break anything, I'm not sure 
this is a good idea from an operational point of view to let it undeterministic.


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, June 18, 2015 09:29
To: LITKOWSKI Stephane SCE/IBNF; Stefano Previdi (sprevidi)
Cc: spring@ietf.org; isis...@ietf.org list
Subject: Re: [spring] Conflicting MS entries

Hi Stéphane,

 From: stephane.litkow...@orange.com Sent: Thursday, June 18, 2015 
 9:23 AM
 
 Hi Bruno,
 
   1) I don't really the issue. From a forwarding standpoint, looks like
 we can simply program multiple SIDs in the FIB.
 
 [SLI] What about the IP to MPLS entry ?

[Bruno] If transit LSRs install all SIDs, an ingress may use any SID, no? Local 
decision. 

Bruno

 

_

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

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

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

_

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

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

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

Re: [spring] Conflicting MS entries

[stephane.litkowski]

Hi Bruno,

1) I don't really the issue. From a forwarding standpoint, looks like 
we can simply program multiple SIDs in the FIB.

[SLI] What about the IP to MPLS entry ?


_

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

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

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

[spring] Providing unprotected SPRING TE path

[stephane.litkowski]

I think it would be good to discuss this topic within SPRING WG.

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: isis...@ietf.org; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; o...@ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi,

After discussing a lot with Les offline, we almost found an agreement on the 
understanding of this use case and possible relationship with unprotected SIDs.
Use case :
Creation of a SR TE tunnel which is unprotected. Protection may be 
provided end to end using for example two disjoint paths.
Controller based or ingress based tunnel setup.

It seems clear now that using ONLY unprotected SIDs does not solve the issue as 
when a link fails, convergence will happen, and nodes that are near the failure 
may reroute a NodeSID Algo 0 used within the TE stack before Ingress or 
controller recomputes the new path fitting constraints. So there may be 
transient situations where the path does not fit constraints anymore. Based on 
this, introducing NON PROTECTED NodeSID does not help in solving this 
transient situation.

Now, as I explained, IMO, it's possible to introduce end to end OAM on top on 
the SRTE to bring the LSP down as soon as there s something wrong on the path. 
A Holddown timer can be used to keep LSP down until convergence happens at 
Ingress or Controller. But introducing such OAM and holddown and coupled with 
relations with IGP may also be complex and there is a chance that it does not 
solve the issue. In case of protected NodeSID used, OAM will not work, because 
switchover time will be too small. Using OAM , defacto requires path with no 
protection.
So unprotected SID+OAM may solve the use at the price of some complexity and 
possibly not solving 100% of the cases.

To conclude :
We need to solve this use case and we need to find another elegant, simple and 
scalable solution for this.

Possible existing solutions :
- Use Adj-SID only = does not sounds good as there will be an impact of stack 
depth = Path compression necessary
- Use binding TLV and create some new Node-SID corresponding to a set of 
Adj-SID = This introduces more states within the network (how many ?)
- Anything else ?

Best regards,

Stephane


-Original Message-
From: Rob Shakir [mailto:r...@rob.sh]
Sent: Thursday, January 08, 2015 10:52
To: LITKOWSKI Stephane SCE/IBNF
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak 
(ppsenak); draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler; 
o...@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] [OSPF] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Stephane,

If we think about the “MUST NOT be protected” case that you mention. Let’s 
assume that we have a service that is performance sensitive, such that we want 
to take a particular path through the network - and that we use Node-SIDs like 
you say.

If we assume that the requirement is for A-B-C-D-E path below. The node SID for 
E points via C-D-E and hence is used for stack compression like you say:

  A -- B -- C -- D -- E
|/
--- Q ---

In your envisaged behaviour, C does not protect the Node-SID for E. In the case 
of the C-D link failure, then the “preferred” behaviour is that C now drops 
traffic towards this destination. However, C does not remove the FIB entry for 
the Node-SID for E, it’s actually just now known via Q. At this point, A can 
forward with exactly the same stack, and the packet takes a new A-B-C-Q-E path, 
which is non-conformant with the performance requirement of the service.

In terms of what C does with its FIB, does it simply not use C-Q-E during the 
failure, but post-reconvergence use it anyway? If so, why not use C-Q-E during 
the failure - because the service is always going to non-conformant to the 
performance requirement?

With an Adj-SID, it makes sense, because essentially unless that adjacency is 
available, then there is no alternate path for the SID that will be taken - so 
traffic never hits a non-conformant path.

Practically, if I can’t tell a customer that the path taken will definitely be 
A-B-C-D-E, and it may rather go via C-Q-E at some point following convergence 
[until the head-end calculates that such a change had happened - either a link 
outage, or a metric change - and stops using the label stack], then there’s 
little problem of having the traffic go via C-Q-E during protection.

For the disjoint case, the consideration that one has to make is:
* are alternative SPF paths for a particular Node-SID actually still 
conformant with the disjointness requirement? How many simultaneous failures 
does one require to 

Re: [spring] IPR disclosure for draft-filsfils-spring-segment-routing-mpls

[stephane.litkowski]

I'm not aware of non disclosed IPR.

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Wednesday, November 12, 2014 19:40
To: Alvaro Retana (aretana)
Cc: spring@ietf.org; draft-filsfils-spring-segment-routing-m...@tools.ietf.org
Subject: Re: [spring] IPR disclosure for 
draft-filsfils-spring-segment-routing-mpls

I'm not aware of non disclosed IPR.

Thanks,
Regards,
Bruno

 -Original Message-
 From: Clarence Filsfils [mailto:cfils...@cisco.com]
 Sent: Wednesday, November 12, 2014 7:33 AM
 To: Ahmed Bashandy
 Cc: Alvaro Retana (aretana); spring@ietf.org; 
 draft-filsfils-spring-segment- routing-m...@tools.ietf.org
 Subject: Re: IPR disclosure for 
 draft-filsfils-spring-segment-routing-mpls
 
 
 I'm not aware of any IPR on this draft
 
 Cheers,
 Clarence
 
 On 12.11.14 18:09, Ahmed Bashandy wrote:
 
  I'm not aware of any IPR on this draft
 
  Thanks
 
  Ahmed
 
 

_

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

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

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

_

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

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

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

Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing

[stephane.litkowski]

I'm not aware of non disclosed IPR.


From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Wednesday, September 24, 2014 15:03
To: draft-filsfils-spring-segment-rout...@tools.ietf.org
Cc: spring@ietf.org
Subject: IPR Claims related to draft-filsfils-spring-segment-routing

Hi!

In parallel to the WG Adoption Call for this draft, I want to formally ask the 
authors (no additional contributors are listed in the latest version of the 
draft) to please respond to this message indicating whether or not you are 
aware of any relevant IPR beyond what has been already disclosed.  The draft 
will not progress (pending the results of the WG Adoption Call) until we have 
received a response from each author.

http://datatracker.ietf.org/ipr/search/?option=document_searchid=draft-filsfils-spring-segment-routing

Thanks!

Alvaro.

_

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

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

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

Re: [spring] SPRING MPLS and Entropy Label

[stephane.litkowski]

IMHO,
 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
Yes it is ... SPRING brings more flexibility in ECMP for TE tunnels than 
RSVP-TE does. And ECMP with Bundle-Adj-SID is something really useful when a 
Service Provider is using parallel ECMP links rather than LAGs.

2) is EL the way to achieve ECMP with MPLS SPRING?
I would also agree that having two mechanism would be bad from an operational 
point of view.
Entropy label is not new at IETF, but new in deployment (feature availability 
is something really recent). If SP that have deployed Entropy for loadbalancing 
flows needs to move to something else for their SR-TE tunnels, well ... sounds 
a bad thing ...
Moreover entropy label has the magic of keeping loadbalancing stateless which 
is a pretty good advantage compared to adding more states at Ingress just for 
loadbalancing.


Stephane


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, July 23, 2014 17:56
To: Kireeti Kompella
Cc: m...@ietf.org; spring@ietf.org; 
draft-kini-mpls-spring-entropy-la...@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label

Hi Kireeti,

(Responding on-list for completeness - and a reminder to myself.)

On 23 Jul 2014, at 12:54, Kireeti Kompella kire...@juniper.net wrote:

 - I feel that it would be useful to provide some clarification as to 
 where we expect entropy to be required for load-sharing in the draft.
 
 There are three questions hiding here:
 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
 Valid question, as ECMP wasn't seen at first as necessary with RSVP-TE, which 
 shares intent with Adj-SID. I'd say the answer is Yes.  You give an example 
 of why; analogies from the multi path RSVP draft can also be used. 
 
 2) is EL the way to achieve ECMP with MPLS SPRING?
 I sincerely hope so; having two mechanisms in MPLS to enable ECMP wouldn't be 
 ideal. But I won't rule out other ways. 
 
 [Your point is taken: laying out (1) and (2) more clearly would help 
 the draft.]

rjs I agree with both points. Let me work to contribute some material to 
expand on the couple of points I raised following the meeting this week.

 
 3) Given Yeses to (1) and (2), how?
 That's the current focus of the draft. This part is for now an exploration. I 
 agree that at some point, we have to narrow the options down to a few 
 (ideally one). This would be an action for vendors, knowing their chips, and 
 providers, knowing their requirements to sit together and work it out. 
 
 There is an aspect of the draft that hasn't come out, which is along the 
 lines of the MPLS forwarding draft, soon to be an RFC: what is the best way 
 in the future, given the requirements of SPRING and EL? I.e., if you built 
 new chips today, knowing what we know, which option would you choose?  
 Getting a sense of that would help the community to come to a common choice 
 for the future -- as someone mentioned, today's choices/compromises may end 
 up varying widely vendor-to-vendor. 

rjs Agreed - if we can determine whether we think that the list of options is 
complete following the exercise of solving (1) and (2), then perhaps we can 
start to address these questions and try to conclude the discussions at the 
next meeting.

Cheers,
r.

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

_

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

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

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

Re: [spring] SPRING MPLS and Entropy Label

[stephane.litkowski]

 We already know how to encode label offset.
Are you referring to Segment Index as offset  of label base ?

 Using the same encoding you can treat offset value as number of significant 
 bits within the 20 bit label.
Could you give an example  of lookup and forwarding structure for your label 
range/label prefix ? I see something possible but I still have an issue with 
the lookup structure.



From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 13:24
To: LITKOWSKI Stephane SCE/IBNF
Cc: Kireeti Kompella; spring@ietf.org; 
draft-kini-mpls-spring-entropy-la...@tools.ietf.org; m...@ietf.org
Subject: RE: [spring] SPRING MPLS and Entropy Label


Hi,

That is also solved problem ;)

We already know how to encode label offset. Using the same encoding you can 
treat offset value as number of significant bits within the 20 bit label.

We do not need to extend this to current label use cases. Hence there is no 
issue with backwards compatibility.

Very basic and simple ;)

Cheers,
R.
On Jul 24, 2014 7:05 PM, 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com wrote:
Robert,

From a practical point of view , how do  you represent such MPLS label range 
with a prefix ?
[70, 170]
[17, 69]

MPLS was not designed for “label aggregation” scheme …
Or we need to change of labels are allocated from the label space for all label 
consumers … to permit this aggregation.


From: rras...@gmail.commailto:rras...@gmail.com 
[mailto:rras...@gmail.commailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 12:54
To: LITKOWSKI Stephane SCE/IBNF
Cc: Kireeti Kompella; m...@ietf.orgmailto:m...@ietf.org; 
spring@ietf.orgmailto:spring@ietf.org; 
draft-kini-mpls-spring-entropy-la...@tools.ietf.orgmailto:draft-kini-mpls-spring-entropy-la...@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label

Stephane,

This has NOTHING TO DO with IPv6. I am not even sure based on what you draw 
such strange conclusion 

I am talking pure about MPLS data plane (even without any IP above) and how we 
can solve the load balancing problems.

At min I expect for any discussion to be valid to discuss and compare all 
options.

Note also that SPRING does not use LDP so I am much less interested in solving 
the LDP load balancing issues.

Rgs,
R.


On Thu, Jul 24, 2014 at 6:46 PM, 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com wrote:
Robert,

Talking MPLS, I don’t see a way to use MPLS label “prefix” … this is a 
discussion we already had together. I think you are trying to sell IPv6 SR that 
I will unfortunately not buy again ☺

From: spring [mailto:spring-boun...@ietf.orgmailto:spring-boun...@ietf.org] 
On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 08:48
To: Kireeti Kompella
Cc: m...@ietf.orgmailto:m...@ietf.org; 
spring@ietf.orgmailto:spring@ietf.org; 
draft-kini-mpls-spring-entropy-la...@tools.ietf.orgmailto:draft-kini-mpls-spring-entropy-la...@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label


Hi Kireeti,

I quite disagree about the more state argument.

If you treat mpls label as prefix with mask which is all this boils down to 
there is no more state either in data or control plane.

As to the point of not perfect load balancing it all depends on your hash 
function. If you always advertise at least as big block as you have max 
parallel links on any interface you should be fine.

Best ,
R.
On Jul 24, 2014 2:12 PM, Kireeti Kompella 
kire...@juniper.netmailto:kire...@juniper.net wrote:
Hi Robert,

On Jul 24, 2014, at 03:21 , Robert Raszuk 
rob...@raszuk.netmailto:rob...@raszuk.net wrote:

Therefor an alternative of using any form of entropy labels in data plane all 
together would be to allocate a SID blocks (say 64 or 128 wide) and allow 
SPRING header imposition to use such pools of SIDs per group of flows to 
effectively allow for efficient load balancing in the network.

We’re rehashing (pun unintended) the entropy label discussion.

Before we settled on entropy labels the way we did, we discussed advertising 
label blocks in LDP.  There are two problems:
a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more state 
in the forwarding plane (and to some extent, in the control plane).
b) if you use small blocks, you get uneven load balancing; if you use large 
blocks, you blow up the state more.

Kireeti


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie.