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

["Adrian Farrel" <adrian@olddog.co.uk>]

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

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

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

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

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

Thanks for the work.
Adrian