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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Acking, Thank you Adrian.


On 2015-02-06 12:33 PM, "Adrian Farrel" <[e-mail]> wrote:

>I'm sorry, were you waiting for a response from me?
>
>I think you have covered all of my points and you can make and post a new
>revision, then we'll move on.
>
>A
>
>> -----Original Message-----
>> From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
>> Sent: 23 January 2015 23:17
>> To: [e-mail]; draft-ietf-teas-mpls-tp-rsvpte-ext-associated-
>> [e-mail]
>> Cc: [e-mail]; Alvaro Retana (aretana)
>> Subject: Re: AD review of
>>draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp
>> 
>> Thank you Adrian for the thorough review.
>> 
>> Please see replies inline .. <RG> ..
>> 
>> 
>> On 2015-01-22 9:37 AM, "Adrian Farrel" <[e-mail]> wrote:
>> 
>> >Thanks for this document which I found clear and not too long.
>> 
>> <RG> Thank you.
>> 
>> >
>> >I have done my usual AD review to try to flush out any issues that
>> >might otherwise show up in IETF last call or IESG review.
>> >
>> >The only largish issue I have is about error conditions. Pretty much
>>the
>> >only error handling I see is in 5.3 where you have:
>> >
>> >   An egress node, upon receiving a Path message containing an
>> >   ASSOCIATION or Extended ASSOCIATION Object with Association Type set
>> >   to "Single Sided Associated Bidirectional LSP" MUST create an LSP in
>> >   the reverse direction or reject the Path message by sending a
>> >   PathErr.
>> >
>> >...but you don't say what reason code to give.
>> >
>> 
>> 
>> ><RG> Ack, please see below.
>> >
>> >
>> >You need to handle some other error conditions such as...
>> >
>> >**** race conditions
>> >**** what if the association is triggered by both ends at the same
>>time?
>> >
>> 
>> ><RG> For double sided provisioning, this is expected and may not
>> >necessary be an error. For single sided provisioning, this should not
>> >happen given egress node only triggers reverse LSP as a response to the
>> >incoming LSP.
>> >
>> >**** what if the reverse dirn LSP has already been associated with
>> >something else?
>> >
>> 
>> ><RG> This can happen when an LSP on one side is being rerouted, and may
>> >not necessarily be an error condition. For example, during MBB, there
>> >will be two LSPs and association may be updated at some time during the
>> >MBB process.
>> >
>> >**** failure conditions
>> >**** what if not willing or able to associate?
>> >
>> 
>> 
>> ><RG> It is a bit difficult to know if this is really an error or it is
>>a
>> >transient condition due to LSP reroute or while node is being
>> >provisioned, or there is provisioning error, etc. In such cases,
>> >bidirectional LSP state would stay down so there should not any effect
>>on
>> >traffic.
>> >
>> >
>> >**** what if set-up of reverse LSP fails?
>> >**** what if requested REVERSE LSP parameters are not acceptable?
>> >
>> >
>> 
>> ><RG> These are for single sided provisioning, right? For both of the
>> >above cases, we can add a new PathErr ("LSP Admission Failure/Reverse
>>LSP
>> >Failure". Operator needs to then check the egress node as reverse LSP
>> >failure could be for many different reasons. If you agree, we can add a
>> >new PathErr code in the document (Reverse LSP Failure).
>> >
>> >
>> >**** what if the remote end point doesn't support the association
>> >mechanism defined here? how will the initiator know?
>> >
>> 
>> ><RG> An egress node may send PathErr ("LSP Admission Failure/Bad
>> >Association Type" [RFC4872]. We can add it in the document if you
>>agree.
>> >
>> >
>> >
>> 
>> <SNIP>
>> 
>> 
>> Thanks,
>> 
>> Rakesh
>> 
>
>