JSON examples for MPLS static LSP configuration

drafts/te-types-update/diffs/te-pkt-types/model-diff-spaces.txt

@@ -1,46 +1,63 @@
-    11c11,12
+    11c11
     <       "RFC 8776: Common YANG Data Types for Traffic Engineering";
     ---
-    >       "RFCXXXX: Updated Common YANG Data Types for Traffic 
-    >       Engineering";
-    12a14,15
+    >       "RFCXXXX: Common YANG Data Types for Traffic Engineering";
+    12a13,14
     >   // RFC Editor: replace XXXX with actual RFC number
     >   // and remove this note
-    22c25
+    22c24
     <                <mailto:tsaad@juniper.net>
     ---
     >                <mailto:tsaad.net@gmail.com>
-    41c44
+    37,39c39,49
+    <      data type definitions specific to MPLS TE.  The model fully
+    <      conforms to the Network Management Datastore Architecture
+    <      (NMDA).
+    ---
+    >      data type definitions specific to Packet Traffic Enginnering
+    >      (TE).
+    >      
+    >      The model fully conforms to the Network Management Datastore
+    >      Architecture (NMDA).
+    > 
+    >      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+    >      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
+    >      'MAY', and 'OPTIONAL' in this document are to be interpreted as
+    >      described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
+    >      they appear in all capitals, as shown here.
+    41c51
     <      Copyright (c) 2020 IETF Trust and the persons identified as
     ---
-    >      Copyright (c) 2023 IETF Trust and the persons identified as
-    46c49
+    >      Copyright (c) 2024 IETF Trust and the persons identified as
+    46c56
     <      the license terms contained in, the Simplified BSD License set
     ---
     >      the license terms contained in, the Revised BSD License set
-    51,52c54,71
+    51,52c61,80
     <      This version of this YANG module is part of RFC 8776; see the
     <      RFC itself for full legal notices.";
     ---
     >      This version of this YANG module is part of RFC XXXX
     >      (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     >      for full legal notices.";
-    > 
-    >   revision 2023-07-10 {
+    >   revision 2024-01-25 {
     >     description
     >       "Added common TE packet identities:
-    >        - bandwidth-profile-type.
+    >        - bandwidth-profile-type;
+    >        - path-metric-loss;
+    >        - path-metric-delay-variation.
     > 
     >        Added common TE packet groupings:
     >        - te-packet-path-bandwidth;
-    >        - te-packet-link-bandwidth.";
+    >        - te-packet-link-bandwidth.
+    >        
+    >        Updated module description.";
     >     reference
-    >       "RFC XXXX: Updated Common YANG Data Types for Traffic
-    >       Engineering";
+    >       "RFC XXXX: Common YANG Data Types for Traffic Engineering";
     >   }
     >   // RFC Editor: replace XXXX with actual RFC number, update date
     >   // information and remove this note
-    61c80,126
+    61c89,187
     <   /**
     ---
     >   /*
@@ -89,13 +106,65 @@
     >         Marker with Efficient Handling of in-Profile Traffic";
     >     }
     > 
+    >   // CHANGE NOTE: The identity path-metric-loss below has 
+    >   // been added in this module revision
+    >   // RFC Editor: remove the note above and this note
+    >   identity path-metric-loss {
+    >     base te-types:path-metric-type;
+    >     description
+    >       "The path loss (as a packet percentage) metric type
+    >       encodes a function of the unidirectional loss metrics of all
+    >       links traversed by a P2P path.
+    >        
+    >       The basic unit is 0.000003%,
+    >       where (2^24 - 2) or 50.331642% is the maximum value of the
+    >       path loss percentage that can be expressed.
+    >       
+    >       Values that are larger than the maximum value SHOULD be
+    >       encoded as the maximum value.";
+    >     reference
+    >       "RFC8233: Extensions to the Path Computation Element
+    >       Communication Protocol (PCEP) to Compute Service-Aware Label
+    >       Switched Paths (LSPs);
+    > 
+    >       RFC7471: OSPF Traffic Engineering (TE) Metric Extensions;
+    > 
+    >       RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.";
+    >   }
+    > 
+    >   // CHANGE NOTE: The identity path-metric-delay-variation below has 
+    >   // been added in this module revision
+    >   // RFC Editor: remove the note above and this note
+    >   identity path-metric-delay-variation {
+    >     base te-types:path-metric-type;
+    >     description
+    >       "The path delay variation encodes the sum of the unidirectional
+    >       delay variation metrics of all links traversed by a P2P path.
+    >       
+    >       The path delay variation metric unit is in microseconds, where
+    >       (2^24 - 1) or 16,777,215 microseconds (16.777215 sec) is the
+    >       maximum value of the path delay variation that can be
+    >       expressed.
+    >       
+    >       Values that are larger than the maximum value SHOULD be
+    >       encoded as the maximum value.";
+    >     reference
+    >       "RFC8233: Extensions to the Path Computation Element
+    >       Communication Protocol (PCEP) to Compute Service-Aware Label
+    >       Switched Paths (LSPs);
+    > 
+    >       RFC7471: OSPF Traffic Engineering (TE) Metric Extensions;
+    > 
+    >       RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.";
+    >   }
+    > 
     >   /*
-    180a246,249
+    180a307,310
     >   /*
     >    * Groupings
     >    */
     > 
-    472a542,611
+    472a603,672
     >     }
     >   }
     > 

drafts/te-types-update/diffs/te-pkt-types/model-diff.txt

@@ -1,46 +1,63 @@
-11c11,12
+11c11
 <       "RFC 8776: Common YANG Data Types for Traffic Engineering";
 ---
->       "RFCXXXX: Updated Common YANG Data Types for Traffic 
->       Engineering";
-12a14,15
+>       "RFCXXXX: Common YANG Data Types for Traffic Engineering";
+12a13,14
 >   // RFC Editor: replace XXXX with actual RFC number
 >   // and remove this note
-22c25
+22c24
 <                <mailto:tsaad@juniper.net>
 ---
 >                <mailto:tsaad.net@gmail.com>
-41c44
+37,39c39,49
+<      data type definitions specific to MPLS TE.  The model fully
+<      conforms to the Network Management Datastore Architecture
+<      (NMDA).
+---
+>      data type definitions specific to Packet Traffic Enginnering
+>      (TE).
+>      
+>      The model fully conforms to the Network Management Datastore
+>      Architecture (NMDA).
+> 
+>      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+>      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
+>      'MAY', and 'OPTIONAL' in this document are to be interpreted as
+>      described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
+>      they appear in all capitals, as shown here.
+41c51
 <      Copyright (c) 2020 IETF Trust and the persons identified as
 ---
->      Copyright (c) 2023 IETF Trust and the persons identified as
-46c49
+>      Copyright (c) 2024 IETF Trust and the persons identified as
+46c56
 <      the license terms contained in, the Simplified BSD License set
 ---
 >      the license terms contained in, the Revised BSD License set
-51,52c54,71
+51,52c61,80
 <      This version of this YANG module is part of RFC 8776; see the
 <      RFC itself for full legal notices.";
 ---
 >      This version of this YANG module is part of RFC XXXX
 >      (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
 >      for full legal notices.";
-> 
->   revision 2023-07-10 {
+>   revision 2024-01-25 {
 >     description
 >       "Added common TE packet identities:
->        - bandwidth-profile-type.
+>        - bandwidth-profile-type;
+>        - path-metric-loss;
+>        - path-metric-delay-variation.
 > 
 >        Added common TE packet groupings:
 >        - te-packet-path-bandwidth;
->        - te-packet-link-bandwidth.";
+>        - te-packet-link-bandwidth.
+>        
+>        Updated module description.";
 >     reference
->       "RFC XXXX: Updated Common YANG Data Types for Traffic
->       Engineering";
+>       "RFC XXXX: Common YANG Data Types for Traffic Engineering";
 >   }
 >   // RFC Editor: replace XXXX with actual RFC number, update date
 >   // information and remove this note
-61c80,126
+61c89,187
 <   /**
 ---
 >   /*
@@ -89,13 +106,65 @@
 >         Marker with Efficient Handling of in-Profile Traffic";
 >     }
 > 
+>   // CHANGE NOTE: The identity path-metric-loss below has 
+>   // been added in this module revision
+>   // RFC Editor: remove the note above and this note
+>   identity path-metric-loss {
+>     base te-types:path-metric-type;
+>     description
+>       "The path loss (as a packet percentage) metric type
+>       encodes a function of the unidirectional loss metrics of all
+>       links traversed by a P2P path.
+>        
+>       The basic unit is 0.000003%,
+>       where (2^24 - 2) or 50.331642% is the maximum value of the
+>       path loss percentage that can be expressed.
+>       
+>       Values that are larger than the maximum value SHOULD be
+>       encoded as the maximum value.";
+>     reference
+>       "RFC8233: Extensions to the Path Computation Element
+>       Communication Protocol (PCEP) to Compute Service-Aware Label
+>       Switched Paths (LSPs);
+> 
+>       RFC7471: OSPF Traffic Engineering (TE) Metric Extensions;
+> 
+>       RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.";
+>   }
+> 
+>   // CHANGE NOTE: The identity path-metric-delay-variation below has 
+>   // been added in this module revision
+>   // RFC Editor: remove the note above and this note
+>   identity path-metric-delay-variation {
+>     base te-types:path-metric-type;
+>     description
+>       "The path delay variation encodes the sum of the unidirectional
+>       delay variation metrics of all links traversed by a P2P path.
+>       
+>       The path delay variation metric unit is in microseconds, where
+>       (2^24 - 1) or 16,777,215 microseconds (16.777215 sec) is the
+>       maximum value of the path delay variation that can be
+>       expressed.
+>       
+>       Values that are larger than the maximum value SHOULD be
+>       encoded as the maximum value.";
+>     reference
+>       "RFC8233: Extensions to the Path Computation Element
+>       Communication Protocol (PCEP) to Compute Service-Aware Label
+>       Switched Paths (LSPs);
+> 
+>       RFC7471: OSPF Traffic Engineering (TE) Metric Extensions;
+> 
+>       RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.";
+>   }
+> 
 >   /*
-180a246,249
+180a307,310
 >   /*
 >    * Groupings
 >    */
 > 
-472a542,611
+472a603,672
 >     }
 >   }
 >