Subject: RE: WG Last Call on ARPmediation draft:draft-ietf-l2vpn-arp-mediation-01.txt

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 26 Apr 2005 15:47:47 -0400

Hi Carlos and Mark,

Here is the updated section 4.2 with changes suggested
by you and mark lewis. Please review this for the correctness.

=========
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.
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.
.     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].
=============

Responses to rest of your comments in-line.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Carlos Pignataro
> Sent: Monday, April 25, 2005 5:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: WG Last Call on ARPmediation
> draft:draft-ietf-l2vpn-arp-mediation-01.txt
> 
> 
> Vach,
> 
> Please find some comments inlined below.
> Hope they are useful and it's not too late ;-)
> 
> 
> 3.0 IP Layer 2 Interworking Circuits:
>     The IP Layer 2 Interworking Circuits refer to Pseudowires that
>     carry IP datagrams as payload.  The ingress PE removes the data
>     link header of its local Attachment Circuit and transmits the
>     payload (an IP frame) over the Pseudowire with or without the
>     optional control word. The egress PE encapsulates the IP packet
>     with the data link header used on its local Attachment Circuit.
> 
>     The IP Pseudowire encapsulation is described in [PWE3-IANA].
> 
> *****	[PWE3-IANA] (or AFAIK any other place) does not specify that
> 	`IP Layer2 Transport' is to be used for IPv4 only or IPv6 as
> 	well; the IP version discriminates between the 2 on data
> 	packets. However, this document does not mention IPv6.
> 
> 

himanshu> IANA doc specifies the PW type code point. Control draft
himanshu> at least one point defined the IP over MPLS encapsulation
himanshu> I will check the latest version.

> __________
> 
> 
> 4.2 CE Devices Using ARP:
>     Once the local CE has been discovered for the given Attachment
>     Circuit, the local PE responds to subsequent ARP requests 
> from that
>     device with its own MAC address.
> 
> *****	The local PE shouldn't proxy the ARPs until the remote CE's
> 	IP address's been discovered & signaled, and only when the
> 	destination protocol address matches the remote CE's IP addr.
> 
> 

himanshu> Correct. Will make the change.

> __________
> 
> 
> 
> 4.2 CE Devices Using ARP:
>     The local PE signals the CEƳ IP
>     address to the remote PE and may initiate an unsolicited ARP
>     response to notify local CE MAC address to  IP address binding of
>     the remote CE.
> 
> *****	At this point, the local PE may not know the remote CE's IP.
> 	Does initiating the unsolicited ARP refer to the remote PE?
> 
> 

himanshu> It refers to the case where local PE may already know remote CE's
himanshu> IP address. In which case, it can generate unsolicited ARP response.
himanshu> This paragraph will read better once the changes related to your
himanshu> earlier comment is incorporated.

> __________
> 
> 
> 
> 4.4 CE Devices Using PPP:
>        . If the local PE does not know the IP address of the local CE,
>          it generates a configure-request without the configure IP
>          address TLV.
> 
> *****	An IPCP Configure-Request without IP Address option is to
> 	be sent if the local PE does not know the IP address of the
> 	_remote_ CE instead of the "local CE"? This section is about
> 	discovering the local CE's IP address, and if the remote CE's
> 	IP address is known, why not send it in the Configure-Request?
> *****	Also, what to do if the conditions in this and next bullet both
> 	apply (i.e. PE does not know local CE's address but does know
> 	remote CE's address)?
> 
> 
> __________
> 
> 
> 
> 4.4 CE Devices Using PPP:
>        The response from CE is accepted as IP address of
>          the local CE.
> 
> *****	The response of the local CE would be a CONFACK, CONFNACK or
> 	other, depending on whether it's configured to require the IP
> 	from the peer; however, it seems to me that the IP address of
> 	the local CE should be taken from the `IP Address Option' in the
> 	local CE's IPCP Configure-Request and not from the response from
> 	the CE, as these are double negotiations.
> 
> 
> __________
> 
> 
> 
> 4.4 CE Devices Using PPP:
>        . If PE knows the IP address of the remote CE, it sends an IPCP
>          configure-request with the IP address of the remote CE in the
>          configure IP address TLV
> 
> *****	Probably `in the IP Address configuration Option' is more clear;
> 	this however seems to be the mechanism to signal the local CE
> 	about the remote CE's IP address, and not to discover the local
> 	CE's IP.
> 
> 
> __________
> 
> 
> 
> 4.4 CE Devices Using PPP:
>        . If the local PE receives an IPCP configure-request 
> without the
>          configure IP address TLV, and if it knows the IP address of
>          the remote CE, it responds with configure NAK with the
>          configure IP address TLV set with remote CEƳ IP address.
> 
> *****	Wouldn't this procedure "assign" the remote CE's IP address to
> 	the local CE? The value in the Configure-Nak indentifies a
> 	"value acceptable to the Configure-Nak sender." If the idea is
> 	to tell the CE that it must send an IP Address option, from
> 	RFC1661:
> 	"Finally, an implementation may be configured to request the
> 	 negotiation of a specific Configuration Option. If that option
> 	 is not listed, then that option MAY be appended to the list of
> 	 Nak'd Configuration Options, in order to prompt the peer to
> 	 include that option in its next Configure-Request packet.
> 	 Any value fields for the option MUST indicate values acceptable
> 	 to the Configure-Nak sender." There's also this text that
> 	applies from RFC1332:
> 	"If negotiation about the remote IP-address is required, and the
>          peer did not provide the option in its Configure-Request, the
>          option SHOULD be appended to a Configure-Nak.  The 
> value of the
>          IP-address given must be acceptable as the remote 
> IP-address, or
>          indicate a request that the peer provide the information."
> 	In any case, it seems to me the CONFNAK should not contain the
> 	remote CE's IP address as the value.
> 
> 
> __________
> 
> 
> 
> 4.4 CE Devices Using PPP:
>          However, if PE does not know the remote CEƳ IP address yet,
>          it responds with a configure NAK.
>        . If the local PE does not know the IP address of the 
> remote CE,
>          it sends an IPCP configure-request with IP address as zero.
>          The response from CE is recorded and used to validate the
>          incoming remote CEƳ IP address via PW signaling.
> 
> *****	An IP Address option of zero means that the peer should assign
> 	the sender's IP address. From RFC1332:
> 	"If all four octets are set to
>          zero, it indicates a request that the peer provide the
> IP-Address
>          information."
> 	So in this case the response from the CE would be a
> 	Configure-Nak with the IP address to use (assigned) if
> 	configured to do so; the CE local CE could assign an IP address
> 	but would not know the remote CE's address. Unless I'm
> 	mis-interpreting the bullet.
> 
> 
> __________
> 
> 
> 
> 4.4 CE Devices Using PPP:
>     The local PE must deny configurations such as header compression
>     and encryptions in the NCP packets with such options.
> 
> *****	Does the above mean `IP-Compression-Protocol Option for IPCP and
> 	other NCPs'?
> 
> 
> 
> __________
> 
> 
> 
> 4.5 Router Discovery method:
>     In order to learn the IP address of the CE device for a given
>     Attachment Circuit, the PE device may execute Router Discovery
>     Protocol [RFC 1256] whereby a Router Discovery Request (ICMP ?
>     router solicitation) message is sent using a source IP address of
>     zero. The IP address of the CE device is extracted from the Router
>     Discovery Response (ICMP ?ter advertisement) message from the
>     CE.
> 
> 
> *****	What if the ICMP Router advertisement message contains multiple
> 	Router Addresses with the same preference level?
> 
> 
> __________
> 

