Re: Stitching and inter-domain signaling

[Arthi Ayyangar <arthi@juniper.net>]

Hi Adrian,


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

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

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

> Otherwise, I know there are a lot of people who would like to do it (not
> 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

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