[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt



Hi again, Lou.

[SNIP]

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].

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.

So you took out both paragraphs.
That is OK with me, but I wanted to check it's what you intended.

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.

What? Crash?

Oh, you mean drop the message and log, or send a PathErr message?
(Noting that 2205 and 3209 distinguish situations for both options.)

If a PathErr, what error code and error value?

Not too much to ask you to clarify?

Otherwise, thanks for all the updates.

Cheers,
Adrian