[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt
Hi,
A few comments. I think some of these qualify as issues.
Thanks,
Adrian
===
IPR boilerplate
===
Abstract
OLD
Specifically, switching in support of Ethernet private
line service and Ethernet virtual private line service.
NEW-EITHER
Specifically, switching in support of the Ethernet private
line service and the Ethernet virtual private line service.
NEW-OR
Specifically, switching in support of Ethernet private
line services and Ethernet virtual private line services.
===
Abstract
Some of the
extensions defined in this document are generic in nature and not
specific to Ethernet.
It is good that you have this statement.
I think you should split it to a separate paragraph and include a hint as to
which extensions you are referring to. That is, which functions/features. Or
have they all moved out to draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt
===
Section 1.1
s/Support for P2P and MP2MP service is/Support for P2P and MP2MP services
is/
===
Section 2 para 2
s/is not modified/are not modified/
===
Section 2.1 para 2
long identifiers
are carried in the attributes object
Please clarify. The CALL_ATTRIBUTES object.
===
Section 2.1 para 2
As with the long call ID, the
Ethernet endpoint identifier is typically only relevant at the
ingress and egress nodes.
===
Section 2.1.1.1
A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be
included in the signaling messages of an LSP (connection) associated
with an established call. Such objects are processed according to
[4420BIS].
As per our (elongated) discussion for the MLN extensions. I don't see the
value of including this object in a connection signaling message, and I see
some significant dangers (including a breach in the "need to know" policy
for the distribution of information within the Internet).
But I have two issues with this paragraph.
1. You say "MAY be included", but nowhere in the spec do you
say why or what it might be used for. We are not in the habit of
defining mechanisms on the chance that they will be valuable at
some time in the future. If you have a specific use in mind, please
state it. Otherwise, we should delete this paragraph and let new
documents vary the rules when/if a use is found.
2. Draft 4420-bis (now RFC 5420) does not mention this object
and it is not appropriate to reference it for processing rules.
===
Section 2.1.1.1
Transit nodes supporting this document MUST propagate the Endpoint ID
TLV without modification.
Are you sure this is what you want?
Isn't it the case that endpoint identifiers could be mapped at UNI and E-NNI
reference points?
===
Section 2.2
Signaling for Ethernet connections follows the procedures defined in
[RFC4974].
I wouldn't say that RFC 4974 was the normative reference for setting up LSPs
of any sort.
===
Section 2.2
In the context of Ethernet
connections, a call only exists when one or more LSPs (connections in
[RFC4974] terms) are present. An LSP will always be established
within the context of a call and, typically, only one LSP will be
used per call.
This seems to be contradictory.
How can the LSP be "established within the context of a call" if the call
"can only exist when one or more LSPs are present"?
But RFC 4974 explicitly states (section 6.1)...
Note that a Call MUST NOT be imposed upon a Connection that is
already established.
In fact, 2.2.1 says:
When establishing an Ethernet connection the initiator MUST first
establish a Call per the procedures defined in [RFC4974].
So what is section 2.2 trying to say?
Would it be helpful to show the formal relationship between:
- Ethernet (virtual) connection
- GMPLS call
- GMPLS LSP == connection == Ethernet LSP
- EVPL connection
I think there is some real confusion because the LSP is switching Ethernet
and is a connection. But it is not your "Ethernet (virtual) connection".
For example, in section 2.3...
Ethernet connections established according to this document MUST use
the traffic parameters defined in [ETH-TRAFFIC] in the FLOWSPEC and
TSPEC objects.
But this should be "Ethernet LSPs" I think.
===
Section 2.3.1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IL2CP | EL2CP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [ETH-TRAFFIC] for a description of the Type and Length fields.
Per [ETH-TRAFFIC], the Type field MUST be set to two (2)
Hmmm. Presumably 3 == 2 for the purpose of this document?
===
Section 2.3.1
Don't you think IL2CP and EL2CP need to be under IANA's control?
===
Section 2.3.1
Ethernet connections established according to this document MUST
include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried
in the FLOWSPEC and TSPEC objects.
What do I do if the TLV is not there in each case?
===
Section 3
s/services./service./
===
Section 3.1
Would it be possible to change
OLD
EPL Service LSP Encoding Type
----------- -----------------
Type 1/MEF Ethernet (2) [RFC3471]
Type 2 Line (e.g., 8B/10B) (TBA by IANA)
NEW
EPL Service LSP Encoding Type Value Reference
----------- ------------------- ---------------- ---------------
Type 1/MEF Ethernet 2 [RFC3471]
Type 2 Line (e.g., 8B/10B) 14 (TBA by IANA) [This document]
===
Section 4
Parameter Value
-------------- -----
Switching Type TBD [NOTE: under discussion]
Time to complete that discussion?
===
Section 4.1 para 1
s/requires/require/
===
Section 4.2
Per [MEF6], the mapping of the single VLAN ID used at the incoming
interface of the ingress to a different VLAN ID at the outgoing
interface at the egress UNI is allowed for EVPL services that do not
support either bundling and VLAN ID preservation.
Stack hit heap trying to parse this!
How about...
If an EVPL service supports neither bundling nor VLAN ID
preservation, then [MEF6] allows mapping of VLAN IDs. The VLAN ID
used at the incoming interface of the ingress UNI-C may be different
from the VLAN ID at the outgoing interface of the egress UNI-C.
(Although I wonder if UNI-N is actually what is meant.)
===
References will need updating.
idnits will help you identify what needs doing.
===