Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

Dhruv, thanks.

Your RSVP-TE text results in the section below.

I find the use of “TE” in the term BIER-TE unfortunate. That that work used to be called “Traffic Engineering for BIER” was one of the inspirations for reopening RFC3272bis. You’re right that section 3.5 of the BIER-TE architecture document goes some way to explaining tree engineering in the context of traffic engineering, so I have also included the text further below.

Cheers,

Adrian

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),

   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.

   RSVP-TE enables the reservation of resources (for example, bandwidth)

   along the path.

   RSVP-TE 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.

5.1.3.13.  Bit Index Explicit Replication Tree Engineering

   Bit Index Explicit Replication (BIER) [RFC8279] specifies an
   encapsulation for multicast forwarding that can be used on MPLS or
   Ethernet transports.  A mechanism known as Tree Engineering for Bit
   Index Explicit Replication (BIER-TE) [I-D.ietf-bier-te-arch] provides
   a component that could be used to build a traffic engineering
   multicast system.  Note well: BIER-TE does not of itself offer
   traffic engineering, and the abbreviation "TE" does not, in this case,
   refer to traffic engineering.

   In BIER-TE, path steering is supported via the definition of a
   bitstring attached to each packet that determines how the packet is
   forwarded and replicated within the network.  Thus, this bitstring
   steers the traffic within the network and forms an element of a
   traffic engineering system.  A central controller that is aware of
   the capabilities and state of the network as well as the demands of
   the various traffic flows, is able to select multicast paths that
   take account of the available resources and demands.  This
   controller, therefore, is responsible for the policy elements of
   traffic engineering.

   Resource management has implications on the forwarding plane beyond
   the BIER-TE defined steering of packets.  This includes allocation of
   buffers to guarantee the worst case requirements of admitted traffic
   and potentially policing and/or rate-shaping mechanisms, typically
   done via various forms of queuing.  This level of resource control,
   while optional, is important in networks that wish to support
   congestion management policies to control or regulate the offered
   traffic to deliver different levels of service and alleviate
   congestion problems, or those networks that wish to control latencies
   experienced by specific traffic flows.

From: Dhruv Dhody <dhruv.ietf@gmail.com> 
Sent: 28 June 2022 08:26
To: Farrel Adrian <adrian@olddog.co.uk>
Cc: Vishnu Pavan Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>; TEAS WG Chairs <teas-chairs@ietf.org>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

Hi Adrian,

On Mon, Jun 27, 2022 at 9:24 PM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > wrote:

Hi Dhruv,

Thanks for your reviews, past and present.

See in line.

Adrian

From: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > On Behalf Of Dhruv Dhody
Sent: 23 June 2022 18:30
To: Vishnu Pavan Beeram <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com> >
Cc: TEAS WG <teas@ietf.org <mailto:teas@ietf.org> >; TEAS WG Chairs <teas-chairs@ietf.org <mailto:teas-chairs@ietf.org> >
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

Hi WG, 

I reviewed the document in the past. I did a pass again. Thanks, Adrian and the design team for a great job! 

Compared to details provided for other techniques, I found the details about RSVP-TE to be lacking. We have a section on RSVP [1] but it does not say much about RSVP-TE. Wouldn't it make sense to have an explicit section on RSVP-TE for such a comprehensive I-D? 

[AF] I suppose that would go after 5.1.3.2 to follow on from the last sentence of that section, and comes before 5.1.3.3 that would build on it. But you know what I am going to say…

[AF] I’d be happy to receive some text.

[Dhruv]: Here is something for you to further refine...

RSVP-TE is a protocol extension of the RSVP for traffic 

engineering as specified in [RFC3209]. RSVP-TE allows 

the establishment of TE LSPs, taking into consideration 

network constraint parameters such as available bandwidth. 

The extension supports signaling explicit paths that could

be administratively specified, or automatically computed 

by a suitable entity (such as PCE) based on the QoS and 

policy requirements, taking into consideration the 

prevailing network state. RSVP-TE enables the allocation 

of resources (for example, bandwidth) along the path using

the PATH and RESV messages.

RSVP-TE is further extended to support Fast Reroute (FRR)

[RFC4090], Diffserv [RFC4124], Bidirectional LSPs 

[RFC7551]. Support for GMPLS for RSVP-TE is specified in 

[RFC3473].

To support TE for multicast services, 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.  

I also wonder if there should be some text on TE for multicast? 

[AF] Would that be anything that didn’t go in the RSVP-TE section?

[Dhruv]: I can think of BIER-TE, maybe a pointer to https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-13.html#section-3.5

or borrow some text? 

Thanks! 

Dhruv

Otherwise, IMHO the document is ready to be shipped! 

Thanks! 

Dhruv

[1] https://www.ietf.org/archive/id/draft-ietf-teas-rfc3272bis-16.html#section-5.1.3.2

On Tue, May 24, 2022 at 10:52 PM Vishnu Pavan Beeram <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com> > wrote:

All,

This starts working group last call on

https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/

Given the size of the document, this will be an extended
LC (3 weeks). The working group last call ends on June 14th.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Pavan (Co-Chair & Doc Shepherd)

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas