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

["Mahesh Kelkar" <[e-mail]>]

Carlos,

Please see my comments inline [mvk]

Thanks
Mahesh

-------- Original Message --------
Subject: 	Re: [L2tpext] WG last call for 
draft-ietf-l2tpext-tunnel-switching-05.txt
Date: 	Wed, 10 Aug 2005 14:20:10 -0400
From: 	Carlos Pignataro <[e-mail]>
Organization: 	cisco Systems, Inc.
To: 	da Silva, Ronald <[e-mail]>
CC: 	[e-mail]
References: 
<[e-mail]>


[mvk] It has occurred to us that use of keywords "outgoing" and "incoming" is conflicting. Hence we will replace them with the terms "FIRST" and "SECOND". The new terminology could be applied to all the reference models i.e. LAC-LNS-incoming, LNS-LAC-outgoing, LAC-LAC and LNS-LNS.

We will add the following statements in the terminology section:
- FIRST tunnel is the 1st tunnel established at the TSA.
- SECOND Tunnel is the 2nd tunnel established at the TSA.

The error codes in section 5 would be updated as follows:
- Next hop unreachable (Result Code 2, Error Code TBD)
- Next hop busy (Result Code 2, Error Code TBD)
- TSA busy (Result Code 2, Error Code TBD)

[mvk] FIRST and SECOND sessions are two discrete entities. The FIRST session is established in the beginning and then TSA uses the negotiated parameters of the FIRST session as a basis to negotiate the SECOND session. If the SECOND session fails to negotiate then it should be terminated. Same thing can be said for the tunnel.


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

[mvk] Thank you very much for your valuable comments. 


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.

[mvk] Yes. 

Data sequencing AVP is a L2TPV3 avp equivalent to the Sequencing required avp in L2TPv2. In v3, any endpoint (LAC or LNS i.e. LCCE) can send the Data Sequencing avp with the value 0 (no sequencing), 1 (sequencing only for non-ip packets) or 2 (sequencing for all the packets). In v2, only LAC can send the Sequencing Required AVP that requests the sequencing for all the packets.  

TSA Behavior:

1. If data sequencing is enabled on the FIRST session, then TSA should enable it on the SECOND session by sending the appropriate AVP i.e. REGENERATED

2. If data sequencing is enabled on the FIRST session, then may choose (as decided by the local policy) not to enable the sequencing on SECOND session i.e. DROPPED.

TSA should not enforce the sequencing but should send the data sequencing AVP on the SECOND session, if its enabled on the FIRST. There is not requirement to have all hops use the consistent sequencing configuration. As always TSA's local policy would take precedence over this default behavior of "REGENERATED or DROPPED"


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)

[mvk] It's not a correct statement. I will fix that. L2tpV3 avps are not dropped across the tunnel switch. FIRST and SECOND tunnel/session are two distinct entities, hence it is up to TSA to decide whether to ignore the avps negotiated on FIRST or regenerate them on SECOND.

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?

[mvk] No. SECOND tunnel is established after the establishment of FIRST tunnel. Hence, SECOND tunnel must comply with the bearer capabilities negotiated by the FIRST tunnel i.e. TSA must use the bearer capabilities negotiated by the FIRST for negotiating the SECOND. If SECOND tunnel does not comply then the tunnel should be terminated.

   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.

[mvk] Tiebreak is a per-hop entity; it does not need to be forwarded to the next hop. Defining "regenerated and AVP switch on version switch" is implied by the fact that the SECOND tunnel is L2TPv3. 
Please see comments on all the v3 avps at the bottom. 

   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"?

[mvk] Agreed. We should add the "dropped". And leave it at the TSA's discretion.

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

[mvk] Agreed. In fact we will add a statement at the beginning:
"In its default behavior TSA needs to be as transparent as possible. However, TSA shouldn't prevent local policies to override the default behavior and allow regeneration of the AVPs mentioned as '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/

[mvk] ok.

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?

[mvk] Yes. "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).

[mvk] Agreed. Do not match the TSA IDs if length is 0.

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.

[mvk] Yes. We should mention the "multi-TSA" environment in this discussion.

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.

[mvk] ok

7. Security Considerations

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

