1 Mar 2007 03:35
Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
Pandian, Vijay <Vijay.Pandian <at> sycamorenet.com>
2007-03-01 02:35:38 GMT
2007-03-01 02:35:38 GMT
Hi,
In section 4.2
Technology Specific Bandwidth Accounting, it says:
In the
ASON context, accounting on per timeslot basis using 32-bit
tuples of the form <signal_type (8 bits); number of unallocated
timeslots (24 bits)> may optionally be incorporated in the
technology specific field of the ISCD TE link attribute when the
switching capability field is set to TDM value. When included,
format and encoding MUST follow the rules defined in [RFC4202].
tuples of the form <signal_type (8 bits); number of unallocated
timeslots (24 bits)> may optionally be incorporated in the
technology specific field of the ISCD TE link attribute when the
switching capability field is set to TDM value. When included,
format and encoding MUST follow the rules defined in [RFC4202].
The signal types
as defined in RFC4606 Section 2.1
covers a basic set. The
signal type is used in conjunction with the other attributes like RCC, NCC,
etc., to determine other Elementary Signal such as STS-12c SPE, STS-48c SPE, STS-192c SPE
etc.
It is not clear to me how this 8-bit filed could be used to cover all
the different types of signal types.
Thanks and best regards,
Vijay
> The killer is:
> Mechanisms described in [6] should be
> re-examined and may need to be altered to define new security
> associations based on receiver's IP address instead of the sending
> and receiving interfaces.
>
> I think that if you say that the re-examination is needed, you must do it.
> You need to satisfy yourself as to whether any changes (beyond those
> expressed in RFC4206) are needed.
>
> My view is that you should be able to echo the text of RFC4206 without
> needing anything further. This is because the relationship between the
> end-points of the S-LSP is the same as that between the end points of the
> H-LSP in RFC4206. The precedent for remote signaling adjacencies has
> already been established, and you are not defining anything new.
Security section re-written as follows:
From a security point of view, the changes introduced in this
document model the changes introduced by [2]. That is, the control
interface over which RSVP messages are sent or received need not be
the same as the data interface which the message identifies for
switching traffic. But the capability for this function was
introduced in [4] to support the concept of out-of-fiber control
channels, so there is nothing new in this concept for signaling or
security.
The application of this facility means that the "sending interface"
or "receiving interface" may change as routing changes. So, these
interfaces cannot be used to establish security association between
neighbors, and security associations MUST be bound to the
communicating neighbors themselves.
[6] provides a solution to this issue: in Section 2.1, under "Key
Identifier", an IP address is a valid identifier for the sending (and
by analogy, receiving) interface. Since RSVP messages for a given
LSP are sent to an IP address that identifies the next/previous hop
for the LSP, one can replace all occurrences of 'sending [receiving]
interface' with 'receiver's [sender's] IP address' (respectively).
For example, in Section 4, third paragraph, instead of:
"Each sender SHOULD have distinct security associations (and keys)
per secured sending interface (or LIH). ... At the sender,
security association selection is based on the interface through
which the message is sent."
it should read:
"Each sender SHOULD have distinct security associations (and keys)
per secured receiver's IP address. ... At the sender, security
association selection is based on the IP address to which the
message is sent."
Thus the mechanisms of [6] can be used unchanged to establish
security associations between control plane neighbors.
This document allows the IP destination address of Path and PathTear
messages to be the IP address of a nexthop node (receiver's address)
instead of the RSVP session destination address. This means that the
use of the IPsec Authentication Header (AH) (ruled out in [6] because
RSVP messages were encapsulated in IP packets addressed to the
ultimate destination of the Path or PathTear messages) is now
perfectly applicable, and standard IPsec procedures can be used to
secure the message exchanges.
An analysis of GMPLS security issues can be found in [16].
> ===
>
> IANA considerations
>
> It would be helpful to name the sub-registries to help IANA get these
> allocations right.
>
> In section 7.1 the registry is "RSVP TE Parameters" (not the registry
> quoted in section 7) and the sub-registry is "Attributes Flags"
>
> In section 7.2 the registry is "Resource ReSerVation Protocol (RSVP)
> Parameters" and the sub-registry is "Error Codes and Globally-Defined
> Error Value Sub-Codes"
Done.
> It is also helpful to supply the precise text you would like added to the
> registry.
>
> For section 7.1:
>
> Path Resv RRO
> Bit Name message message sub-object
> Reference
> ---- ------------------------------- -------- -------- ---------- ---------
> 5 LSP stitching desired bit Yes No Yes
> [This doc]
>
>
> For section 7.2:
>
> 24 Routing Problem [RFC3209]
>
> 23 = Stitching unsupported [This doc]
Done.
> ===
RSS Feed