Subject: Stitching and inter-domain signaling

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Dec 2004 15:54:27 -0000

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

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 16 Dec 2004 11:38:21 -0800 (PST)

Hi Adrian,

> Section 3.2 currently only describes stitching of packet LSPs.
-------> Are you sure you read the 01 version ? Because the 00 version is
the one that only talks about 'stitching of packet LSPs' and only talks
about inter-domain LSPs wrt stitching. These issues have mostly been
addressed in the 01 version.

Further,
> stitching in the context of CCAMP.
-------> I think we do spell out in the draft that any node (not just a
domain boundary node) may use stitching or nesting....although in the
document we may refer to the "inner LSP" as an inter-domain LSP in most
places.

> LSPs may be established, but stitched in the data plane.
------> Sure, we agreed that it is a useful concept and applicable to
other areas besides inter-domain TE and also applicable to non-packet
LSPs, and hence the changes were made to the 01 version.

> me know ASAP whether (and when!) you will be able to work on this draft.
------> We will come up with a separate draft for stitching, if that is
what is prefered by the WG. We will propose a date once JP and I have had
a chance to sync up on this.

> a threat - just a subtle hint!).
-------> Thanks for clarifying it explicitly. :-)

I will not reply to your following comments right now, since I am tending
to believe that you have looked at the older version of the draft; e.g.
the new draft does not even have a section 2.3 that you mention below. :-)
Nevertheless, I will  take your comments into account (where applicable),
when the changes are made for the next revision

I will send out a separate mail with a proposed date for the stitching
doc.

thanks,
-arthi

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Dec 2004 19:30:09 -0000

> addressed in the 01 version.

Oh pooh!
Too many drafts. Too much to review :-(

Sorry,
I'll try again with the right version of the document.

A