Re: [L2tpext] Re: Local CE IP Address AVP

[Mark Lewis <[e-mail]>]

Hi Carlos,

>
>IMHO, there are other specifics to the IP-L2 transport over
L2TPv3 apart
>from the `Local CE IP Address AVP'.

Sure, the 'Local CE IP Address AVP' is obviously only designed
for the ARP mediation component of IP-L2 transport.


>For example, a PW Type for IP-L2
>Transport is not yet defined (in any draft and thus not
allocated),

I thought that IP L2 transport had been allocated the PW type
0x000B, hadn't it??

(http://www1.ietf.org/proceedings_new/04nov/IDs/draft-ietf-pwe3-iana-allocation-07.txt)


Regards,

Mark




>RCs
>(like mismatch ARP Med), should not use the value of `1 -
Only non-IP
>data packets require sequencing' for sequencing, etc. All
these would
>probably be too much for a document past last call, and only
adding the
>`Local CE IP Address AVP' would be incomplete. Besides, the
AVP is
>probably more related to or specific of IP-L2 transport than
to the
>signaling of l2vpns.
>
>We had actually been working in an `IP Layer 2 Transport over
L2TPv3'
>document including all of those considerations and numbers,
which should
>be ready very soon.
>
>Does that sounds reasonable?
>
>Best Regards,
>
>--Carlos.
>
>Circa 4/29/2005 11:24 PM, Ignacio Goyret said the following:
>> This discussion should be continued in the WG list.
>> 
>> Document by Mark Lewis attached inline at the end of this
message.
>> 
>> 
>> At 03:27 4/30/2005 +0100, Mark Lewis wrote:
>> 
>>>Hi Wei,
>>>
>>>Further to my idea for a 'Local CE IP Address' AVP, please see
>>>the attached word doc for a description.
>>>
>>>Any thoughts?
>>>
>>>Regards,
>>>
>>>Mark
>>>
>>>
>>>
>>>---- Original message ----
>>>
>>>>Date: Fri, 29 Apr 2005 16:18:57 -0700
>>>>From: Wei Luo <[e-mail]>  
>>>>Subject: Re: draft-ietf-l2tpext-l2vpn-02.txt  
>>>>To: [e-mail]
>>>>
>>>>Hi Mark,
>>>>
>>>>Reply under yours.
>>>>
>>>>Mark Lewis wrote:
>>>>
>>>>>Hi Wei,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>'The Interface Maximum Transmission Unit may be carried in
>>>>>>>both the ICRQ and ICRP messages sent during L2TP session
>>>>>>>(pseudowire) establishment between LACs.
>>>>>>
>>>>>>This text already exists in the current draft:
>>>>>>
>>>>>>   The Interface MTU is a 2-octet value.  This AVP MAY be
>>>
>>>present in
>>>
>>>>>>   ICRQ and ICRP.
>>>>>>
>>>>>
>>>>>
>>>>>That'll teach me not to read a draft properly!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>The Interface Maximum Transmission Unit AVP may also be
>>>>>>>carried in a SLI message in order to signal
reconfiguration of
>>>>>>>the MTU of a local attachment circuit (after L2TP session
>>>>>>>establishment).
>>>>>>
>>>>>>The reason it MTU AVP should not be put into a SLI message
>>>
>>>is because:
>>>
>>>>>>   The MTU values of a given pseudowire, if advertised
in both
>>>>>>   directions, MUST be identical.  If they do not match,
>>>
>>>the pseudowire
>>>
>>>>>>   SHOULD NOT be established.
>>>>>>
>>>>>>SLI messages do not estalish pseudowires but indicate
>>>
>>>status of the
>>>
>>>>>>pseudowires.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Sure- I am aware that SLI are not used to establish
>>>
>>>pseudowires. What I was
>>>
>>>>>getting at was using an SLI to signal a **RE**configuration
>>>
>>>(modification)
>>>
>>>>>in the MTU of attachment circuit **AFTER** pseudowire
>>>
>>>establishment.
>>>
>>>>>So, for example:
>>>>>
>>>>>At PW establishment, LCCE.A sends an ICRQ to LCCE.B with an
>>>
>>>MTU AVP
>>>
>>>>>specifying an attachment circuit MTU of 1500.
>>>>>
>>>>>LCCE.B responds with an ICRP with an MTU AVP specifying an
>>>
>>>attachment
>>>
>>>>>circuit MTU of 1500.
>>>>>
>>>>>LCCE.A sends an ICCN and PW setup is complete.
>>>>>
>>>>>
>>>>>***AFTER*** PW setup, an administrator then
>>>
>>>*modifies/reconfigures* the MTU
>>>
>>>>>on the attachment circuit on LCCE.A to 1600 (eg. using the
>>>
>>>'mtu 1600'
>>>
>>>>>command on Cisco boxes).
>>>>>
>>>>>Might an SLI be useful here to signal a **change** in
>>>
>>>attachment circuit
>>>
>>>>>MTU??
>>>>
>>>>That could be one way to do it.  The current draft writes
>>>
>>>that the 
>>>
>>>>pseudowire should not be established whenever there is an MTU
>>>
>>>mismatch. 
>>>
>>>> When a PE changes its own MTU, a mismatch occurs. 
>>>
>>>Therefore, the PE 
>>>
>>>>should first bring down the pseudowire and re-signal using
>>>
>>>the new MTU 
>>>
>>>>value.
>>>>
>>>>The problem with SLI signaling is that if the peering PE is
>>>
>>>not ready to 
>>>
>>>>change the MTU upon receiving the SLI, it probably sends a
>>>
>>>CDN to tear 
>>>
>>>>down the pseudowire anyway.  And both PEs have to go through
>>>
>>>the full 
>>>
>>>>session signaling procedure to re-establish the pseudowire. 
>>>
>>>So the 
>>>
>>>>benefit of maintaining the pseudowire is quite small.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Also, have you considered the addition of an 'Locally
>>>>>>>Connected CE Device IP address' AVP to be used where ARP
>>>>>>>mediation is carried out on the LCCE (IP mode L2VPN
>>>>>>>interworking)? This might be useful to signal the IP
address
>>>>>>>of the connected local CE device to a remote LAC/LCCE.
The AVP
>>>>>>>would not be marked mandatory, and could be hidden (M,H
bits).
>>>>>>>
>>>>>>>The AVP could potentially be carried in ICRQ and ICRP
messages
>>>>>>>if the local CE's IP address is known at the time of
session
>>>>>>>setup, or in an SLI if the CE's IP address becomes
known (or
>>>>>>>changes) after session setup has taken place.
>>>>>>>
>>>>>>
>>>>>>That's certainly an interesting point.  The ARP mediation
>>>
>>>draft defines
>>>
>>>>>>one LDP TLV for such a purpose, so I wonder if the authors
>>>
>>>prefer to
>>>
>>>>>>expanding that for L2TP in that draft or leaving it for
>>>
>>>this one.  I
>>>
>>>>>>will ask.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>As I am sure you are aware, the ARP mediation draft is
>>>
>>>currently going
>>>
>>>>>through IETF last call. I suggested the inclusion of the
>>>
>>>AVP I describe
>>>
>>>>>above, and received the following response:
>>>>>
>>>>>
>>>>>
>>>>>>5.0 CE IP Address Signaling between PEs
>>>>>>
>>>>>>
>>>>>>******How about for L2TPv3? I must admit I can’t recall an
>>>>>>L2TPv3 AVP that would allow the advertisement of the local
>>>>>>CE’s IP address to the remote PE, but I may well be a
little
>>>>>>behind the times on this! I guess that if such an AVP exists
>>>>>>(or will exist), it would have to be advertised either
in the
>>>>>>ICRQ/ICRP/ICCN or SLI (where discovery of the CE’s IP
address
>>>>>>did not coincide with pseudowire establishment)??
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>himanshu> We have not considered other PW signaling
mechanisms
>>>>>himanshu> in this draft. - may be future work item
>>>>>
>>>>
>>>>The L2TP draft has already gone through last call.  I will
>>>
>>>consult with 
>>>
>>>>the WG chairs to see whether it can be added at this stage.
>>>>
>>>>Thanks again!
>>>>
>>>>---Wei
>>>>
>>>>
>>>>>
>>>>>Regards,
>>>>>
>>>>>Mark
>> 
>> 
>> --------------------------------------------------------------
>> 
>> Local CE IP Address AVP
>> 
>> 
>> The Local CE IP Address AVP (Attribute Type TBA) is used to
signal
>> the IP address of a locally attached CE device to a remote
LCCE.
>> 
>> The advertisement of the IP address of a CE device is
relevant in
>> a LAC-to-LAC pseudowire deployment, where IP (routed) mode
L2VPN
>> interworking is being used. In this case, a process referred to
>> as 'ARP mediation' as described in
[draft-ietf-l2vpn-arp-mediation-01.txt]
>> may be performed in order to resolve addresses.
>> 
>> The encoding of the Local CE IP Address AVP is as follows:
>> 
>>     0                   1                   2             
     3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
>>   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |M|H|0|0|0|0|    Length         |              0       
        |
>>   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |              TBA              |       Local CE IP
Address        
>>   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                                    |
>>    ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
>> 
>> 
>> The Local CE IP Address is a 4-octect field. It may contain
either the
>> IP address of a locally attached CE device, or a NULL value
(0).
>> 
>> The Local CE IP Address AVP MAY be present in ICRQ and ICRP
messages if
>> the local CE device’s IP address is known at the time of
pseudowire setup.
>> 
>> If the local CE device’s IP address becomes known (or
changes) subsequent
>> to pseudowire setup, then the local CE device’s IP address
MAY be
>> signalled to the remote LCCE by including a Local CE IP
Address AVP in
>> an SLI message.
>> 
>> An SLI message containing a Local CE IP Address AVP with a
NULL value (0)
>> MAY also be used to signal the withdrawal of the IP address
of the locally
>> attached CE device.
>> 
>> 
>> The Mandatory (M) bit of the Local CE IP Address AVP SHOULD
be set to 0,
>> and the Hidden (H) bit MAY be set to either 1 or 0.
>> 
>> The Length of the Local CE IP Address AVP is 10 octets.
>> 
>> 
>> _______________________________________________
>> 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