Subject: [CCAMP] Hello Message

From: Vishwas Manral <[email-masked]>
Date: Sun, 25 Apr 2010 16:45:36 -0700

Hi,

While working on the document for RSVP-TE for IPv6 I noticed that
RFC3209 specifies that the Hello Message TTL should be set to 1,
however RFC3473 does not change the behavior.

Shouldn't the TTL in the case of GMPLS be set to more than one as a
control channel to he data plane nexthop could be multiple hops away?
I think we should reccomend the use of the TTL value of 255. Besides
for IPv6 it would be the Hop Limit field.

Thanks,
Vishwas

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 25 Apr 2010 19:11:24 -0500

Hi,

I believe that TTL 1 is only for immediate neighbors.

Regads,
Reshad.

   When HELLO messages are being the exchanged between immediate
   neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be
   set to 1.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vishwas Manral
Sent: Sunday, April 25, 2010 7:46 PM
To: [email-masked]
Subject: [CCAMP] Hello Message

Hi,

Thanks,
Vishwas
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 25 Apr 2010 17:13:41 -0700

Hi Reshad,

In GMPLS in the control plane the immediate neighbors may be more than
one IP Hop away.

Thanks,
Vishwas

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 25 Apr 2010 19:23:23 -0500

Hi Vishwas,

You're right I guess there's ambiguity as to whether immediate is referring to data-plane or control-plane.

Regards,
Reshad.

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Sunday, April 25, 2010 8:14 PM
To: Reshad Rahman (rrahman)
Cc: [email-masked]
Subject: Re: [CCAMP] Hello Message

Hi Reshad,

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 25 Apr 2010 17:50:01 -0700

Hi Reshad,

That is correct.

All messages except the OAM and LMP test message are sent over the
control plane. So immediate neighbors in the control plane too should
not set the TTL to 1, unless they are sure the neighbor is directly
connected in the IP layer.

In my view, it is more than an ambiguity its not been taken care of at
all in the spec.

Thanks,
Vishwas

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Apr 2010 09:12:47 -0400

Vishwas,

I have to say, I really don't see an issue here. Recall that in 3209 DP
and CP adjacencies are congruent, so there is no ambiguity.  In the
cases where hellos are exchanged between non-immediate neighbors (GMPLS
or MPLS), TTL shouldn't be set to 1.  I think this case is fairly
clearly covered too.  To be specific, how would you like to see the text
changed? For example, do you want the text to read:

Current 3209:
   When HELLO messages are being the exchanged between immediate
   neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be
   set to 1.
Add
   Additionally, when HELLO messages are not being the exchanged
   between immediate neighbors, the IP TTL field of all outgoing HELLO
   messages SHOULD NOT be set to 1.

Seems a bit redundant and obvious.  Don't you think?

Am I missing something?

Lou

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 07:26:36 -0700

Hi Lou,

I think if you read the sentence just before the one we have mentioned
it becomes clear:

   The HELLO mechanism is intended for use between immediate
   neighbors. When HELLO messages are being the exchanged between
   immediate neighbors, the IP TTL field of all outgoing HELLO messages
   SHOULD be set to 1.

What this seems to mean to me, is that HELLO's always use TTL 1.

The text we need to have in GMPLS RFC is:

   The HELLO mechanism is intended for use between immediate
   neighbors. In the GMPLS case the immediate neighbors can be more
   than one IP Hop away. HELLO messages exchanged in GMPLS
   between immediate neighbors SHOULD have the IP TTL field of all
   outgoing HELLO messages set to 1.

Without this the HELLO mechanism does not work.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 07:30:45 -0700

Hi Jonathan,

Thanks a lot for the inputs. I guess you wanted to forward the mail to the list.

I agree if like you mentioned, older implementations used GRE the TTL
required in the inner header is always 1. However that is just one way
to implement it and like you mentioned implementations set the TTL
value to greater than 1.

I agree LMP CC Hello mechanisms are useful.

Thanks,
Vishwas