himanshu> The network topology recommended mandates that there is one router
himanshu> per attachment circuit. If multiple routers do exist then some
himanshu> heuristics is required - such as first on the list or something.

> 
> 
> 5.2 LDP Based Distribution:
>     In addition, this document defines an IP address TLV that must be
>     included as an optional parameter in the  Label Mapping message
>     when advertising the PW FEC for the IP L2 Interworking 
> Circuit. The
>     use of optional parameters in the Label Mapping message to extend
>     the attributes of the PW FEC is specified in the [PWE3-Control].
> 
> *****	Is the must in the first sentence above a MUST? What are the
> 	U and F bits set to?
> 
> 
> __________
> 
> 

himanshu> Luca has raised the same question, please refer to my response to him.
himanshu> In short, there needs to exist either a separate draft or a whole
himanshu> section to explain this.

> 
> 6.1 CE Devices Using ARP:
>     The PE must respond only to those ARP requests whose destination
>     protocol address matches the remote CE's IP address.
> 
> *****	Is this s/must/MUST/?
> 
> 
> __________
> 
> 

> 
> 6.3 CE Devices Using PPP:
>     When the PE learns the remote CE's IP address, it should initiate
>     the Configure-Request using the remote CE's IP address or respond
>     to pending Configure-Request from the local CE.
> 
> *****	Shouldn't it do both, independently? Ack the Configure-Request
> 	from the CE (when the PE discovered the local CE's address)
> 	_and_ issue a Configure-Request proxying the remote CE's IP
> 	address to inform the local CE?
> 
> 
> __________
> 
> 

himanshu> Yes it should. Will make the change.

> 
> 6.3 CE Devices Using PPP:
>     As noted earlier,
>     all other configuration options related to compression,
>     encryptions, etc., should be rejected.
> 
> *****	IPCP Option 2 and other NCPs?

himanshu> yes.

> 
> 
> Thanks,
> 
> --Carlos.
> 
> Circa 4/21/2005 1:19 PM, Vach Kompella said the following:
> > Two weeks are almost up, and there have been no comments on 
> this draft.
> > Either everyone is comfortable with the draft, or no one cares.  In
> > either case, we would like to hear comments.
> > 
> > -Vach 
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] 
> >>On Behalf Of Vach Kompella
> >>Sent: Wednesday, April 06, 2005 1:08 PM
> >>To: [email-masked]
> >>Subject: WG Last Call on ARP mediation 
> >>draft:draft-ietf-l2vpn-arp-mediation-01.txt
> >>
> >>
> >>Folks,
> >>
> >>We are starting a 2 week working group Last Call on the ARP 
> >>mediation draft.  Please read and send comments to the list.
> >>
> >>Thanks.
> >>
> >>Vach Kompella
> >>IP Division, Alcatel
> >>[email-masked]
> >>+1 650 623-2556
> >>
> >>
> > 
> > 
> 
> -- 
> --Carlos.
> Escalation RTP - cisco Systems
> 
>

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 26 Apr 2005 23:49:17 -0400

