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

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 25 Apr 2005 17:39:09 -0400

Hi Carlos,

Thanks for your comments.
I scanned through your comments quickly and it appears
from your comments as well as comments from Mark Lewis that
PPP section needs to be revised/clarified.

Let me send response to your specific comments.

Just wanted to quickly reply to acknowledge your mail and
no it is not too late.

/himanshu

> -----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.
> 
> 
> __________
> 
> 
> 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.
> 
> 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: Mark Lewis <[email-masked]>
Date: Wed, 27 Apr 2005 09:42:29 +0100

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: Shah, Himanshu [mailto:[email-masked]]
>>Sent: 26 April 2005 20:48
>>To: Carlos Pignataro; [email-masked]; [email-masked]
>>Cc: [email-masked]
>>Subject: RE: WG Last Call on ARPmediation
>>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.
>>
>>
>>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.
>>
>> > __________
>> >
>> >
>>himanshu> Correct. Will make the change.
>>
>> > __________
>> >
>> >
>> >
>>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.
>>
>>
>> > __________
>> >
>> >
>> >
>>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.
>>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.
>>
>>
>> >
>>himanshu> Yes it should. Will make the change.
>>
>>
>> >
>>himanshu> yes.
[mailto:[email-masked]]

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 27 Apr 2005 17:53:46 -0400

Hi Luca,
Thanks for your comments.
Responses in line marked with "himanshu>"
 
regards,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Luca Martini
Sent: Monday, April 25, 2005 9:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: WG Last Call on ARPmediation draft:draft-ietf-l2vpn-arp-mediation-01.txt

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.
[himanshu>] Noted. 
- The introduction section needs to make it clear that A PW of type IP is used. It should reference PWE3-CONTROL.
[himanshu>] Noted. 
- 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 ;-)
[himanshu>] Noted 
- Please change all the PWE3-IANA to PWE3-CONTROL. The IANA document only specifies a PW type number , nothing more.
[himanshu>] Noted.  
- Section 3.0: PWs are bi-directional by definition , so remove the text "bi-directional"
[himanshu>] Noted 
- 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. 
[himanshu>] I am not sure what exact method you have in mind. Can you elaborate??
- Page 5 has some nordic region O characters in it ... not English.
[himanshu>] noted. 
- 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. 
[himanshu>] I checked in the latest IANA draft, there is no interface parameter for IP address. Besides, IP address in not intended to be part of the interface parameter because that would make it a static PW attribute. It is intentionally passed in the optional parameter field of the Label Mapping message as the IP address may not available when the PW FEC is exchanged. That is,  IP L2 Transport PW must be allowed to be established before the IP address of the local CE is known. This way, multicast packets can flow (such as OSPF hello) between the CEs, which in turn causes ETH-CE to ARP for his peer. If ETH-attached PE is strictly learning CE's IP address from ARP packets, this enables PE to learn CE's IP address and can now send an update in LDP NOTIFICATION message.

 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 )
[himanshu>]  That is right. And hence there is no IP interface parameter. Me and Hamid had written a draft-shah-pwe3-control-protocol-extension-00.txt back in 2003. This draft described how PEs can exchange capabilities and PW attributes thereafter via LDP NOTIFICATION. About 4 cases were sited in that draft, PW status, PW QOS, CE's IP address and CE's IP and MAC address (used for IPLS). Out of which, you included the PW status in the base PWE3-control draft but not others. Well, we need the rest. Since that draft has expired, I have included the text describing how exchange of CE's IP address can be conducted as part of optional TLV of the LABEL MAPPING msg and LABEL NOTIFICATION msg in this draft.
  Spacing is wrong at the section 6.0 heading
[himanshu>] Noted 
-PWE3 Control draft must be made normative. ( The procedures described here are not implementable without pwe3-control )
[himanshu>] Noted 

Thanks.
Luca

Vach Kompella wrote: 

Two weeks are almost up, and there have been no comments on this draft.

-Vach 

-----Original Message-----

From:  [email-masked] [ mailto:[email-masked]] 

To:  [email-masked]

Folks,

Thanks.

Vach Kompella

IP Division, Alcatel

+1 650 623-2556

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 29 Apr 2005 13:58:35 -0400

Hi Carlos,

Thanks for the comments again.
I will incorporate your recommendations/request-for-clarification in the 
new version of the draft.

regards,
himanshu

> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Tuesday, April 26, 2005 11:49 PM
> To: Shah, Himanshu
> Cc: [email-masked]; [email-masked]; [email-masked]
> Thanks. Please find a couple of follow-up comments inline.
> 
> Circa 4/26/2005 3:47 PM, Shah, Himanshu said the following:
> > Hi Carlos and Mark,
> > 
> where CE and PE can exchange the local IP address configuration
> own, PE proxies for remote CE.
> present in the IP-Address option TLV 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.
> 
> IP-Address option, PE responds with Configure-Ack.
> the local CE using IPCP and hence would rely on other means
> It may also be noted here that to use the other methods (IRDP,
> multicast) with PPP, IPCP needs to be open.
> 
> > ·	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 
> [snip]
> there is one router
> > 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,
> 
> -- 
> --Carlos.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 29 Apr 2005 14:04:52 -0400

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

> 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