Subject: RE: FW: WG Last Call on ARPmediation

From: Mark Lewis <[email-masked]>
Date: Fri, 29 Apr 2005 21:57:20 +0100

Hi Himanshu,

>
>As for denying all other PPP specific options (obviously
>we can not make them interwork for ETH/FR/ATM), I don't know
>if should list each and every PPP option or some blanket
>statement saying that PPP specific options can not be
>interworked with other non-PPP attachment circuits.
>

Obviously, both attachment circuits (including the PPP
attachment circuit) are terminated on their local PE device
when using IP (routed) mode L2VPN interworking, so there is no
question of interworking PPP, as you say.

I completely agree with you about a blanket statement. I guess
that in order for IP mode L2VPN interworking to function, the
only NCP option that the PE and CE *MUST* negotiate is the
IPCP IP-Address option (0x03) - it is not necessary to
negotiate any other NCPs or IPCP options. Isn't that right?

So, how about *something along these lines* :

'In order for IP (routed) mode L2VPN interworking to function
correctly, the PE device MUST negotiate the IPCP IP-Address
option (0x03) with the local CE device. The PE device MAY
reject configuration of other NCPs and IPCP options.'

Is that at all useful??

Regards,

Mark

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: 29 April 2005 19:05
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: FW: WG Last Call on ARPmediation
draft:draft-ietf-l2vpn-arp-mediation-01.txt

Hi Mark,

I think we are on the same page.
Your offered text reads better so I will use that.

As for denying all other PPP specific options (obviously
we can not make them interwork for ETH/FR/ATM), I don't know
if should list each and every PPP option or some blanket
statement saying that PPP specific options can not be
interworked with other non-PPP attachment circuits.

regards,
himanshu

> -----Original Message-----
> From: Mark Lewis [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2005 4:42 AM
> To: Shah, Himanshu
> Cc: [email-masked]; [email-masked];
[email-masked]
> Subject: Re: FW: WG Last Call on ARPmediation
> draft:draft-ietf-l2vpn-arp-mediation-01.txt
> 
> 
> Hi Himanshu,
> 
> Please see my comments below.
> 
> 
> 
> 
> 4.4 CE Devices Using PPP
> 
> The IPCP protocol is a two-sided negotiation procedures where
> CE and PE can exchange the local IP address configuration with
> each other. Since PE does not have IP address of his own, PE
> proxies for
> remote CE.
> 
> 
> ************************************************************
> Would it be possible to tweak the description of IPCP here?
> How about ‘The IP Control Protocol [IPCP] describes a
> procedure to establish and configure IP on a point-to-point
> connection, including the negotiation of IP addresses.’
> 
> Also, you mention that ‘……since the PE does not have an IP
> address of its own, it proxies for the remote CE’. Isn’t it
> more correct to say that the PE performs proxy negotiation on
> behalf of the remote CE because when using IP/routed mode
> L2VPN interworking, the PPP negotiation **does not take place
> end-to-end between the CE devices** (the remote CE does not
> reside on a PPP link, and the pseudowire type used between PE
> devices is type 0x000B).
> 
> Therefore, in order for the local CE device to find out the IP
> address of the remote CE, the local PE device must
> ‘impersonate’/proxy the remote CE? It doesn’t really have that
> much to do with the fact that the PE doesn’t have its own IP
> address on the link does it??- The really **crucial fact** is
> that proxy PPP negotiation takes place between the local CE
> and PE because there is no end-to-end PPP negotiation between
> the local and remote CE devices, isn’t it???
> 
> So, how about wording along the following lines:
> 
> ‘When using IP (Routed) mode L2VPN interworking, PPP
> negotiation is not performed end-to-end between CE devices. In
> this case, PPP negotiation takes place between the CE device
> and its local PE device (on the PPP attachment circuit). The
> PE device performs proxy PPP negotiation, and informs the
> local CE device of the IP address of the remote CE device
> during IPCP negotiation using the IP-Address option [0x03].’
> **************************************************************
> 
> 
> When a PPP link becomes operational after the LCP
> negotiations, the local PE MAY perform following actions
> .     The PE learns the IP address of the local CE from the
> Configure-Request received with the IP-Address option (0x03).
> The PE verifies that the IP address present in the IP-Address
> option TLV is non-zero. If the IP address is zero, PE responds
> with Configure Reject (as this is a request from CE to assign
> him an IP address). If the IP address is non-zero, PE responds
> with Configure-Ack.
> 
> 
> 
> ************************************************************
> Would it be possible to change ‘IP-Address option TLV’ here to
> ‘IP-Address option’ (delete the acronymn ‘TLV’ as its not
> really used to describe PPP options)??
> ************************************************************
> 
> 
> .     If the PE receives Configure-Request without the
> IP-Address option, PE responds with Configure-Ack. In this
> case, PE would not learn the IP address of the local CE using
> IPCP and hence would rely on other means as described above
> (such as link-local broadcast from OSPF hello).
> Â·	If the PE does not know the IP address of the remote CE, it
> generates a Configure-Request without the IP-Address option.
> Â·	If the PE knows the IP address of the remote CE, it sends
> an IPCP Configure-Request with the IP-Address option
> containing the remote CE's IP address.
> 
> The local PE device must deny the configuration of Network
> Control Protocol [NCP] options such as the IP-Compression
> Protocol [IPCP option 0x02].
> 
> 
> ***************************************************
> I’m not sure about the phrase, ‘….options such as the
> IP-Compression Protocol [IPCP option 0x02].’ What,
> specifically, are the criteria for denying the configuration
> of an NCP option here? I know that it includes IPCP
> IP-Compression [0x02] option, but how about denying
> negotiation of the Compression Control Protocol (CCP, RFC
> 1962) in its entirety?? Do you perhaps also want to include a
> prohibition against negotiation of the Encryption Control
> Protocol in its entirety (ECP, RFC 1968)??
> 
> 
> 
> 
> Hope that helps,
> 
> Mark
> 
>

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 29 Apr 2005 17:35:20 -0400

Hi Mark/Himanshu,

Please find a couple of comments inline.

Circa 4/29/2005 4:57 PM, Mark Lewis said the following:
> option (0x03) with the local CE device.

A MUST here contradicts the fact that the text does not "require" the CE
to provide IP-Address option, and instead the PE relies on other methods
if the CE does not send IPCP option 0x03. From the 2nd bullet:
	".     If the PE receives Configure-Request without the
	IP-Address option, PE responds with Configure-Ack."

> The PE device MAY

I wonder if this should be stronger, a SHOULD or MUST; I think the idea
is to prevent the CE from negotiating any other protocol/NCP so that it
does not send those protocols that would ultimately be discarded at the
PE and not transported.

Thanks,

--Carlos.

-- 
--Carlos.
Escalation RTP - cisco Systems