Re: [L2tpext] WG last call for draft-ietf-l2tpext-tunnel-switching-05.txt

Please find some comments on draft-ietf-l2tpext-tunnel-switching-05.txt.
I hope they are useful and clear:

2. L2TPv2 to L2TPv3 switch

***CP: It would appear that there could be more to the data
***CP: encapsulation adaptation in the L2TP version switch case.
***CP: Specifically in terms of dataplane sequencing. As an example,
***CP: L2TPv3 could use Data Sequencing AVP with a value of 1 (Only
***CP: non-IP data packets require sequencing). Such cases should
***CP: probably be considered in this section.

3. AVP Behavior

   - DROPPED AVP: AVP is dropped if it was present in the incoming
   message. All the L2TPv3 only AVPs are dropped when switched onto
   L2TPv2 tunnel.

***CP: It seems not all L2TPv3-specific AVPs are dropped. Specifically,
***CP: Tx|Rx Connect Speed must be regenerated and "translated" (i.e.,
***CP: change the AVP Type) if there is a version switch as specified
***CP: already (i.e., 74 <-> 24 and 75 <-> 38)

3.1. IETF Vendor AVPs

   Framing Capabilities (SCCRQ, SCCRP) - MUST be REGENERATED.

   Bearer Capabilities (SCCRQ, SCCRP) - MUST be either REGENERATED or

***CP: Is there a need for an ordered-mode regeneration (i.e., wait for
***CP: the outbound tunnel AVP in order to generate the inbound tunnel
***CP: AVP value) for these?

   Tie Breaker (SCCRQ) - MUST be either REGENERATED or DROPPED.

***CP: Some of these AVPs have corresponding different AVPs between v2
***CP: and v3. Similar to the Tx|Rx Connect Speed AVPs, the v2 Tie
***CP: Breaker was split such that v3 has Control Connection and Session
***CP: Tiebreakers. Should there be a disctintion between "regenerated"
***CP: and "regenerated and AVP switch on version switch"? Other AVPs
***CP: that would fall in these category are Assigned Tunnel ID vs.
***CP: Assigned CC ID, Sequencing Req. vs. Data Sequencing Req.,
***CP: Assigned Session ID vs. Local Session ID.

   Host Name (SCCRP, SCCRQ) - MUST be REGENERATED.

***CP: From L2TPv3, "LCCEs are identified during control connection
***CP: establishment either by the Host Name AVP, the Router ID AVP, or
***CP: a combination of the two". It would appear that in a version
***CP: switch, a v3 tunnel could do without Host Name, so this case
***CP: could also be "regenerated or dropped if using router id in v3"?

   Control Connection DS AVP (SCCRQ, SCCRP) (Ref [4]) - MUST be either
   RELAYED if present in the inbound message or DROPPED if it's not
   supported. The value of this AVP could be chosen based on 'PHB Code'
[snip]
   Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either
   RELAYED if present in the inbound message or DROPPED if it's not
   supported. The value of this AVP could be chosen based on 'PHB Code'

***CP: Why do these MUST be relayed? I would think that different
***CP: policies in the inbound and outbound tunnels could call for using
***CP: a different DSCPs, in which case it could be "regenerated".

   Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either
   RELAYED if present in the inbound message or DROPPED if it's not
   supported. The value of this AVP could be chosen based on 'PHB Code'
   used (or to be used) on the tunnels, which the TSA is going to be

***CP: s/tunnels/sessions/

4. Loop Detection

   The TSA ID AVP, Attribute Type TBD, could be used to detect if a
   session is looping in an L2TP tunnel switched network. This AVP MUST
   be STACKED.

***CP: "could be used" or SHOULD/MAY?

   uniqueness among all the inter-connected LACs, LNSs and TSAs. If no
   value is configured then the AVP value MUST be of length 0.

***CP: In a multi-TSA environment, if a TSA ID value is not configured
***CP: in more than one TSA, then a such TSA would find a match (i.e.,
***CP: matching empty string). Maybe should clarify such a case, for
***CP: example saying that TSA ID AVP with a value of zero length MUST
***CP: NOT be used in matching, or that a match comparison MUST only be
***CP: performed if the TSA has a configured non-null TSA ID (or some
***CP: other usage guideline).

5. CDN Messages and L2TP tunnel Switching

   Upstream busy (Result Code 2, Error Code TBD) - TSA MUST generate a
   CDN message with this Error Code for the LAC, if upstream LNS
   disconnects the outgoing call with an error code 'TSA Busy' or other
   indications from upstream indicates the upstream is too busy to take

***CP: For clarification, an upstram LNS disconnecting (outgoing?) call
***CP: with `TSA Busy' implies a multi-TSA environment, right? That is,
***CP: upstream LNS must also be TSA for some further upstream LNS2.

6. IANA Considerations

   This document requires following parameters to be assigned through
   IETF Consensus [RFC 2434] as indicated in Section 5 of [1]. These
   are:

***CP: The 3 number space assignment is through Expert Review, as
***CP: specified in RFC3438 Sections 2.2 and 2.3.

7. Security Considerations

   AVP hiding, described in [1] MUST be either used to help mitigate

***CP: Extraneous `either'?

   this, though it is not widely regarded as cryptographically secure.
   [RFC 3193] describes a more robust method for securing L2TP in

***CP: Missing reference to RFC3193 in the References Section.

   general, and should be used to encrypt all L2TP messages if access to

9. References

9.1. Normative References

   [7]   RFC 1661, W. Simpson, "The Point-to-Point Protocol (PPP)", STD
         51, July 1994.

***CP: Unused reference.

9.2. Informative References

   [8]   L. Martini, M. Townsley, C. Metz, T. Nadeau, M. Duckett, V.
         Radoaca, "Pseudo Wire Switching" work in progress, draft-
         martini-pwe3-pw-switching-01.txt, October 2004.

***CP: Unused reference.

A couple of nits and global comments as well:

Status of this Memo

***CP: Need to use RFC3978/3979 boiler.

                     Figure 1:   L2TP tunnel Switching

***CP: It may be useful to identify the inbound and outbound tunnels in
***CP: the figure.

***CP: %s/TSA Id/ TSA ID/g

Thanks,

--Carlos.

Circa 7/31/2005 12:35 PM, da Silva, Ronald said the following:
> This is the last call for draft-ietf-l2tpext-tunnel-switching-05.txt.
> Please review and send comments to this list.
> 
> Last call will end August 15th, 2005.
> 
> Thanks!
> -ron
> 
> _______________________________________________
> L2tpext mailing list
> L2tpext@ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext