Subject: Draft response to the OIF

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Dec 2007 14:50:46 -0000

Hi,

The OIF sent us a communication (http://www.olddog.co.uk/oif2007_382_01.pdf) 
with some specific questions about the use of GMPLS protocols.

Here is a draft response. Thanks to Lou Berger for the bulk of this text.

Comments please before I send this around Christmas.

Thanks,
Adrian
===

To : Lyndon Ong, OIF TC Chair <[email-masked]>
Cc: Ross Callon, IETF Routing Area Director <[email-masked]>
    David Ward, IETF Routing Area Director <[email-masked]>

Subject: Response to Your Questions about GMPLS Protocol Usage

Dear Lyndon,

Thanks for your communication dated 29th November 2007 and your subsequent 
email exchange with clarifications.

Please find below responses from CCAMP experts to the questions you posed.

May we take this oportunity to stress that we are open to receiving such 
questions in a less formal way either directly or through the CCAMP mailing 
list, and may be able to provide timely responses during the course of your 
testing events.

> 1) One of the features provided in the OIF UNI 2.0 is the ability to
> non-disruptively modify service attributes associated with an LSP. The
> modification of the service attributes is limited to LSPs that were
> initiated using Shared Explicit filter style. Modification is performed
> by signaling a new LSP that utilizes the same Tunnel ID as the original
> LSP but with the new service parameters. Once the new LSP state is
> established, the original LSP state is removed.

There are two distinct options for modifying an LSP. The first is "in-place" 
modification where a new trigger Path message is sent for an existing LSP. 
The second is the "make-before-break" approach to tunnel/service 
modification first introduced in RFC 3209. You appear to be refering to the 
latter case since you mention a new LSP.

> Non-disruptive modification was demonstrated in the 2007
> interoperability test by modifying the bandwidth of an LSP realized by a
> SONET/SDH VCAT group. In the process of testing, a number of questions
> arose regarding the RESV message flow. These questions included:
>
> - How many RESV messages are expected to be generated? Is it one since
>   the resources in use by both LSPs are the same, or two since the LSPs
>   are handled through separate signaling sessions.

In make-before-break, each LSP is signaled independently.  Per LSP Resv 
messages should be expected.  Assuming the old LSP is in-place at the time 
of signaling the new LSP, and only one Path message is issued, then only one 
Resv would be expected. That is, a Resv for the new LSP, but no further Resv 
for the existing LSP.

When the old LSP is also modified as part of the make-before-break, e.g., to 
update administrative status prior to alarm-free tear-down, then a Resv 
message on the old LSP may also be generated.

> - What is the bandwidth amount that should be reflected in the RESV
>   messages? If separate RESV messages are generated for both LSPs, is it
>   the bandwidth requested in the corresponding PATH message? Or is it
>   the actual bandwidth being provided by the connection at the time the
>   RESV message is generated?

According to RFC 4606:

    For a particular sender in a session, the contents of the FLOWSPEC
    object received in a Resv message SHOULD be identical to the contents
    of the SENDER_TSPEC object received in the corresponding Path
    message.  If the objects do not match, a ResvErr message with a
    "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.

 Again, in make-before-break, each LSP is signaled independently.

> In the interop test both approaches were observed. To facilitate the
> subsequent demonstration, receivers were expected to handle both cases.
>
> 2) In the process of testing, we found that not all implementations
> included Explicit Route Objects (ERO) in PATH messages when performing
> graceful deletion, even though earlier PATH messages for the LSP had
> included an ERO. For some intermediate node implementations, the lack of
> the ERO was seen as removing the 'pinned' nature of the connection,
> causing the node to interpret the PATH message as requiring a new path
> computation which may end up using a different route. Other
> implementations utilized the Session and Sender Template to relate the
> received PATH message with the existing connection thereby identifying
> the path the message should be forwarded on. This approach was taken by
> these implementations since inclusion of an ERO is not mandatory. We
> would appreciate CCAMP's thoughts on what the behavior should be.

As described in RFC 2205, Path and Resv messages are idempotent.  This means 
that any Path message reflects full state, and differences between one Path 
message and a subsequent Path message may be reasonably considered an 
explicit change. Therefore, while there is no explicit requirement stated in 
RFC 3473, it is typical to only modify the Admin Status Object in Path 
messages sent in connection to RFC 3473 section 7.2.1. deletion procedures 
(i.e. to include the full ERO as on previous Path messages).

It may be observed, however, that while an implementation detecting a change 
in ERO (such as the removal of the ERO) may legitimately opt to reroute, 
that implementation should also note the change in Admin Status associated 
with the graceful deletion and may "assume" that such a reroute would be a 
waste of time. Further, in a transport system, implementaitons should only 
perform local reroutes (deviating from in-place LSPs) with extreme caution 
since these risk impacting traffic.

> 3) In the process of testing, we found cases where the update of a
> link's attributes (i.e. available capacity) was not being done by
> advertising an updated LSA using the same LSAid, but by flushing the old
> LSA followed by generation of a new LSA with a new LSAid. Since the
> LSAid for Opaque LSAs is not tied to the resource being advertised
> (i.e. the resource is identified using TLVs in the Opaque LSA, not using
> the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as
> it causes the order that the LSAs are processed to become important. We
> would appreciate CCAMP's thoughts on what the behavior should be.

The OSPF WG, is the proper WG to respond to this as they are the 
authoritative source on OSPF technology.  From our perspective, RFC 2328 
dictates the use of the same Link State ID when advertising a change in a 
link's information.  While it is certainly possible to advertise a change 
via issuing an LSA with a new Link State ID and flushing old state, from the 
perspective of OSPF this is not a change in link state, rather a completely 
new link.

> 4) Finally, in the process of testing, we found cases where established
> connections were deleted based on node restart procedures in RFC
> 3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006)
> states deletion of established connections as the result of control
> plane failure (including node restart) shall not occur. It has been
> identified this could also occur when a number of cascaded nodes restart
> at the same time. We would appreciate CCAMP's thoughts on ways to
> prevent deletion of established connections from occurring when a node
> restarts.

 Without specific details, it's impossible to address the found cases or to 
identify if they were due to implementation or specification issues.

More broadly, RFC 3473 does not require the removal of forwarding state, 
even in the case of state synchronization errors, and implementations may 
take different action (such as reporting the condition to a management 
station). An implementation at a restarting node may consider that the lack 
of control plane state at its neighbor indicates that the removal of 
forwarding plane state has been attempted through the control plane while 
the restarting node was down and should follow local policy in determining 
how to react.

We would also like to direct you to RFC 5063 and 
draft-ietf-ccamp-gr-description which may provide additional relevant 
information.

We hope this addresses your questions.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Dec 2007 14:14:52 -0000

Hi,

After some off-line emails, here is an updated draft response to 
http://www.olddog.co.uk/oif2007_382_01.pdf

The changes are in the answer to question 3)

Any further comments?

Cheers,
Adrian

===

Dear Lyndon,

According to RFC 4606:

The OSPF WG, is the proper WG to respond to this as they are the 
authoritative source on OSPF technology.  From our perspective, RFC 2328 
dictates the use of the same Link State ID when advertising a change in 
information about a link, and  RFC 3630  states "The LSA ID has no 
topological significance."

While it is certainly possible to advertise a change via issuing an LSA with 
a new Link State ID and flushing old state, from the perspective of OSPF 
this is not a change in link state, rather a completely new link.

In fact, when there are key changes to the information advertised about a 
link (for example, a change to the Link Type or Link ID), the advertising 
router should recognise that these changes represent the advertisement of a 
new link and should use a new LSA with a new Link State ID. However, where 
the change is clearly a change to the link state of an existing link, the 
advertising router should use the same Link State ID.

Best regards,