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

[Carlos Pignataro <[e-mail]>]

Hi Mark,

Please see inline.

Circa 4/30/2005 10:53 AM, Mark Lewis said the following:
> 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??
> 

No. The link below Section 2. (or 2.1. in version -09) references the
LDP (FEC128/129) "Pseudowire Type", which is a 15-bit quantity (1 bit
used in the FEC Element for Control-word).
   IANA needs to set up a registry of "Pseudowire Type".  These are 15-
   bit values.

In contrast, "L2TPv3 Pseudowire Types" uses a different number space or
registry created as part of RFC3931 (see Section 10.6) for these 16-bit
quantities:
   The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value
   used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP

See also the registry "L2TPv3 Pseudowire Types" in
http://www.iana.org/assignments/l2tp-parameters

Regards,

--Carlos.



> (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
> 
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

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