On Mon, Apr 26, 2010 at 7:04 AM, Sadler, Jonathan B.
<[email-masked]> wrote:
> Vishwas -
>
> It all depends on how your supporting your control channel.  In early years, many implementations ran the control channel as a tunnel (e.g. GRE, IP-in-IP) to handle two issues: getting around the snooping of RSVP traffic by intermediate routers (this was later accommodated for by router alert) and TTL expiry limits in both RSVP-TE and OSPF.  This is part of the reason LMP sessions are critical - they in essence provide CC OAM (i.e. is it still up) for the tunnel.
>
> Today, many implementations run control channels without running over a tunnel and support larger TTL.
>
> Hope this helps,
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
> Sent: Sunday, April 25, 2010 6:46 PM
> To: [email-masked]
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 07:32:14 -0700

Changed with a small correction:

Hi Lou,

  outgoing HELLO messages set to 255.

Thanks,
Vishwas

---

From: Julien Meuric <[email-masked]>
Date: Mon, 26 Apr 2010 17:58:57 +0200

Hi Vishwas.

Keep in mind that RFC 3209 does not say "MUST" but "SHOULD". The fact 
that it does not work in case of multiple IP nodes between GMPLS 
neighbors is a very good (not to say obvious) reason to avoid 1 as IP TTL.

What is more, with RFC 3473 in mind, I read "immediate neighbors" as 
refering to the IP layer (not to the GMPLS controllers); thus I would 
rather describe your context as: "GMPLS neighbors which are *not 
immediate neighbors*" (one of the drivers for LMP, as described by 
Jonathan). In that case, the quoted constraint would not even apply in 
your context.

Regards,

Julien

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Apr 2010 12:36:55 -0400

Vishwas,
	See below.

On 4/26/2010 10:32 AM, Vishwas Manral wrote:
>   neighbors. 

Note that this an informative statement without normative language.

> When HELLO messages are being the exchanged between

Note that this is normative.

> What this seems to mean to me, is that HELLO's always use TTL 1.

No.  it says:
(a) the statement's applicability is limited to the case where message
exchange is between neighbors.  Given that this statement (and RFC)
applies to RSVP, a reasonable interpretation is that this statement
applies to RSVP immediate neighbors.
(b) The a TTL value of 1 is used except when an implementation knows
that there is a reason not to do so.  See RFC2119 for specific language.

> Without this the HELLO mechanism does not work.

I have to say that I simply disagree.  The current language is
sufficient for the scope of immediate (RSVP) adjacency and is silent on
the non-adjacent case.  Such silence is not atypical.  For example, we
(intentionally) don't discuss TTL usage on Hellos.  Another example is
RFC4271 which doesn't mention TTL at all.

Lou

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 11:07:53 -0700

Hi Julien,

I just saw a clear gap and brought it up. My comments are inline.

> Keep in mind that RFC 3209 does not say "MUST" but "SHOULD". The fact that
> it does not work in case of multiple IP nodes between GMPLS neighbors is a
> very good (not to say obvious) reason to avoid 1 as IP TTL.
I agree it is a SHOULD and not a MUST.

That is ok, if we assume that also means that the control plane
neighbors are one IP HOP away is a SHOULD case. Is my thinking
correct?

> refering to the IP layer (not to the GMPLS controllers); thus I would rather
> describe your context as: "GMPLS neighbors which are *not immediate
> neighbors*" (one of the drivers for LMP, as described by Jonathan).
If that is the case then the statement Hello's are sent to immediate
neighbors needs to be first updated (please read the statement just
before the statement you have mentioned).

Regarding Jonathan's comment, I agree it can be implemented with
tunnels. However we cannot write a spec based on a particular
implementation (which is not even listed as a way to do it in the
RFC).

My aim is to just bring out gaps that are very clearly visible. I have
no aim to offend anyone.

Thanks,
Vishwas

>>>>> You're right I guess there's ambiguity as to whether immediate is
>>>>> referring to data-plane or control-plane.
>>>>>
>>>>> Regards,
>>>>> Reshad.
>>>>>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 11:15:42 -0700

Hi Lou,

I really appriciate your prompt replies.

But by saying that we can overlook all sentences without a MUST/
SHOULD is opening a can of worms. In that case you may have to put in
MUST and SHOULD in a lot of places in the RFC.

I agree the BGP RFC does not mention TTL (it is a totally self
contained RFC) but RFC 3473 updates RFC3209. If there is no update
that means the behavior of RFC3209 holds good.

Am I totally off the mark?

Also I have made the TTL statement IPv6 friendly in the RSVP-TE IPv6
draft I have written which now talks of it as Hop Limit. Please do
have a look at it and comment on it.

Thanks,
Vishwas