Make sense! Thanks
Gyan On Mon, Feb 15, 2021 at 10:56 AM Ron Bonica <[email protected]> wrote: > Hi Gyan, > > > > In theory, it should map any END.DTM to any MPLS label stack, regardless > of the control plane. > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra <[email protected]> > *Sent:* Monday, February 15, 2021 12:18 AM > *To:* Ron Bonica <[email protected]> > > *Cc:* Jeff Tantsura <[email protected]>; Loa Andersson <[email protected]>; > [email protected] > *Subject:* Re: [spring] FW: New Version Notification for > draft-bonica-spring-srv6-end-dtm-01.txt > > > > *[External Email. Be cautious of content]* > > > > > > 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 <[email protected]> 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 <[email protected]> > *Sent:* Friday, February 12, 2021 3:55 AM > *To:* Jeff Tantsura <[email protected]> > *Cc:* Loa Andersson <[email protected]>; Ron Bonica <[email protected]>; > [email protected] > *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 <[email protected]> > 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 <[email protected]>, 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 <[email protected]> > Sent: Monday, February 8, 2021 11:51 PM > To: Jeff Tantsura <[email protected]>; Ron Bonica < > [email protected]> > Cc: [email protected] > 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 <[email protected]> > wrote: > > > Please review and comment > > > Juniper Business Use Only > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Sunday, February 7, 2021 11:41 AM > To: Greg Mirsky <[email protected]>; Peng Shaofu > <[email protected]>; Ron Bonica <[email protected]>; Shaofu > Peng <[email protected]>; Shraddha Hegde > <[email protected]>; EXT- [email protected] > <[email protected]> > 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 > [email protected] > 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 > [email protected] > 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: [email protected] > Senior MPLS Expert [email protected] > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TZVumo7a10f3Mu7tLnW06iZ9c6yuW_EVwbfeh-jooFDtvB9TevKWnUQVFvteCmsw$> > > -- > > [image: Image removed by sender.] > <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://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike?entry=gmail&source=g__;Kys!!NEt6yMaO-gk!SxXh23PxhqhKPJavn0YFRaVlbQaMsJt52t189MNQrydcMfjljeN9XpBLe0cAVGGF$> > *Silver Spring, MD > > > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SxXh23PxhqhKPJavn0YFRaVlbQaMsJt52t189MNQrydcMfjljeN9XpBLewVfXQYW$> > > *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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
