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

[Lou Berger <[e-mail]>]

[resend]

Adrian (all),

On 1/6/2015 7:43 AM, Adrian Farrel wrote:
> Hi Jie,
>
> Thanks for the prompt response.
Restoring some overly aggressive culling:

>>> 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.

>>> 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".
> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to have
> changed a bit.
>
> The WG needs to work this through (no need to involve me :-).
> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs to
> change.
> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change.

I this document is correct, and think you've identified a few issues
with draft-ietf-teas-lsp-attribute-ro (which has also been submitted for
publication) and I'll start a new thread on these.

>>> 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?
> Saying what must happen is good, and I think you already do that in the
> document.
>
>> 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. "
> Good reference. Thanks.
>
> So all you need to describe is the error cases. What does a transit node or
> egress do when the ingress screws up?
So you are asking for a new sentence in paragraph 3 of section 3.2.
Perhaps something like:
 OLD
   On receipt of this Path message, the target LSR of the loopback
   request SHOULD try to put the LSP into loopback mode.  If the node
   puts the LSP into loopback mode successfully, it MUST set the
NEW
   On receipt of this Path message, the target node of the loopback
   request MUST check if the LSP is in lock mode by verifying that the
   Administratively down (A) bit is set in the ADMIN_STATUS object.
   If the bit is not set, the loopback request MUST be ignored.  If the
   bit is set the node
   SHOULD try to put the LSP into loopback mode.  If the node
   puts the LSP into loopback mode successfully, it MUST set the

>
>>> 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.
> Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me. You need
> to decide and document.

How about:
OLD
   If the node
   puts the LSP into loopback mode successfully, it MUST set the
   Loopback (B) bit in the Record Route Object (RRO) Attribute subobject
   [RFC5420] and push this subobject onto the RRO object in the
   corresponding Resv message.
NEW
   If the node
   puts the LSP into loopback mode successfully, it MUST set the
   Loopback (B) bit if it adds, per [RFC5420], an Attribute subobject
   to the RECORD_ROUTE object of a Path or Resv message.


> Probably, it is a SHOULD because it is information about the path.
>
> Cheers,
> Adrian
>

One additional comment of my own.  For consistency, only LSR or node
should be used -- they are currently used about equally.  I suggest
replacing "LSR" with "node" .  (Sorry, I thought we did this for this
document already, but clearly I missed this due too much eggnog.)

Thanks,
Lou