Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt

[Lou Berger <lberger@labn.net>]

Adrian,
        Please see below.

At 03:58 PM 4/24/2008, Adrian Farrel wrote:
> Hi Lou,
>
> > > ===
> > > I struggled to see the utility of the Upstream_TSpec and 
> > > Upstream_Adspec objects. By the time these objects are used (on 
> > > the Resv) the reservation has already been made using the 
> > > Upstream_Flowspec (on the Path message).
>
> [SNIP]
>
> I think I found the "exactly the same" description a little strong. 
> But given our discussion (snipped) I think we are agreed on the usage.
>
> The only thing I find missing from the I-D might be expressed as...
>
> "When an egress receives an Upstream-Flowspec object, it responds 
> with an Upstream-TSpec for describe the traffic flow that it will 
> originate. When that Upstream-TSpec is received by the ingress, it 
> may determine that the original reservation is not sufficient to 
> satisfy the traffic flow. In this case it will issue a new Path 
> message with an updated Upstream-Flowspec object to mnodify the 
> resources reserved for the upstream traffic flow. This might also 
> require that the LSP is re-routed, and in extreme cases might result 
> in the LSP being torn down if sufficient resources are not available."

Added to section 2.2.1.

> > > ===
> > > I believe it would be helpful to indicate in the Abstract that 
> > > this is an Experimental approach, and in the Introduction to 
> > > include a whole paragraph on why this is positioned as an Experimental RFC.
> >
> > Okay have added:
> >
> >         NOTE: THIS IS AN EXPERIMENTAL RFC.
> >
> > Let us know if you'd to see anything additional.
>
> In the abstract it would be fine to simply say:
>
> "The procedures described in this document are experimental."

done

> In the Introduction, you might say:
>
> "The usage of asymmetrical bidirectional LSPs is not well developed 
> and no products have been developed yet. In consequence, the 
> procedures described in this document are experimental."

added: "the procedures described in this document are experimental."

> > > Section 1.2
> > > You have
> > >   An alternative approach was considered and
> > >   rejected.  For reference purposes only, the rejected approach is
> > >   summarized in Appendix A.
> > >
> > > Looking ahead at Appendix A, it is hard to see that this 
> > > alternative has been rejected. In fact, it says "SHOULD NOT be 
> > > implemented". Nowhere is there a definitive reason why the 
> > > alternative has been rejected (although there are a few hints in 
> > > the introduction to the Appendix).
> >
> > well it does say:
> >     This section is included for historic purposes and SHOULD NOT
> >     be implemented.
> >
> > and
> >     In summary, the "ADSPEC Object" approach presented in this
> >     section SHOULD NOT be implemented.
> >
> > This seems pretty clear to me.  What would you like it to say?
>
> Well, I've just seen an I-D bounced by the IESG because it uses 
> "SHOULD" without explaining why you might actually do it. That is, 
> there is a claim that in 2119 language "SHOULD" implies that there 
> might be good reasons to deviate, so there needs to be text to 
> describe how the deviation is handled and why it might be introduced.
>
> Curiously, NOT RECOMMENDED would mean the same thing, but might be 
> more acceptable.

NOT RECOMMENDED it is.

> [SNIP]
>
> > I've changed the sec. 1.2. text to read "An alternative approach 
> > was considered and rejected in favor of the more generic approach 
> > presented below." and to A.1. "In particular this approach is 
> > technology specific; it uses the ADSPEC object to carry traffic 
> > parameters for upstream data and requires MEF Ethernet Traffic 
> > Parameter while the approach presented above is suitable for use 
> > with any technology."
>
> That's good.
> Thanks.
>
> > > ===
> > > Section 2.1.1
> > > You suggest using "Routing problem/MPLS label allocation failure"
> > > Are you sure you do not want to be able to tell whether it was the 
> > > upstream or downstream resources that failed? Since these can be 
> > > varied independently, it would surely be useful to know which failed.
> >
> > I don't have a strong opinion one way or another.
>
> Me neither.
> We could ask the implementers :-)
>
> > > Section 2.3.1
> > > I think you need to clarify whether the Upstream_Adspec reports 
> > > the available upstream resources before or after the reservation 
> > > for the LSP in hand.
> >
> > >  Note that Adspec would apply before the reservation.
> >
> > This may be true on the initial path, but it isn't actually stated 
> > anywhere.  Furthermore, the information may include an LSPs 
> > reservation even in the case where it is not yet made.  e.g., 
> > RFC2212 talks in terms of reporting what the "flow might 
> > experience" which implies that the full Tspec is accounted for in 
> > the initial ADSPEC.
> >
> > So I think, like 2210, this should not be mentioned.
>
> OK
>
> > > ===
> > > Section 4
> > > You have...
> > >   The error message
> > >   will propagate to the ingress which can then take action to avoid the
> > >   path with the incompatible node, or may simply terminate the session.
> > > I think you need a little more care with the behavior for unknown 
> > > object on a Resv since that error will propagate to the egress.
> >
> > This can only happen from a non-conformant implementation, i.e., 
> > one that passes a new object in the path but then rejects it in the resv.
>
> Or a node that has to handle a non-conformant node that generates an 
> Upstream-TSpec when it did not receive an Upstream-Flowspec.
>
> But let's leave it.

great.  Thanks for the comments!

Lou

> Thanks for the work.
> Adrian