Stitching and inter-domain signaling

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

Hi,

Well, I just went and re-read your draft to try to decide about where
stitching lives, and I think I am a little clearer on the direction we
should take.

Section 3.2 currently only describes stitching of packet LSPs. Further,
it specifically limits itself to the stitching of an inter-domain LSP to
an intra-domain LSP. This is clearly not an adequate description of LSP
stitching in the context of CCAMP.

LSP stitching is a very useful concept in inter-domain signaling for
packet and non-packet environments and is particularly important in
non-packet environments where the domains have the same non-packet
switching capability since nesting will not be possible. Additionally,
stitching has applicability to nested domains where the interior domain
is of the same switching capability as the exterior domain - thus FA
LSPs may be established, but stitched in the data plane.

I think there is sufficient material here to justify a separate draft,
and it seems to me that the WG is slightly in favor of this split as
well.

I would like you two (Arthi and JP) to be involved in this new draft
since you have been developing the stitching concept. Please can you let
me know ASAP whether (and when!) you will be able to work on this draft.
Otherwise, I know there are a lot of people who would like to do it (not
a threat - just a subtle hint!).

If we can move forward with a stitching draft, I don't see why we can't
take the inter-domain signaling draft into the WG.

I don't think this has a large impact on your current draft. Section 3.2
will need to change as follows:
- generalize it to include non-packet LSPs
   - simply point out that stitching assumes continuity of switching
caps
- leave it with the current inter-domain to intra-domain limitation
- retain the LSP Attribute control bit (that is specifically relevant to
  your draft and not the general stitching draft)
- retain (but modify) the description of stitching behavior in the
  context of inter/intra-domain LSPs


Smaller points to fix sometime (now is good :-)

2.3 does not seem to be complete because it does not clearly explain
that in the case of a contiguous LSP the incoming boundary node *is*
allowed to look ahead in the ERO and perform full computation to the
next boundary node even if the immediate next hop is strictly specified.
This is a deviation from RFC3209 that I believe you intend to allow.

2.3 is missing a similar section for RROs.

3.1 since you are adding an option here, I think you need to explain why
it might be selected. What change in service will the head-end see as a
result of setting or clearing this bit?

3.1 bit 5 (0x10) is currently reserved for "contiguous" in my pre-IANA
file on the CCAMP web pages

3.1    indicates that a boundary LSR MUST not perform any stitching or
s/not/NOT/
(in general, please check your use of 2119 terms in the whole draft)

3.2 bit 6 (0x20) is currently reserved to "force" stitching in my
pre-IANA file on the CCAMP web pages

3.2 I think you need to clarify this text (quite a bit) because it is
very unclear what you mean by "egress".

5. It would be wise to explain that FRR is a packet technology. You need
to flag (by reference) how this form of protection is achieved in
non-packet environments.

7. The security section is a bit flaccid.

8.2 Best to refer to the error numbers by their formal names of Error
Code and Error Value.

10.1 Please move this text to the draft header and kill the reference to
RFC2026

11.1 Please try to control your normative references. Certainly things
that are referenced only from your example should not be considered
normative. Similarly, drafts that are not referenced at all seem
unlikely normative references. just shunt 'em into the informational
section.

Cheers,
Adrian