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

From: Ignacio Goyret <[email-masked]>
Date: Fri, 29 Apr 2005 20:24:07 -0700

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 <[email-masked]>  
>>Subject: Re: draft-ietf-l2tpext-l2vpn-02.txt  
>>To: [email-masked]
>>
>>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 30 Apr 2005 10:13:37 -0400

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.

-- 
--Carlos.
Escalation RTP - cisco Systems

---

From: Wei Luo <[email-masked]>
Date: Mon, 02 May 2005 11:46:22 -0700

IP interworking over L2TPv3 does seem to have more than adding a Local 
CE IP Address AVP.  As part of my original response to Mark, I suggested 
putting this into the PWE3 IP interworking draft so that it can be 
supported in relevant context.  Looks like there is an L2TP draft on IP 
interworking already, so that seems to be the right place for this AVP.

Thanks,

---Wei

---

From: "Mark Lewis" <[email-masked]>
Date: Tue, 3 May 2005 19:14:35 +0100

Hi Carlos & Wei,

I think there are a couple of drafts the 'Local CE IP Address AVP' could
possibly fit in, but as you say, perhaps the most logical fit is an L2TPv3
IP interworking draft. Please go ahead and include it.

Regards,

Mark

> -----Original Message-----
> From: Wei Luo [mailto:[email-masked]]
> Sent: 02 May 2005 19:46
> To: Carlos Pignataro; [email-masked]
> Cc: [email-masked]
> Subject: Re: [L2tpext] Re: Local CE IP Address AVP
>
>