[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL
Hi Carlos,
Please see inline:
[snipped]
>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.
The sequence number field is used as defined in [L2TPv3]. Will clarify
this.
>
> 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?
>
ICMP Ping AVP and BFD AVP belong to the L2TPv3 AVP number space. Will
clarify this explicitly in the IANA section.
> ---
>
> 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).
>
Will add the PW Type AVP.
> ---
>
> 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?
>
This is the same issue as the case when periodic LSP-Ping messages are
used with BFD for BFD over MPLS PWs. If there is a failure in processing
the LSP-Ping message [eg a mismatch between the FEC and the data plane
state], a LSP-Ping error is generated. In the L2TPv3 case a L2TPv3 error
is generated as specified in [L2TPv3].
Text can be added to say:
"L2TPv3 AVPs that identify a PW are processed as defined in [L2TPv3]."
> ---
>
> 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.
ok.
> 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.
>
ok.
Thanks for the comments.
rahul
> ---
>
> 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.
>
> ---
>
> 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.
>
> 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