Hi Himanshu,

Thanks. Please find a couple of follow-up comments inline.

>       to assign him an IP address). If the IP address is non-zero, PE responds with Configure-Ack.

It may be worth clarifying that in this case the Configure-Reject copies
the IP-Address option with null value to instruct the CE to not include
that option in the new Configure-Request.

>       as described above (such as link-local broadcast from OSPF hello).

It may also be noted here that to use the other methods (IRDP,
multicast) with PPP, IPCP needs to be open.

>       option containing the remote CE's IP address.

[snip]

> himanshu> heuristics is required - such as first on the list or something.

I assumed so, I was just wondering if such text needs to be spelled out.
A similar description exists for ARP discovery in Section 4.2.

Also, a couple of more nits:
o The PW Type description/name in PWE3-IANA is `IP Layer2 Transport' and
  not `IP L2 interworking' as in Sections 5.1 and 5.2.
o The following 3 sentences could be clarified in process (where are
  packets not propagated and which direction, under which conditions)
  and scope (applies to all ethernet, ppp, etc?). The first one appears
  in generic section 4.0 but seems ethernet specific:
  1. During the period when the (bi-directional) PW
     has been established but local CE IP device has not been detected,
     only datagrams inside of broadcast/multicast frames are propagated;
  2. Once this is completed, unicast traffic between two
     CEs can start flowing.
  3. During this period, propagation of unicast IP traffic
     is suspended, but multicast IP traffic can continue to flow.

Thanks,