Subject: Re: [CCAMP] Hello Message

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 16:51:32 -0400

In message <[email-masked]>
Lou Berger writes:
>  
> 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

Except as modified by GTSM?  Oops - did I just compound the confusion?

It seems perfectly clear to me.

Curtis

> On 4/25/2010 8:50 PM, Vishwas Manral wrote:
> > 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
> > 
> > On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman)
> > <[email-masked]> wrote:
> >> 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,
> >>
> >> In GMPLS in the control plane the immediate neighbors may be more than
> >> one IP Hop away.
> >>
> >> Thanks,
> >> Vishwas
> >>
> >> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman)
> >> <[email-masked]> wrote:
> >>> 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,
> >>>
> >>> 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
> >>> _______________________________________________
> >>> CCAMP mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>
> >>
> > _______________________________________________
> > CCAMP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ccamp
> > 
> > 
> > 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Thu, 06 May 2010 17:46:28 -0400

Curtis,

If there are GTSM specific implications, e.g., to negotiate when GTSM is 
to be used, they need to be in a GTSM specific document...

Lou

On 5/6/2010 4:51 PM, Curtis Villamizar wrote:
> In message<[email-masked]>
> Lou Berger writes:
>>
>> Vishwas,
>>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 23:04:14 -0400

In message <[email-masked]>
Lou Berger writes:
>  
> Curtis,
>  
> If there are GTSM specific implications, e.g., to negotiate when GTSM
> is to be used, they need to be in a GTSM specific document...
>  
> Lou

Lou,

GTSM can be used on any protocol.  That is the "G" in it.

RFC 5082:

  2.1.  GTSM Negotiation

   This document assumes that, when used with existing protocols, GTSM
   will be manually configured between protocol peers.  That is, no
   automatic GTSM capability negotiation, such as is provided by RFC
   3392 [RFC3392], is assumed or defined.

If both ends of the RSVP-TE adjacency are in the same admin domain,
just configure it.  Is so, it does change the TTL value, which is what
was being discussed.  The above paragraph acknowledges currrent
practice.

Curtis

---

From: Lou Berger <[email-masked]>
Date: Fri, 07 May 2010 09:01:10 -0400

I was referring to the last paragraph in the same section:

    Also note that this specification does not offer a generic GTSM
    capability negotiation mechanism, so messages of the protocol
    augmented with the GTSM behavior will need to be used if dynamic
    negotiation is deemed necessary.

Lou

On 5/6/2010 11:04 PM, Curtis Villamizar wrote:
> In message<[email-masked]>
> Lou Berger writes:
>>
>> Curtis,
>>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 May 2010 10:16:05 -0400

Lou,

GTSM has been used for a long time and no one who has deployed GTSM
has been begging for a GTSM negociation protocol.  So I'm questioning
whether it is really needed.

Curtis