Subject: [spring] FW: New Version Notification for draft-gulkohegde-routing-planes-using-sr-00.txt

From: Shraddha Hegde <[email-masked]>
Date: Tue, 14 Mar 2017 03:25:33 +0000

Hi All,

New draft submitted for "separating routing planes using segment routing".
Looking for inputs and comments.

PS: The draft erroneously got submitted as individual and not affiliated to any WG but the intention was to submit it to SPRING WG.
We will correct it once the submission window opens. Apologies for the inconvenience.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 13, 2017 11:57 PM
To: [email-masked] <[email-masked]>; Shraddha Hegde <[email-masked]>; Arkadiy Gulko <[email-masked]>
Subject: New Version Notification for draft-gulkohegde-routing-planes-using-sr-00.txt

A new version of I-D, draft-gulkohegde-routing-planes-using-sr-00.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF repository.

Name:		draft-gulkohegde-routing-planes-using-sr
Revision:	00
Title:		Separating Routing Planes using Segment Routing
Document date:	2017-03-13
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-gulkohegde-routing-planes-using-sr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-gulkohegde-routing-planes-using-sr/
Htmlized:       https://tools.ietf.org/html/draft-gulkohegde-routing-planes-using-sr-00

Abstract:
   Many network deployments arrange the network topologies in two or
   more planes.  The traffic generally uses one of the planes and fails
   over to the other plane when there are link or node failure.  Certain
   applications require the traffic to be strictly restricted to a
   particular plane and should not failover to the other plane.  This
   document proposes a solution for the strict planar routing using
   Segment Routing.

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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 14 Mar 2017 00:20:27 -0700

Hi Authors,

First I must admit that I have not read the entire draft in details...

But from the abstract it seems that for the problem that this draft is
trying to address, a similar problem is already addressed in the Segment
Routing Problem Statement and Use-Case document (RFC 7855, section 3.3.1.1.1.
Disjointness in Dual-Plane Networks). And the same has been solved using
any cast segments as specified in draft-ietf-spring-mpls-anycast-segment.

Request you to clarify why we need the solution proposed in this draft over
the one proposed in draft-ietf-mpls-anycast-segments..

Thanks and Best regards,
-Pushpasis

On Mon, Mar 13, 2017 at 8:25 PM, Shraddha Hegde <[email-masked]>
wrote:

> PS: The draft erroneously got submitted as individual and not affiliated
> to any WG but the intention was to submit it to SPRING WG.
> To: [email-masked] <[email-masked]>;
> Shraddha Hegde <[email-masked]>; Arkadiy Gulko <
> [email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 14 Mar 2017 08:12:18 +0000

Hi Pushpasis,

I agree. The problem/use-case is already described in RFC7855, the required protocol extensions are already documented in ospf, isis and bgp drafts, we already have multiple implementations, and deployments have been done.

s.

> On Mar 14, 2017, at 8:20 AM, Pushpasis Sarkar <[email-masked]> wrote:
> 
> Hi Authors,
> 
> But from the abstract it seems that for the problem that this draft is trying to address, a similar problem is already addressed in the Segment Routing Problem Statement and Use-Case document (RFC 7855, section 3.3.1.1.1. Disjointness in Dual-Plane Networks). And the same has been solved using any cast segments as specified in draft-ietf-spring-mpls-anycast-segment. 
> 
> Request you to clarify why we need the solution proposed in this draft over the one proposed in draft-ietf-mpls-anycast-segments.. 
> 
> Thanks and Best regards,
> -Pushpasis
> 
> 
> On Mon, Mar 13, 2017 at 8:25 PM, Shraddha Hegde <[email-masked]> wrote:
> Hi All,
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 14 Mar 2017 08:49:23 +0000

Hi Stephano/Pushpasis,

Anycast segments provide loose separation of routing planes. If there is a failure, traffic running over anycast segment is allowed
To failover to different plane. The requirement, this draft tries to address is the strict routing plane separation. Certain application traffic
Should be restricted to one plane even in case of failure and never cross over to the other plane.

I'll add a reference to anycast segments and details of how this is different from anycast SID in the next revision.

Rgds
Shraddha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 1:42 PM
To: Pushpasis Sarkar <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] New Version Notification for draft-gulkohegde-routing-planes-using-sr-00.txt

Hi Pushpasis,

s.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 14 Mar 2017 23:02:55 +0530

Hi Shraddha,

On Tue, Mar 14, 2017 at 2:19 PM, Shraddha Hegde <[email-masked]>
wrote:

> Hi Stephano/Pushpasis,
>
> Anycast segments provide loose separation of routing planes. If there is a
> failure, traffic running over anycast segment is allowed
> To failover to different plane. The requirement, this draft tries to
> address is the strict routing plane separation. Certain application traffic
[Pushpasis] Does this not seem to fit requirements of Policy-Based
Routing/Policy-Based-Backup-Selection?

>
> I'll add a reference to anycast segments and details of how this is
> different from anycast SID in the next revision.
>
[Pushpasis] It will be great if you can add a diagram to illustrate the
difference. Maybe I am missing something here :(

Thanks
-Pushpasis

> Subject: Re: [spring] New Version Notification for
> draft-gulkohegde-routing-planes-using-sr-00.txt
>
> Hi Pushpasis,
>
> I agree. The problem/use-case is already described in RFC7855, the
> required protocol extensions are already documented in ospf, isis and bgp
> drafts, we already have multiple implementations, and deployments have been
> done.
>
> s.
>
>
> Routing Problem Statement and Use-Case document (RFC 7855, section
> 3.3.1.1.1. Disjointness in Dual-Plane Networks). And the same has been
> solved using any cast segments as specified in draft-ietf-spring-mpls-
> anycast-segment.
> >
> > Request you to clarify why we need the solution proposed in this draft
> over the one proposed in draft-ietf-mpls-anycast-segments..
> >
> > Thanks and Best regards,
> > -Pushpasis
> >
> >
> > Status:         https://datatracker.ietf.org/
> doc/draft-gulkohegde-routing-planes-using-sr/

---

From: <[email-masked]>
Date: Tue, 14 Mar 2017 21:24:47 +0000

Hi Pushpasis,
Please review attached file that depicts high level difference as it applies to dual plane use case. Currently, there is no solution available to support optimized loosed path per plane with no fallback to alternative plane if the plane is partitioned.
Thanks
Arkadiy

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 1:33 PM
To: Shraddha Hegde
Cc: Stefano Previdi (sprevidi); [email-masked]; Gulko, Arkadiy (Financial&Risk)
Subject: Re: [spring] New Version Notification for draft-gulkohegde-routing-planes-using-sr-00.txt

Hi Shraddha,

On Tue, Mar 14, 2017 at 2:19 PM, Shraddha Hegde <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stephano/Pushpasis,

Anycast segments provide loose separation of routing planes. If there is a failure, traffic running over anycast segment is allowed
To failover to different plane. The requirement, this draft tries to address is the strict routing plane separation. Certain application traffic
Should be restricted to one plane even in case of failure and never cross over to the other plane.
[Pushpasis] Does this not seem to fit requirements of Policy-Based Routing/Policy-Based-Backup-Selection?

I'll add a reference to anycast segments and details of how this is different from anycast SID in the next revision.
[Pushpasis] It will be great if you can add a diagram to illustrate the difference. Maybe I am missing something here :(

Thanks
-Pushpasis

Rgds
Shraddha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 14, 2017 1:42 PM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Cc: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] New Version Notification for draft-gulkohegde-routing-planes-using-sr-00.txt

Hi Pushpasis,

s.

> On Mar 14, 2017, at 8:20 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Authors,
>
> On Mon, Mar 13, 2017 at 8:25 PM, Shraddha Hegde <[email-masked]<mailto:[email-masked]>> wrote:
> Hi All,
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Arkadiy Gulko <[email-masked]<mailto:[email-masked]>>
> URL:            https://www.ietf.org/internet-drafts/draft-gulkohegde-routing-planes-using-sr-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dgulkohegde-2Drouting-2Dplanes-2Dusing-2Dsr-2D00.txt&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=SfDbR-u1zr_bGaI3a4Z_qEQAOL3sPnevtBDsGfCG97U&e=>
> Status:         https://datatracker.ietf.org/doc/draft-gulkohegde-routing-planes-using-sr/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dgulkohegde-2Drouting-2Dplanes-2Dusing-2Dsr_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=_9kqi_RL2GoWxwwI_n3VvzoJmXv0hA9GFVx9ukTZEFE&e=>
> Htmlized:       https://tools.ietf.org/html/draft-gulkohegde-routing-planes-using-sr-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dgulkohegde-2Drouting-2Dplanes-2Dusing-2Dsr-2D00&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=n75iCPw3hyV297zf1sbYYtBMe_NixFirhgG2jGtCYjw&e=>
>
>
> Abstract:
> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=ZDvFVzoZZoETR5ITncbxO6DhgsV-9u9Z6sG3PceekRA&e=>.
>
> The IETF Secretariat
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=OMIkn_KWEqu2FZrDhknxuWKSn9TP5KRloCTL98iMh4g&e=>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=OMIkn_KWEqu2FZrDhknxuWKSn9TP5KRloCTL98iMh4g&e=>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 15 Mar 2017 12:40:32 +0530

Hi Arkadiy,

Thanks for the detailed explanation.

But I am still not convinced about a separate RP-SID. All I see that is
necessary is here is that PE1 realizes that PE2 has a different Anycast
Group-ID (200 in this case) and then it has to prune the path from SPF
results accordingly. Like mentioned before this seems to me a plain case of
Policy-based Routing/Backup-Selection. This can be achieved in any of the
following ways..

1. Using Separate anycast-SIDs.. one per plane..
2. Or using Node-admin tags to color each of these planes separately..

Both the above can be used in conjunction Policy-based
Routing/Backup-path-selection to achieve what  is being desired here...

Thanks
-Pushpasis

On Wed, Mar 15, 2017 at 2:54 AM, <[email-masked]> wrote:

> Hi Pushpasis,
>
> Please review attached file that depicts high level difference as it
> applies to dual plane use case. Currently, there is no solution available
> to support optimized loosed path per plane with *no fallback* to
> alternative plane if the plane is partitioned.
>
> Thanks
>
> Arkadiy
>
>
>
> *From:* Pushpasis Sarkar [mailto:[email-masked]]
> *Sent:* Tuesday, March 14, 2017 1:33 PM
> *To:* Shraddha Hegde
> *Cc:* Stefano Previdi (sprevidi); [email-masked]; Gulko, Arkadiy
> (Financial&Risk)
>
> *Subject:* Re: [spring] New Version Notification for
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dgulkohegde-2Drouting-2Dplanes-2Dusing-2Dsr-2D00.txt&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=SfDbR-u1zr_bGaI3a4Z_qEQAOL3sPnevtBDsGfCG97U&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dgulkohegde-2Drouting-2Dplanes-2Dusing-2Dsr_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=_9kqi_RL2GoWxwwI_n3VvzoJmXv0hA9GFVx9ukTZEFE&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dgulkohegde-2Drouting-2Dplanes-2Dusing-2Dsr-2D00&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=n75iCPw3hyV297zf1sbYYtBMe_NixFirhgG2jGtCYjw&e=>
> >
> >
> > Abstract:
> tools.ietf.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=ZDvFVzoZZoETR5ITncbxO6DhgsV-9u9Z6sG3PceekRA&e=>
> .
> >
> > The IETF Secretariat
> >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=OMIkn_KWEqu2FZrDhknxuWKSn9TP5KRloCTL98iMh4g&e=>
> >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=-Ov_b1p-pRQOnYT8vSOezy9aO_1j01TWgsPELKNTYsc&s=OMIkn_KWEqu2FZrDhknxuWKSn9TP5KRloCTL98iMh4g&e=>
>
>
>