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

[Lou Berger <[e-mail]>]

Tarek,
    Thanks for the status.  I'll keep an eye out for the next rev.

Lou

On 10/13/2015 2:46 PM, Tarek Saad (tsaad) wrote:
> Hi Lou,
>
> The authors met and reviewed the proposal to use the RSVP Association
> object as a mechanism to relay the per-group bypass assignment information
> between the PLR(s) and MP(s). We agree that since the Association object
> as proposed is used to associate recovery LSP with the LSPs it is
> protecting can serve the purpose of associating a group of protected
> LSP(s) with a bypass LSP. We are looking into extending the IPv4/IPv6
> Extended ASSOCIATION Object (as defined in rfc6780) to carry the necessary
> Summary FRR information between the PLR and MP. We plan to add this in the
> next revision of the document.
>  
> Regards,
> Tarek
>
>
>
> On 2015-09-25, 8:20 AM, "Lou Berger" <[e-mail]> wrote:
>
>> Tarek,
>>    Thanks for the response, see below.
>>
>> On 9/20/2015 10:39 PM, Tarek Saad (tsaad) wrote:
>>> Thanks Lou for your review and comments. Inline for responses.
>>>
>>> On 2015-09-17, 11:21 AM, "mpls on behalf of Lou Berger"
>>> <[e-mail] on behalf of [e-mail]> wrote:
>>>
>>>> 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.
>>> [TS]: seems reasonable, we will discuss this among the authors for a
>>> suitable extension.
>> great.
>>
>>>> 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:
>>> [TS]: the new SO, is recording local information that if intercepted by
>>> another LSR (PLR or MP that understands it) can use it for further
>>> summary
>>> FRR processing. This resembles to an extent what other RRO SOs do today
>>> (e.g. node-id and label Sos) for regular FRR.
>> The point was that those SOs serve their original purpose of being
>> useful in constructing EROs, while the new SOs really have entirely
>> different semantics -- for example what does it mean if an ingress
>> includes the new SOs for a transit node?
>>
>>>>   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
>>> [TS]: yes, the comment (about RRO policies) is rightfully correct. ..
>>> but
>>> also applicable to existing RRO/SO(s) (e.g. node-id and/or label SO)
>>> needed for proper FRR too.
>> Again, this was leveraging SOs that were defined & used for other
>> purposes and overloading their semantics.
>>
>>> That said, will discuss extension of an
>>> existing (FRR) object amongst the authors for (dis)advantages.
>> That would be great and will be very interested in hearing your thoughts.
>>
>> Thanks,
>> Lou
>>
>>> Regards,
>>> Tarek
>>>
>>>
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>