Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb

Dear Adrian, 

Thanks a lot for your review, please see my replies inline.

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Saturday, January 03, 2015 10:34 PM
> To: draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org
> Cc: teas@ietf.org
> Subject: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb
> 
> Thank you for recognising the use of the Administratively Down bit for LI. It's
> good to see existing mechanisms being adapted to new uses.
> 
> I've done my usual AD review to try to catch any issues before IETF last call. I've
> found a few issues, the first two of which will need discussion in the working
> group, I think. The remaining issues are relatively minor.
> 
> While we wait for you to discuss these issues and possibly issue a new revision, I
> will put the document into "Revised I-D Needed" state.
> 
> Thanks for the work,
> Adrian
> 
> ---
> 
> You want to use a bit in the Attribute Flags TLV to indicate Loopback and
> propose including that TLV in the HOP Attributes ERO subobject as defined in
> draft-ietf-ccamp-lsp-attribute-ro.
> 
> Please note that that draft is now draft-ietf-teas-lsp-attribute-ro.

Thanks for pointing out this, will update the reference in a new revision. 

> However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags TLV is
> not allowed in the HOP Attributes ERO subobject. I think this is for a good
> reason that many (all?) of bits defined so far have no meaning if targeted at a
> specific transit LSR.

I guess there may be some confusion about this. Section 5.3.1 of draft-ietf-teas-lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says it is "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP Attribute subobject". 

> I think you need to describe what happens if a LB instruction is received when
> the LSP is not admin down. Similarly, what happens when an LSP is moved from
> admin down to admin up when a LB instruction is in force. Is there an
> implication that transit nodes need to inspect the Admin Status flags?

Agree that we can add some description about these cases. 

Since the lock and loopback requests are originated by the ingress node, maybe we can specify that the ingress node must not send LB instruction before putting the LSP into admin down state, also must not move the lsp to admin up when the lsp is in still loopback mode?

For the transit nodes, my understanding is they could inspect the Admin Status flags to know the status of the LSP. As section 7.2 of RFC 3473 says: 

  "The Admin_Status object is used to notify each node along the path of the status of the LSP. "

> ======
> 
> idnits shows
> 
>   == Unused Reference: 'RFC4783' is defined on line 312, but no explicit
>      reference was found in the text
> 
>   == Unused Reference: 'RFC4872' is defined on line 315, but no explicit
>      reference was found in the text
> 
>   == Unused Reference: 'RFC4974' is defined on line 320, but no explicit
>      reference was found in the text
> 
>   == Unused Reference: 'RFC5852' is defined on line 324, but no explicit
>      reference was found in the text
> 

Thanks for catching this. They were referenced in a previous version. Will clean up this in a new revision. 

> 
> In 3.2 you talk about reporting the LB in the RRO on the corresponding Resv.
> What about the RRO on the Path that is forwarded downstream?

My feeling is the RRO on the Path message MAY carry this information to downstream, while this does not impact the signaling procedure of loopback.

> ---
> 
> I think that Section 5 should refer to the security considerations section of
> draft-ietf-teas-lsp-attribute-ro to pick up any concerns with the use of that
> mechanism.

Agreed. Will add the reference in a new revision. 

Many thanks,
Jie

> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas