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]<mailto:[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]<mailto:[email protected]>>
Sent: Friday, February 12, 2021 3:55 AM
To: Jeff Tantsura <[email protected]<mailto:[email protected]>>
Cc: Loa Andersson <[email protected]<mailto:[email protected]>>; Ron Bonica
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
Sent: Monday, February 8, 2021 11:51 PM
To: Jeff Tantsura <[email protected]<mailto:[email protected]>>;
Ron Bonica <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[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]<mailto:[email protected]>>
wrote:
Please review and comment
Juniper Business Use Only
-----Original Message-----
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky <[email protected]<mailto:[email protected]>>; Peng
Shaofu
<[email protected]<mailto:[email protected]>>; Ron Bonica
<[email protected]<mailto:[email protected]>>; Shaofu
Peng <[email protected]<mailto:[email protected]>>; Shraddha Hegde
<[email protected]<mailto:[email protected]>>; EXT-
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
Senior MPLS Expert [email protected]<mailto:[email protected]>
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
[email protected]<mailto:[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 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 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
Silver Spring, MD
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
