Subject: [dhcwg] New Version Notification for draft-stapp-dhc-relay-id-00

From: Mark Stapp <[email-masked]>
Date: Wed, 13 Feb 2008 17:31:57 -0500

Hello all,

I've posted a new draft defining a new v4 relay agent suboption. The 
basic idea is to have a consistent place to convey an identifier for an 
individual relay agent. I've tried to describe at least one concrete 
use-case for this - in "Industrial Ethernet". It's short - really - so 
please take a look and comment.

I believe that Ralph and John have allocated a slot in the agenda at the 
Philadelphia meeting for me to go over the draft, and I hope to have 
some discussion there too.

Thanks,
Mark

=============================

A new version of I-D, draft-stapp-dhc-relay-id-00.txt has been 
successfuly submitted by Mark Stapp and posted to the IETF repository.

Filename:	 draft-stapp-dhc-relay-id
Revision:	 00
Title:		 The DHCPv4 Relay Agent Identifier Suboption
Creation_date:	 2008-02-13
WG ID:		 Independent Submission
Number_of_pages: 6

Abstract:
This memo defines a new Relay Agent Identifier suboption for the
Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information
option.  The suboption carries a unique identifier configured or
generated at the relay agent.  The suboption allows a DHCP relay
agent to include the unique identifier in the DHCP messages it sends.

The IETF Secretariat.

_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: pavan_kurapati <[email-masked]>
Date: Thu, 14 Feb 2008 10:28:27 +0530

Hi Mark,

I do support the need to uniquely identify relay agent. But in your use case, I was wondering why cant we use 'giaddr' for this purpose as that should uniquely identify the relay agent in the domain. As of today, DHCP servers do not seem to store 'giaddr' in the lease file. But we need to modify the server to either store the relay-id or giaddr for this purpose.

BTW, we did find a need for a relay identifier sub-option in the case of Layer 2 Relay Agents where they do not set giaddr and append option 82. In this case a combination of circuit-id and giaddr (which is set by other Layer 3 Relay Agent) may not be unique. So this sub-option is useful for this scenario.

Thanks,
Pavan
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mark Stapp [[email-masked]]
Sent: Thursday, February 14, 2008 4:01 AM
To: dhcwg
Subject: [dhcwg] New Version Notification for draft-stapp-dhc-relay-id-00

Hello all,

Thanks,
Mark

Abstract:

The IETF Secretariat.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 16 Feb 2008 14:28:02 -0500

Pavan,

On a relay agent, just one network interface could have more than one IP
address configured. So now there are multiple giaddr's in play.
Furthermore, the relay may have multiple network interfacs that are used
for relay operation. So now the number of giaddr's are further
multiplied. That is why using giaddr from a relay is not a good idea.
What we want is one single relay-agent identifier that spans the whole
relay agent.

That is why something as simple as a 128-bit DUID for relay-agent ID
seems just fine. Mark's draft mentions use of DUID in section 4.

It's not worth discussing what to use for relay-id any more. It is DUID,
if the relay-agent generates the relay-id.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of pavan_kurapati
Sent: Wednesday, February 13, 2008 11:58 PM
To: Mark Stapp (mjs); dhcwg
Subject: Re: [dhcwg] New Version Notification for
draft-stapp-dhc-relay-id-00

Hi Mark,

I do support the need to uniquely identify relay agent. But in your use
case, I was wondering why cant we use 'giaddr' for this purpose as that
should uniquely identify the relay agent in the domain. As of today,
DHCP servers do not seem to store 'giaddr' in the lease file. But we
need to modify the server to either store the relay-id or giaddr for
this purpose.

BTW, we did find a need for a relay identifier sub-option in the case of
Layer 2 Relay Agents where they do not set giaddr and append option 82.
In this case a combination of circuit-id and giaddr (which is set by
other Layer 3 Relay Agent) may not be unique. So this sub-option is
useful for this scenario.

Thanks,
Pavan
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mark
Stapp [[email-masked]]
Sent: Thursday, February 14, 2008 4:01 AM
To: dhcwg
Subject: [dhcwg] New Version Notification for
draft-stapp-dhc-relay-id-00

Hello all,

Thanks,
Mark

Abstract:
This memo defines a new Relay Agent Identifier suboption for the Dynamic
Host Configuration Protocol's (DHCP) Relay Agent Information option.
The suboption carries a unique identifier configured or generated at the
relay agent.  The suboption allows a DHCP relay agent to include the
unique identifier in the DHCP messages it sends.

The IETF Secretariat.

**************** CAUTION - Disclaimer ***************** This e-mail
contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the
use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further,
you are not to copy, disclose, or distribute this e-mail or its contents
to any other person and any such actions are unlawful. This e-mail may
contain viruses. Infosys has taken every reasonable precaution to
minimize this risk, but is not liable for any damage you may sustain as
a result of any virus in this e-mail. You should carry out your own
virus checks before opening the e-mail or attachment. Infosys reserves
the right to monitor and review the content of all messages sent to or
from this e-mail address. Messages sent to or from this e-mail address
may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg