[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG Last Call on draft-ietf-ccamp-gmpls-recovery-functional-01.txt
Editors,
Working group last call has completed on this draft without any further comments (that I
saw).
I have a few nits that I'd like you to fix and then we can pass the draft on to the ADs.
Thanks,
Adrian
============
Contributors
Please update contact details
Please add a list of Contents
Section 1 - non-ASCII characters
Unless otherwise stated, all references to ôlinkö in this draft
2. Span Protection
Please left justify heading
Section 2
set of M protection links, usually cwith M <= N.
Read "with".
Section 2 - missing line break
set of M protection links, usually cwith M <= N. A failure in any of the N working
links results in traffic being switched to one of the
2.1 Unidirectional 1+1 dedicated protection
Please left justify heading
Section 2.1
ôDedicated 1+1ö along with the bandwidth parameters for the
Non-ASCII characters
Section 2.1
using the Link Management Protocol (LMP), or if LMP is not
Please add reference for LMP (and in other places in the draft).
Section 2.2
Suppose an LSP is routed over link i between two nodes A and B.
Please state "a bi-directional LSP"
2.3 Dedicated 1:1 protection with Extra Traffic
Please left justify heading
Section 2.3
of the nodes, A or B. This node is referred to as the ômasterö. The other node is
called the ôslaveö. The determination of the master and the slave may be based on
configured information or protocol
Non-ASCII characters (two places)
Section 2.3 - missing line break
of the nodes, A or B. This node is referred to as the ômasterö. The other node is
called the ôslaveö. The determination of the master and the slave may be based on
configured information or protocol
Section 2.3
Traffic(i.e.,the traffic is dropped by the slave and not
Insert space "Traffic (i.e."
Section 2.3
Please add text to introduce the bullets beginning...
o Pre-emption MUST be supported to accommodate Extra
Traffic.
2.6 Messages
You say that these messages MUST be transmitted reliably.
You must, therefore, say what action is taken when such a
message fails to be delivered.
3.0 End-to-End (Path) Protection and Restoration
Read "3. End-to-End..."
Section 3.
tend protection schemes and the functional steps needed to implement
Read "to-end"
Section 3.2
o Switchover: The action when an end node detects a failure
See my comments on the terminology draft. This usage is consistent with what I would like
to see (namely "switchover"), but is inconsistent with the current terminology draft.
Section 3.2
At the same time, send a switchover
request message to the other end node to enable switching
at the other end.
There is no subject of this sentence.
Ditto in the subsequent bullet.
3.1 Unidirectional 1+1 Protection
In the bi-directional case you point out that there are two distinct
failure detection cases. The case of detection by an intermediate
node gives rise to the requirement for signaling with an End-to-End
Failure Indication Message.
Why is this not a requirement in the unidirectional case?
Section 3.2.1
You don't say (but I know you have discovered in the solution draft)
that there is a correlation requirement between working and protection
LSP Identifiers. As you go on to place requirements on nodal information
in the next section, it would be worth clarifying the requirements on
LSP Identifiers.
Section 3.2.2
Each node that is on the working or protection path of an LSP must
have knowledge of the LSP identifier as well as the previous and
next nodes in the LSP. This is so that restoration-related messages
may be forwarded properly.
I don't see this requirement for end-to-end restoration.
It would appear only to be the case that *some* forwarding mechanism exists.
3.2.4 End-to-End Failure Acknowledge Message
This message is sent by the source node in response to an End-to-End
failure indication message. This message is sent to the originator
of the failure indication message. The acknowledge message should be
sent for each failure indication message received. Each
intermediate node receiving the acknowledge message must forward it
towards the destination of the message.
It is not clear from this text what the purpose of this message is. If it is solely to
acknowledge the End-to-End Failure Indication Message, then you need to add a caveat that
this message need not be used when either
- some other means of reliable delivery of the Failure Message is used
or
- some other means of failure indication is used.
3.2.6 End-to-End Switchover Response Message
Please make it clear that this message may convey a positive or negative outcome.
Section 3.3
signaling draft describes different type of switches [GMPLS_SIG]).
Read "[GMPLS-SIG]"
3.3.1 End-to-End Failure Indication and Acknowledgement
As per 3.2.3 and 3.2.4, you need to clarify that there is no requirement that these
messages flow along the path of the LSP.
As per my comment for 3.2.4, you need to clarify the purpose of the Acknowledgement
message.
Section 3.3
Nowhere in this section do you describe how the resources of the broken primary LSP may
become available for use by other LSPs (extra traffic or shared mesh protection) once the
traffic has been switched off the primary (but not necessarily before it has been switched
onto the protection LSP).
Section 4
working path remains allocated to the LSP that was originally routed
over it even after a failure. It is
important to have mechanisms that allow reversion to be performed
with minimal service disruption to the customer. This can be
achieved using a ôbridge-and-switchö approach (often referred to as
make-before-break).
The basic steps involved in bridge-and-switch are:
1. The source node commences the process by ôbridgingö the signal onto both
the working and the protection paths (or links in the
case of span protection).
Line under-flow
Non-ASCII characters
Line over-flow
Line over-flow
Section 4
5. Upon receipt of this message, the destination stops
transmitting along the protection path and de-activates the LSP
along this path. The de-activation procedure should remove the
cross-LSPs along the protection path (and frees the resources
to be used for restoring other failures.
For "cross-LSP" read "cross-connections"?
Section 4
to force a switchover (from working to protect or vice versa), and
Read "protection"
Section 4
working to protect administratively. These administrative conditions
Ditto
Security Considerations
It would be appropriate to write some material on the consequences to
security of protection schemes. For example, the consequences of badly
applied protection may increase the risk of misconnection. In particular
when extra traffic is involved, it is easily possible to deliver the
wrong traffic to the wrong place.
Similarly, an intrusion that sets up what appears to be a valid
protection LSP and then causes a fault may be able to divert traffic.
It is the place of this type of draft to guide the security behavior of
the solutions drafts that will follow.
6. Author's Addresses
Read "Authors' Addresses"
Update as required
7. Intellectual Property Considerations
Please use new boilerplate
Copyright
Please use the new boilerplate.
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Thursday, March 04, 2004 12:23 PM
Subject: Last call on Protection and Restoration Design Team drafts
> As discussed in the CCAMP meeting today, the Protection and Restoration Design Team
drafts
> have been around and stable for a long time.
>
> The terminology draft (draft-ietf-ccamp-gmpls-recovery-terminology-03.txt) is marked as
> standards track, but clearly does not require an implementation.
>
> The Functional Analysis draft (draft-ietf-ccamp-gmpls-recovery-functional-01.txt) is
> neither marked as informational nor standards track - perhaps the editors would like to
> fix this as a last call comment. Nevertheless, this is clearly not aimed at having an
> implementation.
>
> The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-02.txt) is
> informational and does not need an implementation.
>
>
> This email begins a working group last call on
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
> draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
> draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian
>
>
>
>