Re: [Teas] RSVP-TE text in draft-ietf-teas-rfc3272bis

[Gyan Mishra <[e-mail]>]

Looks Excellent!

Ready for publication!

Gyan

On Wed, Jul 6, 2022 at 5:18 PM Adrian Farrel <[e-mail]> wrote:

> OK, Gyan.
>
>
>
> Merged and polished gives us…
>
>
>
> 5.1.3.4.  RSVP-TE
>
>
>
>    RSVP-TE is a protocol extension of RSVP (Section 5.1.3.2) for traffic
>
>    engineering.  The base specification is found in [RFC3209].  RSVP-TE
>
>    enables the establishment of traffic engineered MPLS LSPs (TE LSPs),
>
>    using loose or strict paths, and taking into consideration network
>
>    constraints such as available bandwidth.  The extension supports
>
>    signaling LSPs on explicit paths that could be administratively
>
>    specified, or computed by a suitable entity (such as a PCE,
>
>    Section 5.1.3.11) based on QoS and policy requirements, taking into
>
>    consideration the prevailing network state as advertised by IGP
>
>    extension for ISIS in [RFC5305], for OSPFV2 in [RFC3630], and for
>
>    OSPFv3 in [RFC5329].  RSVP-TE enables the reservation of resources
>
>    (for example, bandwidth) along the path.
>
>
>
>    RSVP-TE includes the ability to preempt LSP based on priorities, and
>
>    uses link affinities to include or exclude links from the paths of
>
>    LSPs.  The protocol is further extended to support Fast Reroute (FRR)
>
>    [RFC4090], Diffserv [RFC4124], and bidirectional LSPs [RFC7551].
>
>    RSVP-TE extensions for support for GMPLS (see Section 5.1.3.5 are
>
>    specified in [RFC3473].
>
>
>
>    Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
>
>    documented in [RFC4461], and signaling protocol extensions for
>
>    setting up P2MP MPLS TE LSPs via RSVP-TE is defined in [RFC4875]
>
>    where a P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-
>
>    LSPs.  To determine the paths for P2MP LSPs, selection of the branch
>
>    points (based on capabilities, network state, and policies) is key.
>
>
>
>    RSVP-TE has evolved to provide real time dynamic metrics for path
>
>    selection for low latency paths using extensions to ISIS [RFC7810]
>
>    and OSPF [RFC7471] based on STAMP [RFC8972] and TWAMP [RFC5357]
>
>    performance measurements.
>
>
>
>    RSVP-TE has historically been used when bandwidth was constrained,
>
>    however, as bandwidth has increased, RSVP-TE has developed into a
>
>    bandwidth management tool to provide bandwidth efficiency and
>
>    proactive resource management.
>
>
>
> What do you think?
>
>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* 05 July 2022 19:18
> *To:* [e-mail]
> *Cc:* TEAS WG <[e-mail]>
> *Subject:* Re: [Teas] FW: I-D Action: draft-ietf-teas-rfc3272bis-18.txt
>
>
>
>
>
> Hi Adrian
>
>
>
> I was expanding on what you already had in 5.1.3.4  so I was thinking you
> could just add on / integrate into what you already have.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Tue, Jul 5, 2022 at 2:02 PM Adrian Farrel <[e-mail]> wrote:
>
> Thanks Gyan,
>
>
>
> Do you propose that that replace Section 5.1.3.4 or should I try to
> integrate it?
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* 05 July 2022 18:17
> *To:* [e-mail]
> *Cc:* TEAS WG <[e-mail]>
> *Subject:* Re: [Teas] FW: I-D Action: draft-ietf-teas-rfc3272bis-18.txt
>
>
>
>
>
> Hi Adrian
>
>
>
> Text below:
>
>
>
> RSVP-TE enables the instantiation of static MPLS LSP loose hops, strict
> hops or a dynamic LSP using IGP extension for ISIS RFC 5305, OSPFV2
> extension RFC 3630 and OSPFv3 extension RFC 5329 for cSPF (constrained SPF)
> Traffic Engineering database (TED) using static TE metrics.  RSVP-TE has
> now evolved to provide real time dynamic metrics for path selection using
> RSVP-TE ISIS extension RFC 7810 and RSVP-TE OSPF extension RFC 7471 based
> on IPPM STAMP RFC 8972 and TWAMP RFC 5357 performance measurements for low
> latency paths. RSVP-TE provides traffic  management capabilities with ECN
> style congestion notification using setup and hold RSVP-TE LSP priorities
> allowing the ability to preempt LSPs based on traffic class as well as
> re-optimization fallback to primary path.  Traffic management features have
> been enhanced significantly with newer hardware and software capabilities.
> RSVP-TE provides link affinity bits to provide a method to include or
> exclude links from TED database for cSPF dynamic LSP instantiation. RSVP-TE
> provides Fast Reroute (FRR) pre signaled Make before break (MBB) link, node
> and path protection from Point of Local Repair (PLR) to Merge Point (MP)
> with FRR extension RFC 4090, yielding approximately 50ms restoration time
> for both P2P and P2MP RSVP-TE tunnels.  RSVP-TE supports Inter-AS TE with
> ISIS extension RFC 5316 and OSPF extension RFC 5392 and Inter Domain MPLS
> and GMPLS RSVP-TE extension RFC 5151.
>
>
>
> RSVP-TE has historically been used when bandwidth was constrained, however
> as bandwidth has increased exponentially over the years, RSVP-TE has
> evolved into a bandwidth management tool to provide bandwidth efficiency
> and proactive resource management.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Tue, Jul 5, 2022 at 6:15 AM Adrian Farrel <[e-mail]> wrote:
>
> OK. Thanks.
>
>
>
> A
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* 04 July 2022 23:50
> *To:* [e-mail]
> *Cc:* TEAS WG <[e-mail]>
> *Subject:* Re: [Teas] FW: I-D Action: draft-ietf-teas-rfc3272bis-18.txt
>
>
>
> Hi Adrian
>
>
>
> I am working on some text to Dons questions as well as additional RSVP-TE
> related details to the new section created.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Mon, Jul 4, 2022 at 6:07 PM Adrian Farrel <[e-mail]> wrote:
>
> OK.
>
> We now have a small Appendix section to cover CR-LDP.
>
> Does anyone else have a further proposal to address Don's comments or are
> we
> done?
>
> Cheers,
> Adrian
>
> -----Original Message-----
> From: I-D-Announce <[e-mail]> On Behalf Of
> [e-mail]
> Sent: 04 July 2022 23:04
> To: [e-mail]
> Cc: [e-mail]
> Subject: I-D Action: draft-ietf-teas-rfc3272bis-18.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Traffic Engineering Architecture and
> Signaling WG of the IETF.
>
>         Title           : Overview and Principles of Internet Traffic
> Engineering
>         Author          : Adrian Farrel
>   Filename        : draft-ietf-teas-rfc3272bis-18.txt
>   Pages           : 97
>   Date            : 2022-07-04
>
> Abstract:
>    This document describes the principles of traffic engineering (TE) in
>    the Internet.  The document is intended to promote better
>    understanding of the issues surrounding traffic engineering in IP
>    networks and the networks that support IP networking, and to provide
>    a common basis for the development of traffic engineering
>    capabilities for the Internet.  The principles, architectures, and
>    methodologies for performance evaluation and performance optimization
>    of operational networks are also discussed.
>
>    This work was first published as RFC 3272 in May 2002.  This document
>    obsoletes RFC 3272 by making a complete update to bring the text in
>    line with best current practices for Internet traffic engineering and
>    to include references to the latest relevant work in the IETF.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-18
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rfc3272bis-18
>
>
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*