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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Lou, Adrian, 

Thanks a lot for your suggestions. We will revise the document following your guidance and submit a new revision soon. 

Best regards,
Jie

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Thursday, January 08, 2015 12:59 AM
> To: [e-mail]; Dongjie (Jimmy); [e-mail]
> Cc: [e-mail]
> Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb
> 
> [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