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

From: "Vach Kompella" <[email-masked]>
Date: Wed, 6 Apr 2005 13:07:32 -0700

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

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 21 Apr 2005 10:19:37 -0700

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 21 Apr 2005 15:24:22 -0400

Vach,

It's an awesome draft.

Thanks,
Andy
(a co-author)

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 25 Apr 2005 17:19:42 -0400

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.

__________

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.

__________

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?

__________

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?

__________

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?

__________

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?

__________

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?

Thanks,

--Carlos.

-- 
--Carlos.
Escalation RTP - cisco Systems

---

From: Luca Martini <[email-masked]>
Date: Mon, 25 Apr 2005 19:21:13 -0600

Vach,

I finally had made the time to read this draft. Here are some comments:

- I'll say it first ( I'm sure the IESG would say the same ) : there 
seem to be a bit too many authors. I think this list needs to be trimmed 
to people you can attribute some text in the document to. I believe 5 
authors is the maximum, without having to really justify it.
- The introduction section needs to make it clear that A PW of type IP 
is used. It should reference PWE3-CONTROL.
- Please fix all the non-ASCII characters in the document , Lot's of 
"CE0x??E" and others. you need to turn off MS-word automatic character 
substitution, or better still use emacs ;-)
- Please change all the PWE3-IANA to PWE3-CONTROL. The IANA document 
only specifies a PW type number , nothing more.
- Section 3.0: PWs are bi-directional by definition , so remove the text 
"bi-directional"
- Section 4.2 with  the topology restriction to only one CE , 
promiscuous ARP can be used to really simplify things. The explanation 
should be added here.
- Page 5 has some nordic region O characters in it ... not English.
- section 5.2 and page 8. Define the IP Address interface parameter , I 
believe it has been allocated in IANA so put the number in here. This 
section needs some major additions. There is no clear description on how 
to work with the IP interface parameter. What LDP notification message ? 
I do not recall defining anything other then PW status messages. There 
is no way to change an interface parameter once the PW is established. ( 
This is not an auxiliary control channel ... it's static , can only be 
used once )
- Spacing is wrong at the section 6.0 heading
-PWE3 Control draft must be made normative. ( The procedures described 
here are not implementable without pwe3-control )

Thanks.
Luca