Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

Thanks Ron!

I really like the innovative idea.

Will this work with LDP v4 v6 to SRv6 interworking as well is my guess?

Kind Regards

Gyan

On Fri, Feb 12, 2021 at 12:04 PM Ron Bonica <rbonica@juniper.net> wrote:

> Gyan,
>
>
>
> Control plane considerations are beyond the scope of this draft. That
> said, when I wrote the draft, I was thinking that the border nodes were
> ASBRs.
>
>
>
>
>              Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Friday, February 12, 2021 3:55 AM
> *To:* Jeff Tantsura <jefftant.ietf@gmail.com>
> *Cc:* Loa Andersson <loa@pi.nu>; Ron Bonica <rbonica@juniper.net>;
> spring@ietf.org
> *Subject:* Re: [spring] FW: New Version Notification for
> draft-bonica-spring-srv6-end-dtm-01.txt
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Ron
>
>
>
> This is an interesting  SR-MPLS to SRv6 interworking concept.
>
>
>
> For an end to end LSP where you end up doing a translation on a border
> node doing the interworking pop of MPLS label stack and impose of SRv6 IPv6
> header in one direction and POP of SRv6 IPv6 header and impose of MPLS
> label stack in the other direction, how does the LSP get stitched from
> ingress PE to egress PE FEC destination if the intermediate node in the
> path is a P node doing the translation interworking.  I think if the
> translation interworking node was an egress PE that is doing the ASBR
> function handoff seems plausible, but if it’s a P node as it appears in
> your example how would the LSP get stitched end to end.
>
>
>
> Could this same concept be used for MPLS LDP fo SRv6 interworking as well.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Tue, Feb 9, 2021 at 8:00 PM Jeff Tantsura <jefftant.ietf@gmail.com>
> wrote:
>
> Thanks Ron, couldn’t have explained it better.
>
> Prefix SID (and the prefix associated with it) could be reachable over any
> interface participating in the topology,  depending on that topology
> structure, with topology changes, outgoing interface might change as well.
> Hence the outgoing interface is a runtime property of the top SID.
>
> Loa - does this clarify?
>
>
>
> Cheers,
>
> Jeff
>
> On Feb 9, 2021, 12:35 PM -0800, Ron Bonica <rbonica@juniper.net>, wrote:
>
> Loa,
>
> I think that Jeff means to say that " A SID instance is associated with
> SR-MPLS label stack. A label stack entry can be associated with a next hop.
> A recursive lookup may be required to derive the next hop from the topmost
> label stack entry."
>
> Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Loa Andersson <loa@pi.nu>
> Sent: Monday, February 8, 2021 11:51 PM
> To: Jeff Tantsura <jefftant.ietf@gmail.com>; Ron Bonica <
> rbonica@juniper.net>
> Cc: spring@ietf.org
> Subject: Re: [spring] FW: New Version Notification for
> draft-bonica-spring-srv6-end-dtm-01.txt
>
> [External Email. Be cautious of content]
>
>
> Jeff,
>
>
> On 08/02/2021 14:51, Jeff Tantsura wrote:
>
> Hi Ron,
>
> Very useful document, thanks!
>
> Question wrt processing:
> As described in the draft:
> “A SID instance is associated with SR-MPLS label stack and outgoing
> interface.”
>
> I’d think that outgoing interface would be recursively resolved based on
> the top SID (and could change based on topological semantics).
> Could you please elaborate?
>
>
> What exactly do yo mean by "recursively"?
>
> /Loa
>
>
> Thanks!
>
>
> Cheers,
> Jeff
>
> On Feb 7, 2021, at 08:46, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> wrote:
>
> 
> Please review and comment
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Sunday, February 7, 2021 11:41 AM
> To: Greg Mirsky <gregimirsky@gmail.com>; Peng Shaofu
> <peng.shaofu@zte.com.cn>; Ron Bonica <rbonica@juniper.net>; Shaofu
> Peng <peng.shaofu@zte.com.cn>; Shraddha Hegde
> <shraddha@juniper.net>; EXT- zhang.zheng@zte.com.cn
> <zhang.zheng@zte.com.cn>
> Subject: New Version Notification for
> draft-bonica-spring-srv6-end-dtm-01.txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
>
> Name: draft-bonica-spring-srv6-end-dtm
> Revision: 01
> Title: The SRv6 END.DTM Segment Type
> Document date: 2021-02-07
> Group: Individual Submission
> Pages: 7
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F9ybUH5$
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F9ybUH5$>
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-b>
> onica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8ap
> yYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8Oytsvgj$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F2zaLIO$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F2zaLIO$>
> Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8DZVjUN4$
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8DZVjUN4$>
> Diff:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-
> <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft->
> bonica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4t
> F8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8CJWOgzv$
>
> Abstract:
> This document describes a new SRv6 segment type, called END.DTM. The
> END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
> Like any segment type, END.DTM contains a function and arguments.
> The function causes the processing SRv6 node to remove an SRv6 header
> and impose an SR-MPLS label stack. The arguments determine MPLS-
> label stack contents.
>
>
>
>
> 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.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!TZVumo7a10f3Mu7tLnW06iZ9c6yuW_EVwbfeh-jooFDtvB9TevKWnUQVFtcVfDrk$>
> .
>
> The IETF Secretariat
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spr>
> ing__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3q
> bYIFrhF8PggLsaR$
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>
> ng__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbY
> IFrhF8PggLsaR$
>
>
> --
>
> Loa Andersson email: loa@pi.nu
> Senior MPLS Expert loa.pi.nu@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TZVumo7a10f3Mu7tLnW06iZ9c6yuW_EVwbfeh-jooFDtvB9TevKWnUQVFvteCmsw$>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TZVumo7a10f3Mu7tLnW06iZ9c6yuW_EVwbfeh-jooFDtvB9TevKWnUQVFrlDW1y5$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD