Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt

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

Hi Dimitri,

> > Abstract:
> >    This document describes protocol specific procedures and extensions
> >    for Generalized Multi-Protocol Label Switching (GMPLS) Resource
> >    ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to
> >    support end-to-end Label Switched Path (LSP) recovery that denotes
> >    protection and restoration.
> > Not sure what is meant by "denotes" in this context.
> > Perhaps "is used to provide" ?
>
> -> was meant to say "that means..." - so any better wording ?

OK...
"...to support end-to-end Label Switched Path (LSP) recovery, that is
protection and restoration of end-to-end LSPs."

> > ===
> > Section 3
> > Although the second paragraph defines "end-to-end protection" I would
like to see this pulled out into its own paragraph for emphasis, and also
a little more clarity added to the definition. For example, it would
appear that your four types of e2e protection are all have the protecting
and protected LSPs disjoint in some way - this makes it appear that this
is a property of e2e protection in general and you should state this if it
is true.
>
> -> so you would like to see as part of the introduction a statement
> about end-to-end protection concept - i don't think there is any
> specific issue in adding this

OK. Thanks. I don't need a whole essay; just a short paragraph.

> > ===
> > Section 3
> >    Note that in both
> >    cases, any lower priority LSP that would use the pre-reserved
> >    resources for the protecting LSP(s) MUST be preempted during the
> >    activation of the protecting LSP.
> > This sentence comes out of the blue. The whole of the paragraph up to
then has not even mentioned extra traffic.
>
> -> don't understand your comment as it is mentioned at the beginning of
> the paragraph

OK. It's a long paragraph with a page throw in the middle. I guess I fell
asleep by the time I got to the end of the paragraph!

> > ===
> > Section 4.2.1
> >    - S (Secondary) bit: enables distinction between primary and
> >      secondary LSPs. A primary LSP is a fully established LSP for
> >      which the resource allocation has been committed at the data
plane
> >      (i.e. full cross-connection has been performed). Both working and
> >      protecting LSPs can be primary LSPs. A secondary LSP is an LSP
> > I am uneasy about this definition of "primary". In [TERM] the only
mention of "primary" is in section 2...
> >    Recovery typically involves the activation of a recovery (or
> >    alternate) LSP when a failure is encountered in the working (or
> >    primary) LSP.
>
> -> this definition needs to be updated as - by removing primary in the
> second parenthesis - it comes from a initial phase where no solution
> where yet started

OK. So please make sure that this happens during RFC Ed or authors 48
hours on [TERM].

> > This implies that "primary" is a synonym for "working".
> > Further, RFC3471 has a subtly different meaning for "secondary" in
section 7.
> >    Protection Information also indicates if the LSP is a primary or
> >    secondary LSP.  A secondary LSP is a backup to a primary LSP.  The
> >    resources of a secondary LSP are not used until the primary LSP
> >    fails.  The resources allocated for a secondary LSP MAY be used by
> >    other LSPs until the primary LSP fails over to the secondary LSP.
At
> >    that point, any LSP that is using the resources for the secondary
LSP
> >    MUST be preempted.
> > Can we please not modify the interpretation of the S-bit.
>
> -> this is what the draft does as also explained in
>
> "   In this document, the PROTECTION object uses as a basis the
>     PROTECTION object defined in [RFC3471] and [RFC3473] and defines
>     additional fields within it. The fields defined in [RFC3471] and
>     [RFC3473] are unchanged by this memo. "
>
> > If you need to flag a new piece of information (to distinguish between
resource allocated and not) then please introduce a new flag.
> > Note that the P-bit appears to be slightly orthogonal because the text
seems to describe the *current* role of the LSP. (The S-bit in RFC3471
describes the role at the time the LSP is set up, I think).
>
> -> note this has already been explained to you - where we came to the
> conclusion for clarity to add the above mentioned paragraph

Well, then I guess I find RFC3471 poorly drafted.

> > ===
> > Section 5
> >    When a failure occurs (say at node B) and is detected at end-node
D,
> >    the receiver at D selects the normal traffic from the other LSP.
> >    From this perspective, 1+1 unidirectional protection can be seen as
> >    an uncoordinated protection switching mechanism acting
independently
> >    at both end-points. Also, for the protected LSP under failure
> >    condition, the Path_State_Removed Flag of the ERROR_SPEC object
(see
> >    [RFC3473]) SHOULD NOT be set upon PathErr message generation.
> > So, what you are saying is that in 1+1 protection the network may
*never* know that the error is so bad that the LSP is dead, but MUST leave
that choice to the ingress. While this is the operational practice in many
transport networks, I don't see why you make this as strong as a SHOULD
NOT.
>
> -> what i mean is that this LSP in a 1+1 mode should not be released
> after failure (which is the common usage of such a scheme)

Agree about comon usage.
Think SHOULD NOT is too strong.
Would accept RECOMMENDED.

> > ===
> > Section 5.1
> >    A new PROTECTION object is included in the Path message. This
object
> >    carries the desired end-to-end LSP Protection Type (in this case,
> >    "1+1 Unidirectional"). This LSP Protection Type value is applicable
> >    to both uni- and bi-directional LSPs.
> > This is unclear. In section 14.1 you have
> >                 0x08    1+1 Unidirectional Protection
> >                 0x10    1+1 Bi-directional Protection
>
> -> in 5.1 "This LSP Protection Type value is applicable
>     to both uni- and bi-directional LSPs. "
>
> -> in 6.1 "This LSP Protection Type
>     value is only applicable to bi-directional LSPs.

Ah!

Very sorry. I wonder if my stupidity is also present in others.
That is (of course), the protection type uni/bi is not the same as the LSP
direction uni/bi.
And that bi protection is meaningless for a uni LSP.

Any hope of a couple of lines to avoid this confusion?

> > ===
> > Section 6.2
> >    directions. This is done using the Notify message with a new Error
> >    Code indicating "Working LSP Failure (Switchover Request)". The
> > I don't see this in the IANA section, and I wonder if you also mean
Error Value?
>
> -> it corresponds to the entry "Notify Error/LSP Failure"
> (suggested value = 6)" error value is thus appropriate

Ah. OK, then just update the text in section 6.2.

> > ===
> > Section 7.2
> >    This operation may be done using a Notify message exchange with a
> >    new Error Code indicating "(Working) LSP Failure (Switchover
> >    Request)". The Notify Ack message MUST be sent to confirm the
> >    reception of the Notify message.
> > All of the same comments as for section 6.2.
> > Also:
> > - Why do you say "may be done"?
>
> -> "initiated" or "performed"

It is the "may be" that I question. It implies there is a choice of ways
to do it.
Section 6.2 uses "this is done".

> > ===
> > Section 13 (D and E)
> >    This, unless a fault condition exists on
> > ? "This is allowed"? "This is possible"? "This is successful"?
>
> -> would you clarify what you mean here

I am suggesting meaning (and therefore replacement text) for the phrase
"This, unless a fault condition exists"

> > ===
> > Section 14.1
> > I believe we have had this discussion before.
> > We don't introduce reserved fields for future extensibility. We only
do it for padding.
> > If you are certain that we need to extend in the future then please
use sub-objects or TLVs.
> > This means that you can:
> > a. Remove the last four bytes of the Protection object.
> > b. Retain the C-Type from RFC3473
>
> -> will add a reference to segment recovery (that does not make use of
> TLVs) - see section 6.1 of SEG-REC

Suppose this is OK.
But, notwithstanding the fact that I am an author of SEG-REC, it appears
that the additional info that is defined in SEG-REC would fit within the
existing 64 bit structure. (Appologies for not reviewing that draft
first.)

> > ===
> > Section 15
> > In the case where my protecting LSP protects only one working LSP and
where the full path of the protecting LSP is known by the ingress (strict
and explicit) and there is no resource sharing between the protected and
protecting LSP, I can't see why I must include a PPRO.
> > In other words, PPRO is an enabler of function (as stated in section
15.4 "The PPRO enables of sharing recovery resources between a given
secondary protecting LSP and one or more secondary protecting LSPs if
their corresponding primary working LSPs have mutually
(link/node/SRLG)disjoint paths."), but that does not make its presence
mandatory.

No comment?

> > ===
> > Section 15.1
> >    The contents of a PRIMARY_PATH_ROUTE object are a series of
> >    variable-length data items called subobjects. The subobjects are
> >    identical to those that can constitute an EXPLICIT/RECORD ROUTE
> >    object as defined in [RFC3209], [RFC3473] and [RFC3477].
> > This seems in contradiction with section 15.3
>
> -> identical in terms of content definition

15.3 says
   The following subobjects are currently defined for the PRIMARY PATH
   ROUTE object:
   - Sub-Type 1: IPv4 Address (see [RFC3209])
   - Sub-Type 2: IPv6 Address (see [RFC3209])
   - Sub-Type 3: Label (see [RFC3473])
   - Sub-Type 4: Unnumbered Interface (see [RFC3477])
but RFC3209 defines
    32   Autonomous system number

Hence a contradiction. If you are prepared to accept type 32 in the PPRO I
suggest that you remove the list of accepted values and simply state that
anything that can go in an ERO *or* an RRO is acceptable in a PPRO.

> > ===
> > Section 17
> > Isn't Notify modified as well?
> > And I thought Resv was, but I may have been sleeping.
>
> -> Resv needs to be added (Notify is not modified)

   This section describes the extensions to the PROTECTION object to
   broaden its applicability to end-to-end LSP recovery. In addition to
   modifications to the format of the PROTECTION object, we extend its
   use so that the object can be included in the Notify message to act
   a switchover request for 1+1 bi-directional and 1:1 protection.

Looks like a modification to me.

> > ===
> > Section 19
> > The IANA section needs some gardening to make it really easy for IANA
to implement.
> > - Only have suggested values in one place in the document
>
> -> ok (do think put the proposed value as part of the text and the IANA
> section ease reading)

Don't feel strongly.
Have seen too many drafts go to RFC with mixed values or TBD still in
place.

> > ===
> > Section 19
> > Should the IANA section also cover the bits in the ADMIN STATUS
object?
>
> -> we did not register these bits since if you think we need to register
> them as part of this section just let me know

Asking your opinion, really.
Question is, what is the risk of losing track of Admin Status bits?
Note, I keep an informal registry on the alternate CCAMP pages.

Thanks for the hard work.
Adrian