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

[Carlos Pignataro <[e-mail]>]

Hello Mark,

IMHO, there are other specifics to the IP-L2 transport over L2TPv3 apart
from the `Local CE IP Address AVP'. For example, a PW Type for IP-L2
Transport is not yet defined (in any draft and thus not allocated), 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