Also TFS
***CP: Sub-Type 9 has been deprecated in favor of 10 (and renamed to
***CP: `"FEC 128" Pseudowire'), and sub-Type 11 ("FEC 129"
Pseudowire)
***CP: is also significant.
TDN: I modified the text as follows:
The LSP Ping header must be used as described [LSP-PING] and MUST
also contain the sub-TLV of 8 for the L2 VPN endpoint or 9 or 10
for "FEC 128 Pseudowire" or 11 for the "FEC 128 Pseudowire".
The sub-TLV indicates the PW to be verified.
---
5.2. Bidirectional Forwarding Detection
When one of the PEs (PE2) doesn't receive control messages
from PE1
during the specified amount of time it declares that the PW in
the
direction from PE2 to PE1 is down.
***CP: Should be "in the direction from PE1 to PE2 is
down" (reversed).
TDN: Ok, fixed to:
When one of the PEs (PE2) doesn't receive control messages from
PE1
during the specified amount of time it declares that the PW in the
direction from PE2 to PE1 is down. It stores the cause
(e.g., Diagnostic code 1 - control detection time expired) and
sends a message to PE1 containing this diagnostic code.
This causes PE1 to declare the PW in the direction from PE1 to PE2
is down and it stores as cause: neighbor signaled session down.
Depending on the emulated services, PE2 may send a
forward direction indication (FDI) indication on its attachment
circuits and PE1 may send an RDI indication on its attachment
circuits [OAM-MAP].
---
5.2. Bidirectional Forwarding Detection
session down. Depending on the emulated services, PE2 may send a
forward direction indication (FDI) indication on its attachment
***CP: Redundant "indication".
TDN: OK.
---
6. OAM Capability Indication for PWs Demultiplexed using MPLS
When LDP is used as the PW signaling protocol the requesting
PE indi-
cates its configured VCCV capability or capabilities to the
remote PE
by including the VCCV parameter with appropriate options
indicating
which methods of OAM it supports in the interface parameter
field of
the PW ID FEC TLV (FEC 128) or in the interface parameter TLV
of the
Genralized PW ID FEC TLV (FEC 129). The requesting PE MAY
indicate
***CP: Should change `interface parameter field' with sub-TLV.
TDN: OK.
---
6.1. Optional VCCV Parameter
[PWE3CONTROL] defines an Interface Parameter field in the LDP
PW ID
FEC (FEC 128) and an Interface Parameters TLV in the LDP
Generalized
...
field. If FEC 128 is used the VCCV parameter field is carried
in the
Interface Parameters field. If FEC 129 is used it is carried as a
***CP: Interface Parameter sub-TLV.
TDN: OK.
---
6.1. Optional VCCV Parameter
The Control Channel (CC Types) type field defines a bitmask
used to
indicate the type of control channel(s) (i.e.: none, one or both)
***CP: "none, one or more" (instead of "both"), since there's
more than
***CP: two now.
TDN: OK.
---
7. VCCV Control Channel for L2TPv3/IP PSN
***CP: This section for L2TPv3 as demux does not seem to specify a
***CP: associated channel, but instead a VCCV-only channel, since
***CP: there's no ACH with a PID. That is, uses the same L2SS format
***CP: when V=1 (instead of an ACH). If this is the intention,
it should
***CP: define how to use the `Sequence #' field in the Default L2SS.
---
7.1. L2TPv3 VCCV Message
The VCCV message MUST contain a VCCV AVP. It does not contain
a mes-
sage header. This could either be a new VCCV ICMP Ping AVP or
VCCV
BFD AVP. The usage of the L2TPv3 AVP format leaves room for
adding
further AVPs to this message in the future as needed.
***CP: Some clarifications may be needed here with the use and
***CP: definition of AVPs, since AVPs are defined in the context of
***CP: L2TPv3 control messages. i.e., what's the relationship
between
***CP: the newly defined AVPs (ICMP, BFD) and L2TPv3 control
messages.
***CP: Which Name/number space do these belong to?
---
7.1.1. L2TPv3 VCCV ICMP Ping AVP
This AVP may be
followed by the L2TPv3 Remote End Identifier AVP to identify
the PW
associated with the session.
...
7.1.2. L2TPv3 VCCV BFD AVP
The L2TPv3 VCCV BFD AVP may be followed by the L2TPv3 Remote End
Identifier AVP to identify the PW associated with the session.
***CP: The incoming Session ID provides context to identify the PW.
***CP: However, including only the Remote End ID AVP optionally
does not
***CP: catch all problems. It does catch Demux/PW-ID
inconsistencies.
***CP: But what if for example the Remote End ID AVP maps to the
Session
***CP: ID received, but there is a mismatch in the PW Type? It
seems all
***CP: AVPs that define the PW should be included as well (as the
"FEC
***CP: 128" TFS in MPLS-PING includes both IP addresses and PW
Type).
---
7.1.1. L2TPv3 VCCV ICMP Ping AVP
...
7.1.2. L2TPv3 VCCV BFD AVP
***CP: It seems some guidelines as far as how to respond in some
cases
***CP: are missing. For example, what if there is a mismatch
between the
***CP: Remote End ID AVP and the Session ID (mismatch in PW/session
***CP: association)? Should it just not reply (as if not
received) or
***CP: reply (as in no problem) since there's no granularity to
specify
***CP: "Return Codes". Or some other mechanism?
---
7.2.1. L2TPv3 VCCV Capability AVP
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
***CP: The separation between the two fields in the above figure is
***CP: shifted. More importantly though, it would seem it would be
***CP: useful to define CC Type bitmask here as well. Even if
there's
***CP: only one CC Type defined in this document (using the L2-
Specific
***CP: Sublayer), defining the bitmask and the L2SS bit allows for
***CP: forward-compatibility, if/when new CC Types need to be added.
---
8.1.2. CV Types
0x04 BFD
***CP: 0x04 was broken down in two in Section 6.1, and that
should be
***CP: reflected in IANA section.
---
TDN: I am going to let Rahul look at the above L2TP questions.
9. Security Considerations
An intruder may impersonate an LDP peer in order to
force a failure and reconnection of the TCP connection, but
where the intruder sets the Recovery Time to 0 on
reconnection.
An intruder could intercept the traffic between LDP or
peers and override the setting of the TCP Recovery Time to
be set to 0.
***CP: These two paragraph seem from LDP GR.
TDN: I reworked the text to the following:
An intruder may impersonate an LDP peer in order to
force a failure and reconnection of the TCP connection.
Please see the Security Considerations section of
[RFC3036] details.
--Tom
Thanks,
--Carlos.
Circa 9/28/2005 3:11 AM, Stewart Bryant said the following:
This is the start of a two week last call for
Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-07.txt
Last call will end at 9AM UK on Wednesday 12th October.
- Stewart
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
--
--Carlos.
Escalation RTP - cisco Systems
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3