Re: [mpls] progressing draft-mtaillon-mpls-summary-frr-rsvpte

[Lou Berger <[e-mail]>]

I have some comments on the proposed mechanism (I have no opinion on
utility or likely implementation):

1. WRT SUMMARY_FRR_BYPASS_ACTIVE object

RSVP object space is a pretty scarce resource and it seems we have a
number of existing objects that could be reused to support transport of
the required information.  Some candidates include: the Association
object with a new association type; or perhaps the PRIMARY_PATH_ROUTE
Object with a new C-type.

2. SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects

While RFC4090 makes use of RRO carried information, it does so without
changing the RRO format.  (At the time, I recall some used this as
justification for RRO usage vs introducing new formats.)  The new SOs
introduce new information and don't seem to be particularly linked to
normal RRO operation -- and more significantly really defining new
transit-node to transit-node signaling semantics:

   The PLR notifies the MP of the bypass tunnel assignment via adding a
   SUMMARY_FRR_BYPASS_ASSIGNMENT subobject to the RSVP Path message
   RECORD_ROUTE object ...

   The MP acknowledges the PLR's assignment by signalling a
   SUMMARY_FRR_BYPASS_ASSIGNMENT subobject within the RSVP Resv messsage
   RECORD_ROUTE object.

IMO this usage of RRO is really wrong (and is easily broken by
application of RRO policies).  I think extending an existing object
class is a better approach. Extending one of the existing FRR objects
would probably be cleanest, but think the authors should consider and
propose their preference.

Lou

On 9/17/2015 6:44 AM, Loa Andersson wrote:
> Working Groups,
>
> The mpls and teas working group chairs discussed the home working
> group for draft-mtaillon-mpls-summary-frr-rsvpte. Since the is entirely
> the choice fell on the mpls working group. We also decided to keep
> the teas wg in the loop.
>
> We have just initiated the mpls review team (MPLS-RT) review if this
> draft. This review is focused on if we want to accept the document as
> a working group draft, and if it is in shape for us to do so.
>
> The MPLS-RT reviewers are picked by the mpls chair that will shepherd
> the document.
>
> This also mean that this is a good time for anyone, from both working
> groups, to review the document. Please send your reviews to the mpls
> working group mailing list ([e-mail]).
>
> /Loa
>