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

[<[e-mail]>]

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:[e-mail]]
Sent: Tuesday, March 14, 2017 1:33 PM
To: Shraddha Hegde
Cc: Stefano Previdi (sprevidi); [e-mail]; 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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, March 14, 2017 1:42 PM
To: Pushpasis Sarkar <[e-mail]<mailto:[e-mail]>>
Cc: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.


> On Mar 14, 2017, at 8:20 AM, Pushpasis Sarkar <[e-mail]<mailto:[e-mail]>> wrote:
>
> 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 <[e-mail]<mailto:[e-mail]>> wrote:
> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Monday, March 13, 2017 11:57 PM
> To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; Arkadiy Gulko <[e-mail]<mailto:[e-mail]>>
> 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<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:
>    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<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
>
> _______________________________________________
> spring mailing list
> [e-mail]<mailto:[e-mail]>
> 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=>
>
> _______________________________________________
> spring mailing list
> [e-mail]<mailto:[e-mail]>
> 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=>