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

On 2015-01-27 6:26 AM, "Adrian Farrel" <adrian@olddog.co.uk> 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:lberger@labn.net]
>> Sent: 26 January 2015 15:05
>> To: Rakesh Gandhi (rgandhi); adrian@olddog.co.uk;
>>draft-ietf-teas-mpls-tp-
>> rsvpte-ext-associated-lsp.all@ietf.org
>> Cc: Alvaro Retana (aretana); teas@ietf.org
>> 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" <adrian@olddog.co.uk> 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
>> > Teas@ietf.org
>> > https://www.ietf.org/mailman/listinfo/teas
>> >
>