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

["Adrian Farrel" <[e-mail]>]

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
>