New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for IPv6 #129
Comments
The tunnel endpoints are identified by TE node ID in the topology. Tunnel |
Agreed to use the te-gen-node-id datatype for tunnel source/destination and nodes in the explicit-route elements These attributes will be interpreted as:
Need to improve the description since the node in the TE topology is identified only by the te-node-id and not by an IP address. IS-IS and OSPF-TE provides some mapping between a dotted-quad te-node-id and one or more IPv4/IPv6 addresses |
2023-05-26 TE Call Agreed not to take actions
|
Discussed this on 06/02:
|
This issue will be addressed in the Packet TE Tunnel model and it is out of scope of the generic TE Tunnel model |
I believe that this topic should be addressed in this draft and not in packet TE tunnel model. One of the proposals was to have an optional leaf with src-ip and dst-ip and adding these optional leafs into the draft would cover the scenario without impacting the rest of the draft. |
See WG LC comment in https://mailarchive.ietf.org/arch/msg/teas/uqCE1W7j4cfkTmWo-Vzib80IVkc/ |
The recommendation is to make a change to RFC8776-bis: Update the description to reflect dotted-quad,v4,v6 are possible |
Discussed with Netmod WG whether this change is BC or NBC: https://mailarchive.ietf.org/arch/msg/netmod/iwFmNRp6jK79Wv6VR30oOomtj9M/ |
2024-01-19 TE Call No conclusive answer from Netmod WG about BC/NBC change Agreed to implement the change in the draft without mentioning the NBC issue In the description, clarify that the v6 address type is re-used for the formatting but the te-node-id is still an identifier and not a routable address Reference for IS-IS IPv6 Router ID: https://datatracker.ietf.org/doc/html/rfc6119 |
Added support also for 16 octects TE identifiers (formatted as IPv6 addresses): fix tsaad-dev#129
In the TE Model we have:
In Te-Types:
That means the 128-bit IPv6 address cant be source and destination in TE tunnel/LSPs. Isn't that an issue that we should fix?
The text was updated successfully, but these errors were encountered: