Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp

[Lou Berger <[e-mail]>]

Rakesh,
	Let's take a stab (off line) at language that addresses Adrian's
comment and captures (our understanding) of the intent of the existing
language, and then pass it around for review by all.  If you can take a
stab at it and send it to me that would be best.

Adrian,
	Give us a little time, say a day or two to get back to you.

Lou

On 01/27/2015 08:58 AM, Rakesh Gandhi (rgandhi) wrote:
> 
> 
> On 2015-01-27 6:26 AM, "Adrian Farrel" <[e-mail]> wrote:
> 
>> Right, well it is really just a case of "what do you want to achieve?"
>>
>> The point I raised originally was wrt the ERO.
>> Firstly the ERO when the Path reaches the egress is not a lot of help, so
>> there
>> is magic mapping from the RRO required.
>> But more importantly, if it is OK that the default position is that the
>> two LSPs
>> follow the same path, this is fine.  OTOH, without putting an ERO with a
>> single
>> loose hop into the Reverse_LSP you have no way of telling the egress that
>> it can
>> perform its own routing choice on the reverse LSP. That seems clunky, but
>> if it
>> what the WG wants then that is OK - you'd just need to state it and
>> explain
>> which RRO sub-objects need to be stripped when creating the reverse path
>> ERO
>> (for example, labels and interfaces might not be suitable in all cases).
> 
> 
> Hi Adrian,
> 
> In the WG, it was agreed that for co-routed LSPs, GMPLS signaling should
> be used. This is why there is no mention of co-routed LSPs in this draft.
> Given this, and the complexity of using RRO to achieve co-routed LSPs, I
> prefer to keep the co-routed LSPs outside the scope of this draft.
> 
> Thanks,
> Rakesh
> 
> 
> <Snip>
> 
> 
> 
>>
>> A
>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: 26 January 2015 15:05
>>> To: Rakesh Gandhi (rgandhi); [e-mail];
>>> draft-ietf-teas-mpls-tp-
>>> [e-mail]
>>> Cc: Alvaro Retana (aretana); [e-mail]
>>> Subject: Re: [Teas] AD review of
>> draft-ietf-teas-mpls-tp-rsvpte-ext-associated-
>>> lsp
>>>
>>>
>>> On 01/26/2015 08:54 AM, Rakesh Gandhi (rgandhi) wrote:> Hi Adrian,
>>>>
>>>> Thanks for your inputs.
>>>>
>>>> If the initiator really needs a specific behaviour, and depending on
>>> it,
>>>> it should signal the egress node via REVERSE_LSP.
>>>
>>> This is a key point.  From an interoperability standpoint there needs to
>>> be expected behavior.
>>>
>>>> IMO, MAY gives a reasonable choice for the egress node to do the right
>>>> thing and if that is not what the initiator prefers, it can alter it
>>> by
>>>> signaling REVERSE_LSP.
>>>>
>>>
>>> To me "MAY" translates to the initiator not being able to rely on any
>>> particular egress' behavior, so from a practical interoperability
>>> standpoint this translates to me to be "don't expect anything to work
>>> reliably without inclusion of the REVERSE_LSP object". So I really think
>>> the proposed language is a bad idea.
>>>
>>> It seems to me that the options are:
>>> (a) require the REVERSE_LSP Object and have it include all objects to be
>>> used
>>>  -- I think this is over kill and optimizes for the special case
>>>
>>> (b) define predictable behavior when REVERSE_LSP Object isn't present
>>> and when the REVERSE_LSP object doesn't contain all objects to be used.
>>>  -- I agree with Adrian's comment that an object enumeration based
>>> approach is risky as it's unclear what happens with new objects. I think
>>> this leads to a generic rule / directive which is how I read as the
>>> intent of the text that lead to this question.  Perhaps we can try to
>>> tighten up the language so an egress knows what it SHOULD/MUST do while
>>> an ingress can predict behavior?
>>>
>>> Lou
>>>
>>>> "
>>>>  If REVERSE_LSP Object is not present in the received Path message of
>>>>  the LSP, the egress node MAY use the LSP properties from the
>>>>  received LSP Path message to signal the LSP in the reverse direction
>>>>  (which may depend on the local policy).
>>>> "
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>>
>>>>
>>>> On 2015-01-25 5:33 PM, "Adrian Farrel" <[e-mail]> wrote:
>>>>
>>>>> Hi Lou, Rakesh, all...
>>>>>
>>>>> [snip]
>>>>>
>>>>>>>> 5.3 has
>>>>>>>>
>>>>>>>>   If REVERSE_LSP Object is not present in the received Path
>>> message
>>>>>> of
>>>>>>>>   the LSP, the egress node SHOULD use the LSP properties from the
>>>>>>>>   received LSP Path message to signal the LSP in the reverse
>>>>>> direction
>>>>>>>>   (which may depend on the local policy).
>>>>>>>>
>>>>>>>> This worries me. Do you mean that in the absence of a REVERSE_LSP
>>>>>> object
>>>>>>>> containing an ERO, the reverse LSP MUST be co-routed with the
>>> forward
>>>>>>>> LSP?
>>>>>>>
>>>>>>> <RG> No. There will also be no (forward LSP) full ERO in the LSP
>>>>>> either to
>>>>>>> do that.
>>>>>>> <RG> Does following work?
>>>>>>>
>>>>>>>    If REVERSE_LSP Object is not present in the received Path
>>> message
>>>>>> of
>>>>>>>    the LSP, the egress node MAY use the LSP properties from the
>>>>>>>    received LSP Path message to signal the LSP in the reverse
>>>>>> direction
>>>>>>>    that MAY or MAY NOT follow the forward LSP path
>>>>>>>    (which may depend on the local policy).
>>>>>>
>>>>>> Humm, I think we should dig into this a bit more before making this
>>>>>> change.
>>>>>>
>>>>>> Adrian,
>>>>>>
>>>>>> Do you have a specific concern with the existing text that you would
>>>>>> like
>>>>>> to see addressed ?
>>>>>>
>>>>>> I think the proposed revision is even less helpful.
>>>>>
>>>>> 1. "MAY NOT" is not 2119 language. It would be enough to say "MAY"
>>>>> because it
>>>>> implies you have a choice.
>>>>>
>>>>> 2. The ERO was just an example of what was worrying me. That is,
>>> that in
>>>>> the
>>>>> absence of sub-objects in the REVERSE_LSP object, the receiving end
>>> point
>>>>> SHOULD (i.e., is strongly directed to unless there is an unusual
>>>>> variation) use
>>>>> the parameters from the forward direction to govern the reverse LSP.
>>> It
>>>>> seems to
>>>>> me that there are probably different classes of information that fit
>>> into:
>>>>> - MUST be in the REVERSE_LSP object or everything will fail (I
>>> believe
>>>>> this is
>>>>> the empty set)
>>>>> - MUST be used from the forward LSP if not in the REVERSE_LSP object
>>>>> - SHOULD be used from the forward LSP if not in the REVERSE_LSP
>>> object
>>>>> - MAY be used from the forward LSP if not in the REVERSE_LSP object
>>>>> - MUST NOT be used from the forward LSP if not in the REVERSE_LSP
>>> object
>>>>>
>>>>> TSpec is a simple example of SHOULD (although maybe the reverse path
>>> TSpec
>>>>> should be modelled on the FlowSpec that will was sent on the Resv?).
>>>>> ERO (derived from the RRO) is either a MAY or a SHOULD depending on
>>> your
>>>>> thought
>>>>> pattern (some people think the default should be that the two LSPs
>>> fate
>>>>> share).
>>>>> The Session Name in the Session Attribute object seems like a MAY
>>> (noting
>>>>> that
>>>>> the name might already be in use).
>>>>> The Alarm_Spec object looks like a MUST NOT.
>>>>> Etc.
>>>>>
>>>>> I'm open to being persuaded that this collapses to one or two
>>> bullets.
>>>>> But if it
>>>>> is more than one bullet, I think there is work to be done to list it
>>> out.
>>>>> And
>>>>> that also worries me for extensibility - when I define a new object
>>>>> carried in a
>>>>> Path message, who is going to think about and document which class it
>>>>> belongs
>>>>> to?
>>>>> Perhaps "MAY" is the vaguest and safest?
>>>>>
>>>>> Adrian
>>>>>
>>>>
>>>> _______________________________________________
>>>> Teas mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>
>>
> 
>