[L2tpext] Re: Local CE IP Address AVP

[Ignacio Goyret <[e-mail]>]

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