Subject: [spring] Providing unprotected SPRING TE path

From: <[email-masked]>
Date: Mon, 12 Jan 2015 08:18:20 +0000

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

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Thursday, January 08, 2015 10:52
To: LITKOWSKI Stephane SCE/IBNF
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; [email-masked]
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 violate constraints. For example, in a dual-plane core network, then if the requirement is disjointness at the IP level, then we may need to lose connectivity entirely within the plane before it is preferable to “hop” to another plane. In this case, using an alternative SPF path for the Node-SID is actually not a problem for disjointness.
	* does the application prefer losing an entire path to having some risk of the services being shared fate until the re-optimisation? 

From the work that we’ve looked at thus far, I have not yet seen a case where I absolutely MUST NOT use an alternate shortest path for a Node-SID and hence don’t require protection at a practical level.

Stack depth is definitely going to be something that we need to consider - to me, where we have centralised controller - actions such as dynamically created forwarding-adjacency LSPs which allow “expansion” of one segment into a set of segments within the path are attractive as a solution where one needs to have explicit routing of traffic for TE purposes. 

Does this make sense, or do you see the use case that we’re addressing here differently?

Cheers,
r.

> On 7 Jan 2015, at 09:44, [email-masked] wrote:
> 
> Hi,
> 
> I'm coming into this long thread and I tried to read all the exchange 
> but I may be missed some lines :)
> 
> But here is my opinion on this subject.
> I think the point from Shradda is valuable in case of Traffic Engineering with Segment Routing, especially with a central controller.
> 
> Today in TE networks, we are selling some disjoints paths to customer that MUST NOT be protected (SDH like services). It would be good to reproduce the same thing with SR-TE.
> 
> Now, current encoding permits to advertise that a specific Adj-SID is protected or not (as already mentioned, this does not say that a protection really exists ..., in case of LFA protection , there may be no FRR path for this adj-SID despite of the protection flag set).
> We pretty know that it would not be possible in all case to use only Adj-SID for a TE tunnel (due to label stack depth), so we need to introduce stack compression using SPT segments and node-SID.
> So to reply on Rob's comment, on RSVP-TE tunnels with looses hops that does not request protection : yes for RSVP, it does not make sense to me, but for SR, due to stack compression, it will be needed.
> 
> If we look at a network, where TE is managed by a central controller, how the controller can ensure that the node-SID used is protected or not (as for Adj-SID, I mean protection requested, not protection installed). I see two ways :
> 	* Use two SIDs attached to the same prefix and add a flag to prevent automatically all nodes to compute a protection for one of the SID. The flag does not really force nodes to compute a protection. Each node will still require local configuration for protection, but the flag will permit to exclude some prefixes for protection (overriding local policy).
> 
> 	* Use two prefixes on each node , prefixes are marked with tags (admin-tags) : "protection tag" and "non protection tag". Each router is configured using LFA policies to not compute protection for prefixes having "non protection tag" AND add knowledge to the controller to use only "non protection tag" prefixes to compress non protected path.
> 
> 
> 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.

---

From: Rob Shakir <[email-masked]>
Date: Tue, 13 Jan 2015 13:33:26 +0000

Hi Stephane,

Thanks for kicking off this discussion — it’s one that we have had a few conversations around.

> On 12 Jan 2015, at 08:18, [email-masked] wrote:
> 
> [… snip …]
> 

I agree here - either the switchover time is very small, and hence we cannot detect anything with connectivity verification OAM, and doing anything that measures the performance does not guarantee that we have strict affinity to the original path (the post-convergence and protection paths may be within the same performance constraints). So, no-protection and OAM is not a good way to ensure that we have strict affinity.

> - Use Adj-SID only => does not sounds good as there will be an impact of stack depth => Path compression necessary

Stack compression is only really required today because we have hardware that has never needed the stack depths that we’re talking about currently. Going forward, if SPRING-TE/SR-TE/AdjSID stacks are popular as a solution, then I see no reason that we MUST always have path compression. It is simply that this isn’t a dimension that we’ve asked our hardware colleagues to optimise for currently IMHO. I’m interested if you’ve a different view?

> - 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 ?)

How many is a question that depends on the network, and the constraints that one places - since this tells you what the AdjSID stack size can be. In some cases, it can be worse than the network diameter, because the constraints may require it. To this end, we can do some analysis to see whether we can determine the number of Binding-TLVs that are going to be required, and then subsequently, figure out how such SID-expansion bindings are created (by PCE, manually by operator?)...

> - Anything else ?

Nothing else comes to mind from me at the moment. Would be interested to hear whether there are other views within the WG.

r.

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Rob Shakir <[email-masked]>
Date: Tue, 13 Jan 2015 14:11:26 +0000

Apologies, someone pointed out an error in my email — thanks!

> On 13 Jan 2015, at 13:33, Rob Shakir <[email-masked]> wrote:
> 
> Hi Stephane,
> 
> I agree here

Apologies, I disagree that SID+OAM is a reasonable solution here.

r.

> - either the switchover time is very small, and hence we cannot detect anything with connectivity verification OAM, and doing anything that measures the performance does not guarantee that we have strict affinity to the original path (the post-convergence and protection paths may be within the same performance constraints). So, no-protection and OAM is not a good way to ensure that we have strict affinity.
> 
>> 
>> To conclude :

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 13 Jan 2015 18:59:03 +0000

Hi Stephane, et. al,
very interesting topic. Please find my questions, notes in-lined and tagged GIM>>.

	Regards,
		Greg

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.
GIM>> So, this is e2e protection for unidirectional LSP or for e2e bi-directional associated LSP (in MPLS-TP terms)?

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. 
GIM>> Is local protection being assumed in this scenario? Local protection, e.g. RSVP FRR, always viewed as transient, temporary solution and not as one that satisfies all constraints. Lower priority services likely to be affected, squeezed out of BW until services recovered and new working paths established.
Based on this, introducing "NON PROTECTED" NodeSID does not help in solving this transient situation.
GIM>> If Local protection is available, then what is the interpretation of "NON PROTECTED" characterization?

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. 
GIM>> Assuming the monitored LSP is unidirectional and "bring down" must happen at ingress. As we demonstrated in draft-mirsky-mpls-bfd-directed, CC session must be bi-directional co-routed in order to avoid false positive and false negative if and when action by the ingress required. Or use AIS-like OAM.

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. 
GIM>> Multi-layer OAM does require coordination of defect detection timers. AIS can help to suppress unnecessary alarms if and when server layer defect already detected.

In case of protected NodeSID used, OAM will not work, because switchover time will be too small. 
GIM>> I think this generalization is too strong. For example, e2e CC monitoring can work with 3.3 msec interval and detect defect in 10 msec guaranteed. Add sub-50 msec for service switchover, e.g. Linear Protection. What doesn't work here?

Using OAM , defacto requires path with no protection.
GIM>> I think that terminology clarification would be helpful. What OAM you're referring to - pro-active CC like BFD with 3.3 msec interval or on-demand CC like LSP Ping?

To conclude :

Best regards,

Stephane

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

Stephane,

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

Cheers,
r.

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.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 Jan 2015 03:12:40 +0000

Hello Stephane, Rob, et al,

Thanks for initiating this very interesting discussion.

Please see in-line for one comment and one possible alternative.

> From: spring [mailto:[email-masked]] On Behalf Of Rob Shakir
> Sent: Tuesday, January 13, 2015 9:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [spring] Providing unprotected SPRING TE path
> 
> >> 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.
> >
> > I agree here
> 

[NOBO] I agree that end to end OAM (i.e., continuity check) will be difficult, as there will be a race condition between local protection(s) and the end to end OAM declaring the failure.

> 
> r.
> 
> > - either the switchover time is very small, and hence we cannot detect
> anything with connectivity verification OAM, and doing anything that
> measures the performance does not guarantee that we have strict affinity
> to the original path (the post-convergence and protection paths may be
> within the same performance constraints). So, no-protection and OAM is
> not a good way to ensure that we have strict affinity.
> >
> >>
> >> To conclude :
> >> - Use Adj-SID only => does not sounds good as there will be an impact
> >> of stack depth => Path compression necessary
> >
> > Stack compression is only really required today because we have
> hardware that has never needed the stack depths that we’re talking about
> currently. Going forward, if SPRING-TE/SR-TE/AdjSID stacks are popular as a
> solution, then I see no reason that we MUST always have path compression.
> It is simply that this isn’t a dimension that we’ve asked our hardware
> colleagues to optimise for currently IMHO. I’m interested if you’ve a
> different view?
> >
> >> - 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 ?)
> >
> > How many is a question that depends on the network, and the constraints
> that one places - since this tells you what the AdjSID stack size can be. In
> some cases, it can be worse than the network diameter, because the
> constraints may require it. To this end, we can do some analysis to see
> whether we can determine the number of Binding-TLVs that are going to be
> required, and then subsequently, figure out how such SID-expansion
> bindings are created (by PCE, manually by operator?)...
> >
> >> - Anything else ?
> >
> > Nothing else comes to mind from me at the moment. Would be interested
> to hear whether there are other views within the WG.

[NOBO] If I assume one condition, then there is another possibility.

The assumption is that if there is a parallel link between a pair of nodes, then the SRTE will be:
- using an Adj-SID on that hop, or
- using a Node-SID to traverse that hop but don't care which link is traversed

If above assumption is reasonable, then the requirements to OAM seem to be that:
(1) N-th hop of a Node-SID forwarding MUST traverses a certain node.
(2) An SRTE MAY have multiple instances of (1).

For example:

A----B----C----D
          |       |
          E----F

Node A has SRTE that consists of Node-SID D but need to ensure that A-B-C-D is traversed.

Node A can create an end to end OAM to monitor the reachability to D.

Additionally, Node A can create an S-BFD session to Node C with specific TTL. "your discriminator" of such S-BFD packet guarantees that Node  A only gets the response as long as the packet is terminating on Node C. When Node B triggers a local protection or [re]convergence causes the packet to traverse A-B-E-F-C-D, then Node A can deterministically detect this and can take a necessary action (e.g., fall back to the backup LSP or re-compute a new path).

Something like that is a possibility with S-BFD.

Thanks!

-Nobo

> >> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter
> >> Psenak (ppsenak);
> >> [email-masked];
> >> [email-masked]; Hannes
> >> Gredler; [email-masked]; [email-masked]
> >> 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.
> >>
> >> 	* are alternative SPF paths for a particular Node-SID actually still
> conformant with the disjointness requirement? How many simultaneous
> failures does one require to violate constraints. For example, in a dual-
> plane core network, then if the requirement is disjointness at the IP level,
> then we may need to lose connectivity entirely within the plane before it is
> preferable to “hop” to another plane. In this case, using an alternative SPF
> path for the Node-SID is actually not a problem for disjointness.
> >> 	* does the application prefer losing an entire path to having some
> risk of the services being shared fate until the re-optimisation?
> >>
> >> From the work that we’ve looked at thus far, I have not yet seen a case
> where I absolutely MUST NOT use an alternate shortest path for a Node-SID
> and hence don’t require protection at a practical level.
> >>
> >> Stack depth is definitely going to be something that we need to consider
> - to me, where we have centralised controller - actions such as dynamically
> created forwarding-adjacency LSPs which allow “expansion” of one segment
> into a set of segments within the path are attractive as a solution where one
> needs to have explicit routing of traffic for TE purposes.
> >>
> >>> I'm coming into this long thread and I tried to read all the
> >>> exchange but I may be missed some lines :)
> >>>
> >>> I think the point from Shradda is valuable in case of Traffic Engineering
> with Segment Routing, especially with a central controller.
> >>>
> >>> Today in TE networks, we are selling some disjoints paths to customer
> that MUST NOT be protected (SDH like services). It would be good to
> reproduce the same thing with SR-TE.
> >>>
> >>> Now, current encoding permits to advertise that a specific Adj-SID is
> protected or not (as already mentioned, this does not say that a protection
> really exists ..., in case of LFA protection , there may be no FRR path for this
> adj-SID despite of the protection flag set).
> >>> We pretty know that it would not be possible in all case to use only Adj-
> SID for a TE tunnel (due to label stack depth), so we need to introduce stack
> compression using SPT segments and node-SID.
> >>> So to reply on Rob's comment, on RSVP-TE tunnels with looses hops that
> does not request protection : yes for RSVP, it does not make sense to me,
> but for SR, due to stack compression, it will be needed.
> >>>
> >>> If we look at a network, where TE is managed by a central controller,
> how the controller can ensure that the node-SID used is protected or not (as
> for Adj-SID, I mean protection requested, not protection installed). I see
> two ways :
> >>> 	* Use two SIDs attached to the same prefix and add a flag to prevent
> automatically all nodes to compute a protection for one of the SID. The flag
> does not really force nodes to compute a protection. Each node will still
> require local configuration for protection, but the flag will permit to exclude
> some prefixes for protection (overriding local policy).
> >>>
> >>> 	* Use two prefixes on each node , prefixes are marked with tags
> (admin-tags) : "protection tag" and "non protection tag". Each router is
> configured using LFA policies to not compute protection for prefixes having
> "non protection tag" AND add knowledge to the controller to use only "non
> protection tag" prefixes to compress non protected path.
> >>>
> >>>
> >>> 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,
> >> 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.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 14 Jan 2015 04:50:00 +0000

Hi Nobo,

Do you mean, set the TTL of SBFD session from A to C as 2? (depending on
the hops). I am not sure if that will help. Assume (in your topology) the
metric between B and C is 10 and A want to avoid link BC. So the normal
path from A to D is A-B-E-F-D and using Node SID D is sufficient to take
the path that satisfy the constraint. In this case, I think relying on TTL
may not help as on B if link BE fails, it redirects over lesser TTL path.

-Nagendra

On 1/13/15, 10:12 PM, "Nobo Akiya (nobo)" <[email-masked]> wrote:

>> Apologies, someone pointed out an error in my email ‹ thanks!
>> 
>> > Thanks for kicking off this discussion ‹ it¹s one that we have had a
>>few
>> conversations around.
>> >
>> >> [Š snip Š]
>[NOBO] I agree that end to end OAM (i.e., continuity check) will be
>difficult, as there will be a race condition between local protection(s)
>and the end to end OAM declaring the failure.
>
>> 
>> r.
>> 
>> hardware that has never needed the stack depths that we¹re talking about
>> It is simply that this isn¹t a dimension that we¹ve asked our hardware
>> colleagues to optimise for currently IMHO. I¹m interested if you¹ve a
>> different view?
>> >
>Additionally, Node A can create an S-BFD session to Node C with specific
>TTL. "your discriminator" of such S-BFD packet guarantees that Node  A
>only gets the response as long as the packet is terminating on Node C.
>When Node B triggers a local protection or [re]convergence causes the
>packet to traverse A-B-E-F-C-D, then Node A can deterministically detect
>this and can take a necessary action (e.g., fall back to the backup LSP
>or re-compute a new path).
>
>> >> 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
>> the case of the C-D link failure, then the ³preferred² behaviour is
>>that C now
>> entry for the Node-SID for E, it¹s actually just now known via Q. At
>>this point,
>> >> Practically, if I can¹t tell a customer that the path taken will
>>definitely be
>> label stack], then there¹s little problem of having the traffic go via
>>C-Q-E
>> during protection.
>> >>
>> preferable to ³hop² to another plane. In this case, using an
>>alternative SPF
>> >> From the work that we¹ve looked at thus far, I have not yet seen a
>>case
>> and hence don¹t require protection at a practical level.
>> >>
>> created forwarding-adjacency LSPs which allow ³expansion² of one segment
>> >> Does this make sense, or do you see the use case that we¹re
>>addressing
>> here differently?
>> >>
>> >> Cheers,
>> >> r.
>> >>
>> >>
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou
>> falsifie. Merci.
>> >>
>> >> If you have received this email in error, please notify the sender
>>and
>> delete this message and its attachments.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 14 Jan 2015 05:58:07 +0000

Hi Nobo,
I have couple comments to the S-BFD session between A and C nodes:
•       I think it must use IP encapsulation, otherwise reflected by C packet would not reach node A;
•       because reflected S-BFD packet being routed by C, there's no guarantee that it traverses node B, not F-E on the way to A;
•       thus forward and reverse directions of S-BFD session may be not co-routed and thus produce some false, positive or negative, defects;
•       and one more, what if there's a node between B and C nodes, B', so that TTL between A and C is 3 for any path.

Does that sound probable?

        Regards,
                Greg

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, January 13, 2015 7:13 PM
To: Rob Shakir; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] Providing unprotected SPRING TE path

> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> > On 13 Jan 2015, at 13:33, Rob Shakir <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Stephane,
> >
> > Thanks for kicking off this discussion — it’s one that we have had a
> > few
> conversations around.
> >
> >> On 12 Jan 2015, at 08:18, [email-masked]<mailto:[email-masked]> wrote:
> >>
> >> [… snip …]
> >>
> 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
> 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.

> measures the performance does not guarantee that we have strict
> affinity to the original path (the post-convergence and protection
> paths may be within the same performance constraints). So,
> no-protection and OAM is not a good way to ensure that we have strict affinity.
> >
> >>
> >> To conclude :
> >> - Use Adj-SID only => does not sounds good as there will be an
> >> impact of stack depth => Path compression necessary
> >
> hardware that has never needed the stack depths that we’re talking
> about currently. Going forward, if SPRING-TE/SR-TE/AdjSID stacks are
> popular as a solution, then I see no reason that we MUST always have path compression.
> >> - 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 ?)
> >
> that one places - since this tells you what the AdjSID stack size can
> be. In some cases, it can be worse than the network diameter, because
> the constraints may require it. To this end, we can do some analysis
> to see whether we can determine the number of Binding-TLVs that are
> going to be required, and then subsequently, figure out how such
> SID-expansion bindings are created (by PCE, manually by operator?)...
> >
> >> - Anything else ?
> >

For example:

A----B----C----D
          |       |
          E----F

Thanks!

-Nobo

> >> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar;
> >> Peter Psenak (ppsenak);
> >> [email-masked]<mailto:[email-masked]>;
> >> [email-masked]<mailto:[email-masked]>; Hannes
> >> Gredler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> 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.
> >>
> 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.
> >>
> 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?
> >>
> adjacency is available, then there is no alternate path for the SID
> that will be taken - so traffic never hits a non-conformant path.
> >>
> 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.
> >>
> failures does one require to violate constraints. For example, in a
> dual- plane core network, then if the requirement is disjointness at
> the IP level, then we may need to lose connectivity entirely within
> the plane before it is preferable to “hop” to another plane. In this
> case, using an alternative SPF path for the Node-SID is actually not a problem for disjointness.
> where I absolutely MUST NOT use an alternate shortest path for a
> Node-SID and hence don’t require protection at a practical level.
> >>
> - to me, where we have centralised controller - actions such as
> dynamically created forwarding-adjacency LSPs which allow “expansion”
> of one segment into a set of segments within the path are attractive
> as a solution where one needs to have explicit routing of traffic for TE purposes.
> >>
> >> Does this make sense, or do you see the use case that we’re
> >> addressing
> here differently?
> >>
> >> Cheers,
> >> r.
> >>
> >>
> >>> On 7 Jan 2015, at 09:44, [email-masked]<mailto:[email-masked]> wrote:
> >>>
> >>> Hi,
> >>>
> protected or not (as already mentioned, this does not say that a
> protection really exists ..., in case of LFA protection , there may be
> no FRR path for this adj-SID despite of the protection flag set).
> SID for a TE tunnel (due to label stack depth), so we need to
> introduce stack compression using SPT segments and node-SID.
> does not request protection : yes for RSVP, it does not make sense to
> me, but for SR, due to stack compression, it will be needed.
> >>>
> how the controller can ensure that the node-SID used is protected or
> not (as for Adj-SID, I mean protection requested, not protection
> installed). I see two ways :
> automatically all nodes to compute a protection for one of the SID.
> The flag does not really force nodes to compute a protection. Each
> node will still require local configuration for protection, but the
> flag will permit to exclude some prefixes for protection (overriding local policy).
> >>>
> (admin-tags) : "protection tag" and "non protection tag". Each router
> is configured using LFA policies to not compute protection for
> prefixes having "non protection tag" AND add knowledge to the
> controller to use only "non protection tag" prefixes to compress non protected path.
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> Stephane
> >>>
> >>
> >>
> >> 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.
> >>
> >> As emails may be altered, Orange is not liable for messages that
> >> have
> been modified, changed or falsified.
> >> Thank you.
> >>
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Mach Chen <[email-masked]>
Date: Wed, 14 Jan 2015 06:08:21 +0000

Hi Nobo, et al, 

If my understanding is right, the requirement is to avoid traffic through protected path. IMHO, for SR-TE, the only way is to use Adj-SIDs to explicitly specify the path. 

Nobo's solution is just for detecting whether the FRR happens and then let the ingress to decide the next step. IMHO, this solution may not work in case there are multiple ECMP paths between B and C, with the specified TTL, the S-BFD packet can reach C along any alternative path. 

Best regards,
Mach

> Sent: Wednesday, January 14, 2015 11:13 AM
> [NOBO] I agree that end to end OAM (i.e., continuity check) will be difficult, as
> there will be a race condition between local protection(s) and the end to end
> OAM declaring the failure.
> 
> >
> > r.
> >
> Additionally, Node A can create an S-BFD session to Node C with specific TTL.
> "your discriminator" of such S-BFD packet guarantees that Node  A only gets the
> response as long as the packet is terminating on Node C. When Node B triggers a
> local protection or [re]convergence causes the packet to traverse A-B-E-F-C-D,
> then Node A can deterministically detect this and can take a necessary action
> (e.g., fall back to the backup LSP or re-compute a new path).
>

---

From: <[email-masked]>
Date: Wed, 14 Jan 2015 09:26:00 +0000

> Stack compression is only really required today because we have hardware that has never needed the stack depths that we’re talking about currently. Going forward, if SPRING-TE/SR-TE/AdjSID stacks a…

[SLI] I agree, that this limitation may be out in future (or not ... no real view today). Now we still need to take care about MTU, there are still links in some networks with small MTUs (and I suspect we should still keep them for years :( ).

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Tuesday, January 13, 2015 14:33
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: [spring] Providing unprotected SPRING TE path

Hi Stephane,

> of Adj-SID => This introduces more states within the network (how many 
> ?)

r.

> ______________________________________________________________________
> ___________________________________________________
> 
> 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.
> 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Wed, 14 Jan 2015 09:30:42 +0000

Hi Greg,

Inline comments

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Tuesday, January 13, 2015 19:59
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: RE: Providing unprotected SPRING TE path

Hi Stephane, et. al,

	Regards,
		Greg

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.
GIM>> So, this is e2e protection for unidirectional LSP or for e2e bi-directional associated LSP (in MPLS-TP terms)?
[SLI] I was considering unidirectional LSP.

[SLI] NON PROTECTED means that local protection must not be applied.

[SLI] Agree.

In case of protected NodeSID used, OAM will not work, because switchover time will be too small. 
GIM>> I think this generalization is too strong. For example, e2e CC monitoring can work with 3.3 msec interval and detect defect in 10 msec guaranteed. Add sub-50 msec for service switchover, e.g. Linear Protection. What doesn't work here?
[SLI] From a theorical point of view, I agree, but putting OAMs at so high rates may bring down LSP when it's not really necessary (very transient congestion due to burst of traffic for example ...). Personnaly I would not go to such timers.

Using OAM , defacto requires path with no protection.
GIM>> I think that terminology clarification would be helpful. What OAM you're referring to - pro-active CC like BFD with 3.3 msec interval or on-demand CC like LSP Ping?
[SLI] More thinking about BFD.

To conclude :

Best regards,

Stephane

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

Stephane,

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

Cheers,
r.

---

From: <[email-masked]>
Date: Wed, 14 Jan 2015 09:34:36 +0000

Hi,

I agree with your point Nagendra, TTL cannot be used (Bruno already proposed such TTL solution on ISIS/OSPF ML).

-----Original Message-----
From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]] 
Sent: Wednesday, January 14, 2015 05:50
To: Nobo Akiya (nobo); Rob Shakir; LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: [spring] Providing unprotected SPRING TE path

Hi Nobo,

Do you mean, set the TTL of SBFD session from A to C as 2? (depending on the hops). I am not sure if that will help. Assume (in your topology) the metric between B and C is 10 and A want to avoid link BC. So the normal path from A to D is A-B-E-F-D and using Node SID D is sufficient to take the path that satisfy the constraint. In this case, I think relying on TTL may not help as on B if link BE fails, it redirects over lesser TTL path.

-Nagendra

On 1/13/15, 10:12 PM, "Nobo Akiya (nobo)" <[email-masked]> wrote:

>> >> Now, as I explained, IMO, it's possible to introduce end to end 
>> >> OAM
>>on
>>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.
>difficult, as there will be a race condition between local 
>protection(s) and the end to end OAM declaring the failure.
>
>> 
>> r.
>> 
>> >> We need to solve this use case and we need to find another 
>> >> elegant,
>> simple and scalable solution for this.
>> >>
>> hardware that has never needed the stack depths that we¹re talking 
>> It is simply that this isn¹t a dimension that we¹ve asked our 
>>hardware  colleagues to optimise for currently IMHO. I¹m interested if 
>>you¹ve a  different view?
>> >
>Additionally, Node A can create an S-BFD session to Node C with 
>specific TTL. "your discriminator" of such S-BFD packet guarantees that 
>Node  A only gets the response as long as the packet is terminating on Node C.
>packet to traverse A-B-E-F-C-D, then Node A can deterministically 
>detect this and can take a necessary action (e.g., fall back to the 
>backup LSP or re-compute a new path).
>
>> Let¹s assume that we have a service that is performance sensitive, 
>>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.
>> >>
>>the  label stack], then there¹s little problem of having the traffic 
>>go via C-Q-E  during protection.
>> >>
>>dual-
>> plane core network, then if the requirement is disjointness at the IP 
>>level,  then we may need to lose connectivity entirely within the 
>>plane before it is  preferable to ³hop² to another plane. In this 
>>Node-SID  and hence don¹t require protection at a practical level.
>> >>
>>dynamically  created forwarding-adjacency LSPs which allow ³expansion² 
>> >>> Now, current encoding permits to advertise that a specific 
>> >>> Adj-SID
>>is
>>protection  really exists ..., in case of LFA protection , there may 
>>be no FRR path for this  adj-SID despite of the protection flag set).
>> >> detruire ainsi
>>que les
>> >> privileged information that may be protected by law; they should 
>> >> not
>>be

---

From: <[email-masked]>
Date: Wed, 14 Jan 2015 11:54:23 +0000

Note that the case you pointed regarding bidirectional LSP with SPRING is also interesting to investigate.

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Tuesday, January 13, 2015 19:59
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: RE: Providing unprotected SPRING TE path

Hi Stephane, et. al,

	Regards,
		Greg

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi,

To conclude :

Best regards,

Stephane

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

Stephane,

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

Cheers,
r.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 Jan 2015 13:42:05 +0000

Hi Nagendra,

Thanks for the comments.
Please see in-line.

> From: Nagendra Kumar Nainar (naikumar)
> Sent: Tuesday, January 13, 2015 11:50 PM
> To: Nobo Akiya (nobo); Rob Shakir; [email-masked]
> Cc: [email-masked]
> the hops). I am not sure if that will help.

Correct. TTL=2 and your_disc target is C. So the packet terminating on any nodes other than C will prevent reflector from generating the response.

> Assume (in your topology) the
> path from A to D is A-B-E-F-D and using Node SID D is sufficient to take the
> path that satisfy the constraint. In this case, I think relying on TTL may not
> help as on B if link BE fails, it redirects over lesser TTL path.

If the normal path is A-B-E-F-D, then A will setup the S-BFD to terminate on E (w/ TTL=2). When the link BE fails, the packet will terminate on C (instead of E) which will prevent A from getting further S-BFD reply (i.e., your_disc target is E). So this will allow A to know when it is taking undesirable (whether that is triggered by protection or otherwise).

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 Jan 2015 13:48:19 +0000

Hello Mach,

Thanks for the comments.
Please see in-line.

> From: Mach Chen [mailto:[email-masked]]
> Sent: Wednesday, January 14, 2015 1:08 AM
> Subject: RE: [spring] Providing unprotected SPRING TE path
> 
> Hi Nobo, et al,
> 
> If my understanding is right, the requirement is to avoid traffic through
> protected path. IMHO, for SR-TE, the only way is to use Adj-SIDs to explicitly
> specify the path.

I agree. As Stephane and Rob mentioned, if there is no concern on the stack depth, using all Adj-SID is a good solution.

> 
> Nobo's solution is just for detecting whether the FRR happens and then let
> the ingress to decide the next step. IMHO, this solution may not work in
> case there are multiple ECMP paths between B and C, with the specified TTL,
> the S-BFD packet can reach C along any alternative path.

That's correct, it deterministically allows the ingress of SRTE to find out when FRR/LFA is triggered. As I described in the "assumption" in my original email, over such hops one must:

[snip]
> > - using a Node-SID to traverse that hop but don't care which link is
[snip]

So if that assumption is not true, we can't use this.

Thanks!

-Nobo

> > > > Thanks for kicking off this discussion — it’s one that we have had
> > > > a few
> > > conversations around.
> > > >
> > > >> OAM on
> > > 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.
> > > popular as a solution, then I see no reason that we MUST always have
> > > path
> > compression.
> > > It is simply that this isn’t a dimension that we’ve asked our
> > > hardware colleagues to optimise for currently IMHO. I’m interested
> > > if you’ve a different view?
> > > >
> > > that one places - since this tells you what the AdjSID stack size
> > > can be. In some cases, it can be worse than the network diameter,
> > > because the constraints may require it. To this end, we can do some
> > > analysis to see whether we can determine the number of Binding-TLVs
> > > that are going to be required, and then subsequently, figure out how
> > > such SID-expansion bindings are created (by PCE, manually by
> operator?)...
> > > >
> > > >> - Anything else ?
> > > >
> > If above assumption is reasonable, then the requirements to OAM seem
> > to be
> > that:
> TTL.
> > "your discriminator" of such S-BFD packet guarantees that Node  A only
> > gets the response as long as the packet is terminating on Node C. When
> > Node B triggers a local protection or [re]convergence causes the
> > detect this and can take a necessary action (e.g., fall back to the backup
> LSP or re-compute a new path).
> >
> > > such that we want to take a particular path through the network -
> > > and that we use Node-SIDs like you say.
> > > >>
> > > not remove the FIB entry for the Node-SID for E, it’s actually just
> > > stack, and the packet takes a new A-B- C-Q-E path, which is
> > > non-conformant with the performance requirement of the service.
> > > >>
> > > 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?
> > > >>
> > > 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.
> > > >>
> > > case, using an alternative SPF path for the Node-SID is actually not
> > > a problem
> > for disjointness.
> > > as a solution where one needs to have explicit routing of traffic
> > > for TE
> > purposes.
> > > >>
> > > >>> Adj-SID is
> > > does not request protection : yes for RSVP, it does not make sense
> > > to me, but for SR, due to stack compression, it will be needed.
> > > >>>
> > > (admin-tags) : "protection tag" and "non protection tag". Each
> > > router is configured using LFA policies to not compute protection
> > > for prefixes having "non protection tag" AND add knowledge to the
> > > controller to use only "non protection tag" prefixes to compress non
> > > protected
> > path.
> > > >>>
> > > >>>
> > > >>> 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
> > > d'alteration, Orange decline toute responsabilite si ce message a
> > > ete altere, deforme ou falsifie. Merci.
> > > >>
> > > >> not be
> > > >> If you have received this email in error, please notify the
> > > >> sender and

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 Jan 2015 13:59:10 +0000

Hi Greg,

Thanks for the comments.
Please see in-line with [NOBO2].

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, January 14, 2015 12:58 AM
To: Nobo Akiya (nobo); Rob Shakir; [email-masked]
Cc: [email-masked]
Subject: RE: [spring] Providing unprotected SPRING TE path

Hi Nobo,
I have couple comments to the S-BFD session between A and C nodes:
·        I think it must use IP encapsulation, otherwise reflected by C packet would not reach node A;
·        because reflected S-BFD packet being routed by C, there's no guarantee that it traverses node B, not F-E on the way to A;
·        thus forward and reverse directions of S-BFD session may be not co-routed and thus produce some false, positive or negative, defects;
[NOBO] The forward direction should be in-band, but also have IP encapsulation after the label stack (i.e., not IP-less) so that the response from the target node can be targeted to the received source IP address. And yes what you described is a common problem of OAM over uni-directional path/tunnel. But if the IP path from a transit node of an SRTE tunnel is broken and SRTE is unaffected, then the result will the that the SRTE ingress still takes an action which will be a “safer than sorry” approach IMO.
·        and one more, what if there's a node between B and C nodes, B', so that TTL between A and C is 3 for any path.
[NOBO] In that case, the SRTE should use Adj-SID on those specific hops if you must traverse specific links. Otherwise use Node-SID, which implies “don’t care which link is traversed”.

Thanks!

-Nobo

        Regards,
                Greg

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, January 13, 2015 7:13 PM
To: Rob Shakir; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Providing unprotected SPRING TE path

For example:

A----B----C----D
          |       |
          E----F

Thanks!

-Nobo