[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt
See in-line response below.
On 2/18/2009 4:50 PM, Adrian Farrel wrote:
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.
sure - definitely a major issue ;-)
===
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
they've moved already, the line should have been dropped when
[GMPLS-EXT] was split out.
===
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.
yes on the above.
===
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.
I think the primary value is providing the operator/carrier with
additional OAM information on the LSP.
2. Draft 4420-bis (now RFC 5420) does not mention this object
and it is not appropriate to reference it for processing rules.
Looks like a broken reference to me, (wrong attributes object) should be
[GMPLS-MRN].
===
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?
the line will be removed - someone else commented on this too.
===
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?
sigh. how about:
OLD:
In the context of
Ethernet connections, a call only exists when one or more LSPs
(connections in [RFC4974] terms) are present.
NEW:
In the context of
Ethernet connections, a call only is only established when one or more LSPs
(connections in [RFC4974] terms) are needed.
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?
great catch, it should be 3.
===
Section 2.3.1
Don't you think IL2CP and EL2CP need to be under IANA's control?
not at this point as current usage is per [MEF10.1] and 8011 and is
unlikely to change. We can always revisit this if/when there ever is a
need for more code point assignments.
===
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?
what you always do you in RSVP when there's a malformed message.
===
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]
done.
===
Section 4
Parameter Value
-------------- -----
Switching Type TBD [NOTE: under discussion]
Time to complete that discussion?
;-)
now says:
Switching Type EVPL [This document] (TBA by IANA)
(suggest value of 45)
===
Section 4.1 para 1
s/requires/require/
thanks.
===
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.)
I'll take a pass at it.
===
References will need updating.
idnits will help you identify what needs doing.
yup.
Thanks again for the detailed review!
Lou