***CP: Extraneous `either'?

[mvk] ok

   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.

[mvk] ok. 

   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.

[mvk] Normative references, by definition are the references that are required to understand this document. Do we have to refer them in the document in order to include it? In that case I will add a reference to this 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.

[mvk] I read PW switching draft a couple of times to understand its applicability. Hence I decided to include the reference. What are the conditions to include an informative reference?


A couple of nits and global comments as well:

Status of this Memo

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

[mvk] Are you referring to section 5 of the 1id-guidelines.txt? It is already included. Could you please point me to the suggested boiler?

                     Figure 1:   L2TP tunnel Switching

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

[mvk] ok. I will add that.

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

[mvk] ok.

Thanks,

--Carlos.


[mvk]

All the other v3 avps

   Extended Vendor ID AVP (Version 3) (All Messages) - MUST be either 
   REGENERATED or DROPPED. 

[mvk] The scope of this avp limited to a hop. In case of v3 tunnel switching, TSA may REGENERATE or DROP it. In case of version switch, TSA will ignore it and will not forward on the SECOND v2 tunnel.

   Message Digest AVP (Version 3) (All Messages) - MUST be either 
   REGENERATED or DROPPED. 

[mvk] The scope of this avp is limited to a hop. Hidden avps are decrypted and encrypted at each hop and hence no need to relay this avp. Each TSA would use the applicable MD algorithm. In case of v3 tunnel switch, regeneration of the AVP may look like a relay.

   Router Id AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED 
   or DROPPED. 

[mvk] The scope of this avp is limited to a hop.

   Assigned Control Connection Id AVP (Version 3) (SCCRQ, SCCRP, 
   StopCCN) - MUST be either REGENERATED or DROPPED. 

[mvk] The scope of this avp is limited to a hop. We can just change it to "regenerated"

    Pseudowire Capabilities List AVP (Version 3) (SCCRQ, SCCRP) - MUST be 
    either REGENERATED or DROPPED. 

[mvk] The scope of this avp is limited to a hop (between the LAC & LNS). In case of v3 tunnel switch, regeneration of the AVP may look like a relay.

   Local Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, 
   CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED. 

[mvk] The scope of this avp is limited to a hop (between the LAC & LNS). We can just change it to "regenerated"

   Remote Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, 
   OCCN, CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED. 

[mvk] The scope of this avp is limited to a hop (between the LAC & LNS). We can just change it to "regenerated"

   Assigned Cookie AVP (Version 3) (ICRQ, ICRP, OCRQ, OCRP) - MUST be 
   either REGENERATED or DROPPED. 

[mvk] Cookie is tied up with the session Id. Hence the scope of this avp is limited to a single hop.

   Remote End Id AVP (Version 3) (ICRQ, OCRQ) - MUST be either 
   REGENERATED or DROPPED. 

[mvk] scope is limited to a hop.

   Session Tie Breaker AVP (Version 3) (ICRQ, OCRQ) - MUST be either 
   REGENERATED or DROPPED. 

[mvk] Scope is limited to a hop. Does not need to be forwarded. Or TSA is not required to know this across the hop.

   Pseudowire Type AVP (Version 3) (ICRQ, OCRQ) - MUST be either 
   REGENERATED or DROPPED. 

[mvk] Scope is limited to a single hop. 

   L2-specific Sublayer AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, 
   OCCN) - MUST be either REGENERATED or DROPPED. 

[mvk] Scope is limited to a hop.

   Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 
   - MUST be either REGENERATED or DROPPED. 

[mvk] See the earlier discussion. Scope is limited to a hop.

   Circuit Status AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, 
   SLI) - MUST be either REGENERATED or DROPPED. 

[mvk] Scope is limited to a hop.

   Preferred Language AVP (Version 3) (SCCRQ, SCCRP) - MUST be either 
   REGENERATED or DROPPED. 

[mvk] Scope is limited to a hop.

   Tx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 
   MUST be either RELAYED, REGENERATED or DROPPED. In case of version 
   switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type 
   24). If value is greater than 4 octets, it SHOULD be dropped. 

   Rx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 
   MUST be either RELAYED if present in the inbound message, REGENERATED 
   or DROPPED. In case of version switch, TSA should relay it as a Rx 
   Connect Speed AVP (Attribute Type 38). If value is greater than 4 
   octets, it SHOULD be dropped. 

[mvk] No change.

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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext








_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext