Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

From: Markus Jork <[email-masked]>
Date: Fri, 20 Jul 2012 22:06:39 -0400

I have reviewed draft-pdutta-mpls-tldp-hello-reduce-03 and have some concerns and suggestions.	

I believe the draft would benefit from a more rigorous definition and examination of its proposed procedures. RFC 5036 has the basic assumption that an LDP session with a peer has at least one or more hello adjacencies. It is not entirely clear to me whether the draft proposes to maintain this rule or to change it by no longer requiring the existence of a hello adjacency to maintain the LDP session.

Most sections of the draft seem to imply that the hello adjacency continues to exist once the infinite hold time has been agreed upon. That is suggested by statements like this:

>   After the
>   session is operational the periodic Targeted Hellos between the LSRs
>   become redundant, as session Keepalives in turn serves the intent of
>   each LSR to maintain its adjacency to its peer.

But when the hello adjacency continues to exist, that means each side can send an updated hello message at any time. That hello could request a short hold time again which is in apparent contradiction to the draft's claim that it helps mitigate DoS attacks based on spurious hellos.

I believe the draft should define the exact nature and extent of the hello adjacency:
- does it really continue to exist after the hold time is set to infinite?
- is it maintained by the fact that the LDP session still exists?
- is it maintained because the hold time is infinite and thus it actually will never cease to exist at all?
- does the loss of the LDP session trigger the deletion of the hello adjacency or does it just modify the nature of the hello adjacency?
- what is the treatment of new hello messages received after the targeted LDP hello reduction has been negotiated (i.e. the hold time is infinite)? 

Once this is done, I think various implications will become clearer and might expose problems. The hello adjacency does not just exist to enable the initial bring-up of the LDP session and to check connectivity to the peer. It also conveys other information such as configuration changes.

At this time, without further clarification of the procedures, I am concerned that the draft would cause an overall decrease in robustness of the LDP protocol.

Apart from these technical concerns, I also wonder about the need for this draft. Reducing signaling overhead to improve scaling is generally a good thing. However, sending of UDP hellos is not typically a pain point as there are well known implementation techniques to deal with that. And if reducing the hellos involves changes to the well established and proven LDP protocol machinery, then I'm kind of doubtful that it's worth it.

-Markus

_____________________________________________
From: Ross Callon 
Sent: Tuesday, July 17, 2012 2:50 PM
To: Markus Jork; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Ross Callon; Martin Vigoureux; Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau
Subject: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Markus, Lizhong, Thomas;

You have been selected as an MPLS Review team reviewers for
draft-pdutta-mpls-tldp-hello-reduce-03

Note to authors: You have been CC'd on this email so that you can know that 
this review is going on. However, please do not review your own document. 

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is
the document technically sound?  We are interested in knowing whether the 
document is ready to be considered for WG adoption (ie, it doesn't have to
be perfect at this point, but should be a good start). 
 
Reviews should be sent to the document authors, WG co-chairs and secretary,
and CC'd to the MPLS WG email list. If necessary, comments may be sent 
privately to only the WG chairs. 
 
Are you able to review this draft by August 3, 2012 (ie, the end of the IETF 
meeting in Vancouver)? We understand that this is somewhat short notice and  
that you might have something else to do the week of the IETF, so let us 
know if you need slightly more time. 
 
Thanks, Ross
(as MPLS WG chair)

PS: I noticed that Tom Nadeau's email address listed in the draft is out of date. This email is being CC'd to his updated address.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sun, 22 Jul 2012 05:46:40 +0530

Please find the responses line. Please let me know if I had answered all concerns and if further clarification needed.

Thanks,
Pranjal

-----Original Message-----
From: Markus Jork [mailto:[email-masked]] 
Sent: Friday, July 20, 2012 7:07 PM
To: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Cc: [email-masked]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

<Pranjal> Thanks for review and your suggestions. </Pranjal>

<Pranjal> This draft does not change or violate procedures defined in RFC 5036. It proposes an OPTIONAL method of reduction of "targeted' hellos (only - as the name of the draft suggests) and the proposed method is backward compatible with procedures defined in RFC 5036. The method uses the hello timeout negotiation procedures as per RFC 5035 without any changes in negotiation procedures.

The method proposed in the draft reduces the hellos (precisely the rate of hellos) required to be exchanged periodically to maintain the hello adjacency between two targeted peering LSRs. Hello adjacencies are maintained as is as per RFC 5035. There can be only one targeted adjacency to a peer. If one t-ldp peer supports the hello reduction procedures but the other peer does not, then the procedures result in no hello reduction and state of LDP session, adjacency remain as defined in RFC 5036. Implementations supporting the hello reduction procedures in the draft have been deployed with non-compatible peering implementations.  </Pranjal>

>   each LSR to maintain its adjacency to its peer.

<Pranjal> That is correct. Hello adjacencies continue to exist. </Pranjal>

<Pranjal> That is correct. Hellos are connection less and a peer MAY update the hello message anytime and any of its parameters (configSeqNum, Hello HoldTime etc). If we refer to RFC 5036 procedures of Hello negotiations, respective timers (both hello tx and adj timeout) would get re-adjusted by both peers if any of the participating peers decide to change the hold time
On the fly.

This draft does not claim to prevent DoS attacks (It can't!). The reduction of hellos provides probabilistically better resiliency on maintenance of hello adjacency during sporadic DoS attacks. Sporadic DoS attacks on UDP port 646 can result in loss of "good" hello packets for certain period of time and thus leading to loss of existing adjacencies. We can certainly claim that it is "implementation specific" and implementations can do proper flow control of existing hello adjacencies (up and running) with H/w assisted flow control/filtering etc and penalizing only the hellos classified as "culprit" by such techniques. The draft does not keep a uniform view of LDP "implementations". I wouldn't intend to go too deep into various proven techniques already out there for years, but note that there are various cost functions associated with such techniques. Not all kinds of systems/implementations would like to implement such H/w assisted techniques. There could be systems that interfaces with large number of t-ldp peerings in mobility backhauls or access/aggregation networks(e.g 10K t-ldp peers) but does not need to deliver core data path functionalities (number of ldp tunnels, pseudowires per t-ldp peering are relatively small)
and so is the h/w assisted supported for faster hellos. </Pranjal>

<Pranjal> Yes, we can clarify that in detail in the draft. I agree that it may not be apparent that RFC 5035 procedures are retained as is. The Hello adjacencies continue to exist "as is" as per RFC 5036.  </Pranjal>

<Pranjal> That's correct. If hello adjacencies exist then sessions would continue to exist as long as session "keeplives" keep the sessions alive. </Pranjal> 

<Pranjal> It depends on case by case. The draft doesn't say that implementation is MANDATORY. For example when transport address of the 
LDP session is different from the IP addresses used to exchange t-ldp hellos, then probably it is not RECOMMENDED to use hello reduction procedures, since sessions keepallives are not really substitute of "reachability". The draft intends to provide generic building block.

</Pranjal>

<Pranjal> This draft does not differ from RFC 5036 on this aspect. However 
Hello reduction procedures would restart (would fall back to hold time as 
Configured in peers) when there is loss of session or loss of adjacency. Thus the procedures allow fast/aggressive hello timers to be configured in 
large scale deployments (5K T-LDP peers) for faster discovery/session set-up,  but results in reduced hellos while sessions/adjacencies are being maintained. Section 4 point 3 mentions that hello reduction procedures start only after LDP session is established. 

Further section 4 states below:

"4. If the LDP session between two LSRs fails leading to tearing down
      of adjacency, then each LSR reverts to advertising their
      configured hello hold time and repeats procedure 1 to 3."

</Pranjal>

<Pranjal> It would help if you could clarify what is meant by "new hellos". 
AFAIK, there can be only one targeted hello adjacency with a t-ldp peer that 
is identified by a unique LDP LSR-ID. The procedures does not apply to link 
Hello adjacencies since link hellos are continued to be sent over an interface at "configured rate" in order to keep discovering new hellos/peers over a broadcast interface. 
</Pranjal>

<Pranjal> The draft does not say that any updates in hellos must not be reflected while reduction is in process. A t-ldp peer can reflect the any changes in hello parameters immediately and that doesn't break hello reduction if already in progress.  We can clarify that in the draft.  An update in config seq number doesn't necessitate that configured hold time be re-advertised rather than reduced hold time (reached at the time of change), unless the configured hold time itself is changed. If configured hold time is changed, the procedures can be restarted by advertising the updated hello hold time by the t-ldp peer.
        
</Pranjal>

<Pranjal> Hello reduction procedures are working in production networks with compatible and non-compatible implementations. Since you are raising 
the question of "decrease in robustness of the LDP protocol", it would be great if you could precisely lay down the issues, algorithms in RFC 5036 
that are violated by this draft that would lead to degraded LDP. The draft further says that the procedures are OPTIONAL. In order to participate in hello reduction both t-ldp peers need to support the reduction procedures but when there is asymmetric case the procedures fall back to as described in RFC 5036. The draft is simply using hello timer negotiation techniques as defined in RFC 5036 to achieve reduction. In the draft we didn't intend to 
re-describe the Hello Negotiation procedures in RFC 5036 since it makes a 
normative reference to the latter anyway. 

</Pranjal>

<Pranjal> I would like to re-iterate the fact that the draft doesn't introduce any "new" negotiation procedures to achieve hello reduction. 
It "reuses" the hello reduction procedures as per RFC 5036 and thus it is 
backward compatible. I already mentioned that the draft does not take uniform view of LDP implementations. 

Excepts from the draft - 

   "large number of LDP sessions (in thousands) to targeted peers, it
   is an additional burden to send and receive Targeted Hellos for all
   peers at periodic intervals. In MPLS deployments at access or
   mobility backhaul, there can be very large volume of LDP sessions
   with targeted LDP adjacencies. Moreover additional mechanisms such as
   centralized BFD [BFD] may be used to track liveliness of ldp
   sessions."

When there are deployments that can use BFD to track T-LDP peers, the Hellos 
become almost redundant after initial discovery and session set-up. It is definitely a pain when you configure aggressive hello timers for faster session set-up (which is a mandate in certain deployments for fast failure recovery with ~ 10K t-ldp peers after a network outage) and yet need to maintain the adjacencies thru hellos when BFD (or likewise) techniques are used to track reachability of existing adjacencies "after" adjacencies are formed. While it can be still be achieved by sending aggressive hellos at start but with larger hold time (thus both peer would have a very large timeout), but note that aggressive timeouts are desirable as well to tear down spurious hellos ASAP.

</Pranjal> 

-Markus

Markus, Lizhong, Thomas;

 

Thanks, Ross
(as MPLS WG chair)

---

From: Markus Jork <[email-masked]>
Date: Sun, 22 Jul 2012 22:42:27 -0400

Pranjal,

Thanks for your detailed response. The section on DoS attacks in the draft caused some doubts for me whether you are really going to keep the hello adjacency in place or whether you were planning to drop hello messages (after agreeing on infinite hold time). Your answer now clarifies that each side can send an updated hello message at any time. So I believe that addresses my concerns which were mostly about what happens when one side has a configuration change.

There is one scenario not mentioned in the draft that might be good to at least acknowledge: in addition to the one targeted hello adjacency for which the hello reduction is applied, there could also be any number of link adjacencies (without hello reduction of course) between the same pair of peers at the same time. The way the draft is worded suggests that it is not really considering that case. However, I can't really think of a problem with that right now.

-Markus

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]] 
Sent: Saturday, July 21, 2012 8:17 PM
To: Markus Jork; Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Cc: [email-masked]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Thanks,
Pranjal

-----Original Message-----
From: Markus Jork [mailto:[email-masked]]
Sent: Friday, July 20, 2012 7:07 PM
To: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Cc: [email-masked]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

<Pranjal> That is correct. Hellos are connection less and a peer MAY update the hello message anytime and any of its parameters (configSeqNum, Hello HoldTime etc). If we refer to RFC 5036 procedures of Hello negotiations, respective timers (both hello tx and adj timeout) would get re-adjusted by both peers if any of the participating peers decide to change the hold time On the fly.

This draft does not claim to prevent DoS attacks (It can't!). The reduction of hellos provides probabilistically better resiliency on maintenance of hello adjacency during sporadic DoS attacks. Sporadic DoS attacks on UDP port 646 can result in loss of "good" hello packets for certain period of time and thus leading to loss of existing adjacencies. We can certainly claim that it is "implementation specific" and implementations can do proper flow control of existing hello adjacencies (up and running) with H/w assisted flow control/filtering etc and penalizing only the hellos classified as "culprit" by such techniques. The draft does not keep a uniform view of LDP "implementations". I wouldn't intend to go too deep into various proven techniques already out there for years, but note that there are various cost functions associated with such techniques. Not all kinds of systems/implementations would like to implement such H/w assisted techniques. There could be systems that interfaces with large number of t-ldp peerings in mobility backhauls or access/aggregation networks(e.g 10K t-ldp peers) but does not need to deliver core data path functionalities (number of ldp tunnels, pseudowires per t-ldp peering are relatively small) and so is the h/w assisted supported for faster hellos. </Pranjal>

<Pranjal> It depends on case by case. The draft doesn't say that implementation is MANDATORY. For example when transport address of the LDP session is different from the IP addresses used to exchange t-ldp hellos, then probably it is not RECOMMENDED to use hello reduction procedures, since sessions keepallives are not really substitute of "reachability". The draft intends to provide generic building block.

</Pranjal>

<Pranjal> This draft does not differ from RFC 5036 on this aspect. However Hello reduction procedures would restart (would fall back to hold time as Configured in peers) when there is loss of session or loss of adjacency. Thus the procedures allow fast/aggressive hello timers to be configured in large scale deployments (5K T-LDP peers) for faster discovery/session set-up,  but results in reduced hellos while sessions/adjacencies are being maintained. Section 4 point 3 mentions that hello reduction procedures start only after LDP session is established. 

</Pranjal>

<Pranjal> It would help if you could clarify what is meant by "new hellos". 
AFAIK, there can be only one targeted hello adjacency with a t-ldp peer that is identified by a unique LDP LSR-ID. The procedures does not apply to link Hello adjacencies since link hellos are continued to be sent over an interface at "configured rate" in order to keep discovering new hellos/peers over a broadcast interface. 
</Pranjal>

        
</Pranjal>

<Pranjal> Hello reduction procedures are working in production networks with compatible and non-compatible implementations. Since you are raising the question of "decrease in robustness of the LDP protocol", it would be great if you could precisely lay down the issues, algorithms in RFC 5036 that are violated by this draft that would lead to degraded LDP. The draft further says that the procedures are OPTIONAL. In order to participate in hello reduction both t-ldp peers need to support the reduction procedures but when there is asymmetric case the procedures fall back to as described in RFC 5036. The draft is simply using hello timer negotiation techniques as defined in RFC 5036 to achieve reduction. In the draft we didn't intend to re-describe the Hello Negotiation procedures in RFC 5036 since it makes a normative reference to the latter anyway. 

</Pranjal>

<Pranjal> I would like to re-iterate the fact that the draft doesn't introduce any "new" negotiation procedures to achieve hello reduction. 
It "reuses" the hello reduction procedures as per RFC 5036 and thus it is backward compatible. I already mentioned that the draft does not take uniform view of LDP implementations. 

Excepts from the draft - 

When there are deployments that can use BFD to track T-LDP peers, the Hellos become almost redundant after initial discovery and session set-up. It is definitely a pain when you configure aggressive hello timers for faster session set-up (which is a mandate in certain deployments for fast failure recovery with ~ 10K t-ldp peers after a network outage) and yet need to maintain the adjacencies thru hellos when BFD (or likewise) techniques are used to track reachability of existing adjacencies "after" adjacencies are formed. While it can be still be achieved by sending aggressive hellos at start but with larger hold time (thus both peer would have a very large timeout), but note that aggressive timeouts are desirable as well to tear down spurious hellos ASAP.

</Pranjal> 

-Markus

Markus, Lizhong, Thomas;

 

Thanks, Ross
(as MPLS WG chair)

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 23 Jul 2012 08:18:50 +0530

Hi Markus,
            Thanks for your response. I agree that in its current state the draft does not clarify about non-applicability of the proposed method on link adjacencies associated with the t-ldp peering session. We would explicitly clarify all the points mentioned in by your review. Thanks again for the detailed review.

Cheers,
Pranjal

-----Original Message-----
From: Markus Jork [mailto:[email-masked]]
Sent: Sunday, July 22, 2012 7:42 PM
To: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Cc: [email-masked]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Pranjal,

-Markus

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Saturday, July 21, 2012 8:17 PM
To: Markus Jork; Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Cc: [email-masked]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Thanks,
Pranjal

-----Original Message-----
From: Markus Jork [mailto:[email-masked]]
Sent: Friday, July 20, 2012 7:07 PM
To: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Cc: [email-masked]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

</Pranjal>

</Pranjal>

</Pranjal>

</Pranjal>

Excepts from the draft -

</Pranjal>

-Markus

Markus, Lizhong, Thomas;

Thanks, Ross
(as MPLS WG chair)

---

From: Lizhong Jin<[email-masked]>
Date: Mon, 23 Jul 2012 17:12:36 +0800

Hi all,
I've reviewed this draft, and have two comments that need to be clarifed:
1. Target Hello tracks the liveness of hello adjacency, while LDP 
keepalive tracks the liveness of session. Do you mean it is not necessary 
to track the liveness of hello adjacency, or substitute it with liveness 
tracking of session? Hello address maybe different with trasport address.
2. Target hellos are not only used for liveness track, but also parameter 
negotiation and updating. When negotiated to infinite, what time interval 
would be used to send the updated hello (e.g, hello with new Optional 
Parameters in potential draft-pdutta-mpls-ldp-adj-capability) message? UDP 
hello is not reliable, would be renegotiated to configured hello hold time 
first?

Summary of review:
a. whether the document is coherent?
Good description on the motivation, need more detail in technical 
description (e.g, refer to my second comment).

b. is it useful? 
Yes.

d. is technically sound ?
Need some clarification.

e. is ready to be considered for WG adoption ?
After clarification, it should be ready for WG adoption.

Regards
Lizhong

Ross Callon <[email-masked]> wrote 2012/07/18 05:49:55:

> Note to authors: You have been CC’d on this email so that you can know 
that 
> document is ready to be considered for WG adoption (ie, it doesn’t have 
to
> and CC’d to the MPLS WG email list. If necessary, comments may be sent 

> PS: I noticed that Tom Nadeau’s email address listed in the draft is
> out of date. This email is being CC’d to his updated address. 
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 23 Jul 2012 17:04:08 -0400

Pranjal> This draft does not change or violate procedures defined in RFC
Pranjal> 5036. It proposes an OPTIONAL method of reduction of "targeted'
Pranjal> hellos (only - as the name of the draft suggests) and the proposed
Pranjal> method is backward compatible with procedures defined in RFC
Pranjal> 5036. The method uses the hello timeout negotiation procedures as
Pranjal> per RFC 5036 without any changes in negotiation procedures.

If the draft does not change any of the procedures specified in RFC 5036,
and does not define any new procedures or messages either, then why is the
draft marked as "standards track"?  At best it would be "Informational".
But are you saying that all the draft really does is to suggest that a
particular parameter be set to a particular value?  That doesn't seem like
very much content.

Pranjal> The reduction of hellos provides probabilistically better
Pranjal> resiliency on maintenance of hello adjacency during sporadic DoS
Pranjal> attacks. Sporadic DoS attacks on UDP port 646 can result in loss of
Pranjal> "good" hello packets for certain period of time and thus leading to
Pranjal> loss of existing adjacencies.

If an attacker can send you UDP packets on port 646, why doesn't he make
them look like Hello packets specifying a short hold time?  That's a much
more effective attack than a "sporadic DoS attack".  In fact, if real Hellos
are not being sent at all, it just becomes easier to mount an attack with a
spoofed Hello.  An attacker could send a spoofed Hello with a hold time of 3
days, and the session would stay up for a few days and then fail
mysteriously, for no apparent reason.  An attack whose effects are not felt
until days later can be quite hard to deal with.  When the Hellos are sent
periodically, on the other hand, there is a self-correction mechanism that
prevents this.

If you want to reduce the targeted Hello load, it might be better to invent
a way (i.e., a protocol change) of turning them off entirely after the
session comes up, so that arriving Hellos are just discarded.  (

BTW, the draft asserts that the periodic Hellos have no value that is not
better served by either BFD or the LDP session keepalives.  I don't know
whether that's true, but it would be nice to see an argument with a little
more substance.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 04:15:45 +0530

Please find my answers further inline.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Monday, July 23, 2012 2:04 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Markus Jork; Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN); [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

[Pranjal] The version 00 was informational. It was made to standards track as per feedback received from WG IETF-SFO. Although the draft re-uses the 
Hello negotiation method as in RFC 5036, it does define procedures for 
reduction (section 4). I am OK if majority votes for Informatonal.
[/Pranjal]

spoofed Hello.  

[Pranjal] When I said UDP packets in port 646 it was not meant to be non-Hello packets - it was meant to be any packet in port 646 that includes LDP Hello Packet (parser won't say bad_msg) or any garnage UDP payload. Sporadic floods of good LDP Hellos are tantamount to DoS attack. If such a flood comes from an "existing" adjacency then one solution could be rate limiting on existing adjacencies (there are several established techniques). If an implementation doesn't have such techniques (e.g h/w assisted) then it is possible that such attacks from one peer may bring down other adjacencies, if the hold time of other adjacencies are relatively small. The draft does not claim as solution for DoS prevention but for probabilistically better resilience on sporadic attacks. [/Pranjal]

An attacker could send a spoofed Hello with a hold time of 3

[Pranjal] Could you elaborate in more details what self-correction means in this context? If we read the section 4, it mentions that Hello Reduction starts only after a LDP session is ESTABLISHED. There are additional well known security methods to secure LDP session (e.g TCP MD5). Do you mean to say that a peer to which we may be running a trusted LDP session can be 
considered as spoof? Well, nobody can prevent a trusted peer not to do spoofing with hellos (hide-and-seek), if the peer administration decided to do so but the draft doesn't claim solution for such spoofing. If there is 
a trusted peer and hello reduction procedures set the holdtime as 3 days
And the session is lost then hello reduction terminates immediately. This 
Is mentioned clearly in point 4 in section 4. Then I don't see your point 
how a spoofed hello adjacency stays up for 3 days. 

[Pranjal] We may not like to do that due to backward compatibility with RFC 5036, unless we say that T-LDP Hellos are deprecated. However, I think there are vendor implementations (at least one vendor I am aware of) that does LDP session protection with T-LDP hellos while link adjacencies to same peer may get lost for a short window. Thus it may not be a sound approach to get rid of T-LDP Hellos. [/Pranjal].

[Pranjal] It depends on case by case. If LDP session transport address is 
different from IP addresses used for T-LDP hellos then Session Keepalives are not substitute. But if we want to use protocols like BFD for fast tracking reachability of T-LDP IPs (there are other protocols as well) then Hellos are redundant. If any Hello param are changed during the life time 
of a adjacency then hellos can be exchanged immediately to reflect the change keeping reduced hold time intact and draft does not prevent it from doing so (corrective action). I would like to hear opposing side of the argument that claims the period fast T-LDP hellos are mandatory for proper functioning of LDP as a protocol and need to quantify the "fastness".  [/Pranjal]

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 08:07:54 +0530

Hi Lizhong,
                  Thanks for review. Please refer my answers inline.

Cheers,
Pranjal
________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 23, 2012 2:13 AM
To: Dutta, Pranjal K (Pranjal); [email-masked]; Thomas Nadeau; Giles Heron
Cc: [email-masked]; VIGOUREUX, MARTIN (MARTIN); Markus Jork; Ross Callon; [email-masked]; [email-masked]
Subject: Re: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Hi all,
I've reviewed this draft, and have two comments that need to be clarifed:
1. Target Hello tracks the liveness of hello adjacency, while LDP keepalive tracks the liveness of session. Do you mean it is not necessary to track the liveness of hello adjacency, or substitute it with liveness tracking of session? Hello address maybe different with trasport address.

[Pranjal]  It depends on case by case. For example when transport address of the LDP session is different from the IP addresses used to exchange t-ldp hellos, then probably it is not RECOMMENDED to use hello reduction procedures, since sessions keepallives are not really substitute of "reachability" or "liveliness" of the adjacency. Alternately it is possible to track the reachability of t-ldp sources by means of other fast protocols (e.g BFD and others etc).
In such a case, the t-ldp hellos could be redundant after initial discovery done and session set-up is complete. When peers are asymmetric w.r.t hello reduction support (one peer supports while the other does not), then the situation falls back to what we have with RFC 5036.

2. Target hellos are not only used for liveness track, but also parameter negotiation and updating. When negotiated to infinite, what time interval would be used to send the updated hello (e.g, hello with new Optional Parameters in potential draft-pdutta-mpls-ldp-adj-capability) message? UDP hello is not reliable, would be renegotiated to configured hello hold time first?

[Pranjal] An updated hello can be sent at any time (whenever any param is changed to reflect the change to peer) without any changes in "current"
hold time (e.g infinite) that was advertised in the last hello message. Means it is not necessary to fallback to configured hold time and restart the reduction process (in fact not desirable). For example, it could be changes in one or more hello adjacency capabilities as described in the aforementioned draft or could be any of the existing standard params such as configSeqNum etc. Since hellos are not reliable, after any parameter change an implementation
may send a set of hellos (let's say 5) at configured intervals (or faster) to reflect the change. But those hellos would continue to advertise infinite hold time
and would fall back to reduced rate after those 5 packets are sent.

However, changes like IPV4 or IPV6 transport address etc may restart the session that can result in starting hello reduction from scratch.

I agree that in its current state draft doesn't describe the solution and its flexibilities in adequate detail. We would definitely address those.

Summary of review:
a. whether the document is coherent?
Good description on the motivation, need more detail in technical description (e.g, refer to my second comment).

b. is it useful?
Yes.

Regards
Lizhong

Ross Callon <[email-masked]> wrote 2012/07/18 05:49:55:

> PS: I noticed that Tom Nadeau's email address listed in the draft is
> out of date. This email is being CC'd to his updated address.
>

---

From: Lizhong Jin<[email-masked]>
Date: Tue, 24 Jul 2012 16:17:04 +0800

Hi Pranjal,
Thanks for the prompt response. See inline below.

Regards
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 
2012/07/24 10:37:54:

> Cc: [email-masked]; VIGOUREUX, MARTIN (MARTIN); Markus Jork; Ross Callon;
> [email-masked]; [email-masked]
> keepalive tracks the liveness of session. Do you mean it is not 
> necessary to track the liveness of hello adjacency, or substitute it
> with liveness tracking of session? Hello address maybe different 
> with trasport address. 
> 
> [Pranjal]  It depends on case by case. For example when transport 
> address of the LDP session is different from the IP addresses used 
> to exchange t-ldp hellos, then probably it is not RECOMMENDED to use
> hello reduction procedures, since sessions keepallives are not 
> really substitute of "reachability" or “liveliness” of the 
> adjacency. Alternately it is possible to track the reachability of 
> t-ldp sources by means of other fast protocols (e.g BFD and others etc). 

> In such a case, the t-ldp hellos could be redundant after initial 
> discovery done and session set-up is complete. When peers are 
> asymmetric w.r.t hello reduction support (one peer supports while 
> the other does not), then the situation falls back to what we have 
> with RFC 5036.
[Lizhong] My concern is tracking of T-LDP hello source address by BFD or 
LDP session (on condition that transport address is same as hello address) 
could not substitue the liveness of the UDP connection of hello adjacency. 
For example, when LDP session is setup, and hello adjacency has negotiated 
to infinite time, althought the hello address is IP reachable, but if UDP 
port '646' is incorrectly closed or some other UDP problem accured, the 
hello adjacency in fact is down, but you could not detect this with 
infinite hold time. Then I mean hello reduction should be used with 
caution that the UDP will not accure any potential problem. Maybe I missed 
something.

> 
> 
> 2. Target hellos are not only used for liveness track, but also 
> parameter negotiation and updating. When negotiated to infinite, 
> what time interval would be used to send the updated hello (e.g, 
> hello with new Optional Parameters in potential draft-pdutta-mpls-
> ldp-adj-capability) message? UDP hello is not reliable, would be 
> renegotiated to configured hello hold time first? 
> 
> [Pranjal] An updated hello can be sent at any time (whenever any 
> param is changed to reflect the change to peer) without any changes 
> in “current” 
> hold time (e.g infinite) that was advertised in the last hello 
> message. Means it is not necessary to fallback to configured hold 
> time and restart the reduction process (in fact not desirable). For 
> example, it could be changes in one or more hello adjacency 
> capabilities as described in the aforementioned draft or could be 
> any of the existing standard params such as configSeqNum etc. Since 
> hellos are not reliable, after any parameter change an implementation 
> may send a set of hellos (let’s say 5) at configured intervals (or 
> faster) to reflect the change. But those hellos would continue to 
> advertise infinite hold time
[Lizhong] It is clear now, thank you.

> 
> However, changes like IPV4 or IPV6 transport address etc may restart
> the session that can result in starting hello reduction from scratch. 
> 
> I agree that in its current state draft doesn’t describe the 
> solution and its flexibilities in adequate detail. We would 
> definitely address those.
[Lizhong] Thank you.

> > Note to authors: You have been CC’d on this email so that you can 
know that 
> > document is ready to be considered for WG adoption (ie, it doesn’t 
have to

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Tue, 24 Jul 2012 15:52:15 +0000

Dear authors,

I've couple of comments:

1) I also have a concern along the same lines as stated by Lizhong:

>> Target Hello tracks the liveness of hello adjacency, while LDP keepalive tracks the liveness of session. Do you mean it is not necessary to track the liveness of hello adjacency, >> or substitute it with liveness tracking of session?

The reduction of T-LDP hellos may cause issues for targeted-adjacencies related to forwarding interfaces [ e.g. LDP over TE tunnel ]. LDP requires an adjacency to be **live** on an interface before MPLS [labeled] forwarding can be setup on the given forwarding interface. If we are using LDP-enabled TE tunnel as forwarding interface, then typically we install unlabeled (LDP) forwarding over TE tunnel interface if LDP's t-adj over TE tunnel goes down. With T-LDP reduction, we lose the ability to track the liveness of the t-adj and will be incorrectly using [labeled] LDP LSP over TE tunnel in the forwarding even when there are issues with this t-adj.

2) Re: "DoS attacks" as motivation for the tldp-reduc:
Your document states that:

"Unlike TCP sessions it is not always possible to

   provide per peer protection for UDP based hellos."

Given new procedures/draft on LDP hello auth (i.e. draft-zheng-mpls-ldp-hello-crypto-auth),
the above does not seem valid anymore, and hence is not a strong argument to support tldp-reduc, IMO.

Rgds,

-- Kamran

From: Lizhong Jin <[email-masked]<mailto:[email-masked]>>
Date: Mon, 23 Jul 2012 17:12:36 +0800
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Thomas Nadeau <[email-masked]<mailto:[email-masked]>>, Giles Heron <[email-masked]<mailto:[email-masked]>>
Cc: Ross Callon <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Hi all,

Summary of review:

b. is it useful?
Yes.

Regards
Lizhong

Ross Callon <[email-masked]<mailto:[email-masked]>> wrote 2012/07/18 05:49:55:

> Note to authors: You have been CC’d on this email so that you can know that
> document is ready to be considered for WG adoption (ie, it doesn’t have to
>   _______________________________________________ mpls mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 21:40:31 +0530

Pls. refer my answers inline.

________________________________
From: Kamran Raza (skraza) [mailto:[email-masked]]
Sent: Tuesday, July 24, 2012 8:52 AM
To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]; Thomas Nadeau; Giles Heron (giheron)
Cc: Ross Callon
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Dear authors,

I've couple of comments:

[Pranjal] Such liveliness can be tracked by running BFD over RSVP. I mentioned that the hello reduction procedures can be deployed case by case and
Is not mandatory. Did we mention in the draft that hello reduction is MUST for LdpoRsvp deployments? There are several cases in access,. Aggregation
Networks where LdpoRsvp is not deployed.

[Pranjal] Not sure what is the point you are raising here. What about DoS attacks in networks from untrusted peers? How would you provide resilience
to existing trusted peer adjacencies (that is using ldp-crypto-auth) from spoofed attacks (without special techniques)? The draft does not claim  as a
solution against DoS attacks but probabilistically better resilience.

Rgds,

-- Kamran

Hi all,

Summary of review:

b. is it useful?
Yes.

Regards
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 21:52:42 +0530

Hi Lizhong,

[Lizhong] My concern is tracking of T-LDP hello source address by BFD or LDP session (on condition that transport address is same as hello address) could not substitue the liveness of the UDP connection of hello adjacency. For example, when LDP session is setup, and hello adjacency has negotiated to infinite time, althought the hello address is IP reachable, but if UDP port '646' is incorrectly closed or some other UDP problem accured, the hello adjacency in fact is down, but you could not detect this with infinite hold time. Then I mean hello reduction should be used with caution that the UDP will not accure any potential problem. Maybe I missed something.

Yes, you are correct. If there is a bug in S/w that closes port 646 accidentally and then with hello reduction it would take long time to detect. But if a port 646 is closed accidently by a peer but without gracefully shutting down LDP session then don't we already have a bigger problem? In that way we can contest
against many solutions that has a bottom line for resilience against bugs. This is a good point you raised and we would mention it explicitly in the draft. Note
that when LDP is deployed in large scale MPLS access, aggregation, seamless MPLS etc the priority is resilience for adjacencies. There are special
techniques that an implementation can adopt (e.g H/w assisted) to provide such resilience but there are cost functions associated with and we may not
be able to take uniform view of LDP in general.

Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Tuesday, July 24, 2012 1:17 AM
To: Dutta, Pranjal K (Pranjal)
Cc: Giles Heron; [email-masked]; VIGOUREUX, MARTIN (MARTIN); Markus Jork; [email-masked]; Ross Callon; [email-masked]; [email-masked]; Thomas Nadeau
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Hi Pranjal,

Regards
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 2012/07/24 10:37:54:

> really substitute of "reachability" or "liveliness" of the
[Lizhong] My concern is tracking of T-LDP hello source address by BFD or LDP session (on condition that transport address is same as hello address) could not substitue the liveness of the UDP connection of hello adjacency. For example, when LDP session is setup, and hello adjacency has negotiated to infinite time, althought the hello address is IP reachable, but if UDP port '646' is incorrectly closed or some other UDP problem accured, the hello adjacency in fact is down, but you could not detect this with infinite hold time. Then I mean hello reduction should be used with caution that the UDP will not accure any potential problem. Maybe I missed something.

> in "current"
> may send a set of hellos (let's say 5) at configured intervals (or

> I agree that in its current state draft doesn't describe the
[Lizhong] Thank you.

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Tue, 24 Jul 2012 16:31:05 +0000

Hi Pranjal,

>> Such liveliness can be tracked by running BFD over RSVP
But BFDoRSVP will be able to detect TE tunnel issues only, but not necessarily LDP's t-hello issues over TE tunnel.
What if T-adj becomes invalid due to LDP config/events [ e.g. Remote node no more accepting t-hellos ] ?

>> Did we mention in the draft that hello reduction is MUST for LdpoRsvp deployments?
No, and I also did not claim that you did :-)
I  am just commenting that such procedure may cause issues  with T-LDP over fwding interfaces.

Rgds.

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 24 Jul 2012 21:40:31 +0530
To: "Syed Kamran Raza (skraza)" <[email-masked]<mailto:[email-masked]>>, Lizhong Jin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Nadeau <[email-masked]<mailto:[email-masked]>>, "Giles Heron (giheron)" <[email-masked]<mailto:[email-masked]>>
Cc: Ross Callon <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]<mailto:[email-masked]>; Thomas Nadeau; Giles Heron (giheron)

Dear authors,

I've couple of comments:

Rgds,

-- Kamran

Hi all,

Summary of review:

b. is it useful?
Yes.

Regards
Lizhong

Ross Callon <[email-masked]<mailto:[email-masked]>> wrote 2012/07/18 05:49:55:

> Are you able to review thisdraft by August 3, 2012 (ie, the end of the IETF

---

From: Eric Rosen <[email-masked]>
Date: Tue, 24 Jul 2012 12:36:40 -0400

> Although the draft re-uses the Hello negotiation method as in RFC 5036, it
> does define procedures for reduction (section 4).

I think the only thing that is new is the idea of configuring two hold
times, one to be used before the session is established and one (infinite)
to be used after.

> If we read the section 4, it mentions that Hello Reduction starts only
> after a LDP session is ESTABLISHED. There are additional well known
> security methods to secure LDP session (e.g TCP MD5).

The fact that the session is established does not provide authentication or
integrity for the Hellos.  There is no way to know that any particular
received Hello originated from the trusted peer, or that it has not been
modified, or that it is not a replay of an earlier Hello.  That is, the
security problems with Targeted Hellos are not mitigated by the fact that
the LDP session is secured.  So even after the session is established,
spoofed Hellos can be used to trick the two peers into using different hold
times.

Bad parameters specified in a received spoofed Hello will eventually get
overwritten by the good parameters specified in the next received authentic
Hello.  Thus the less frequent the authentic Hellos are, the longer it will
take before the bad parameter is overwritten with the good parameter.  

> If LDP session transport address is  different from IP addresses used for
> T-LDP hellos then Session Keepalives are not substitute. But if we want to
> use protocols like BFD for fast tracking reachability of T-LDP IPs (there
> are other protocols as well) then Hellos are redundant.

The draft seems to recommend the use of "hello reduction" with infinite hold
time.  If there are situations in which this is not a good idea, the draft
should describe those.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 22:08:50 +0530

Hi Kamran,
                        Please refer inline.

Thanks,
Pranjal

________________________________
From: Kamran Raza (skraza) [mailto:[email-masked]]
Sent: Tuesday, July 24, 2012 9:31 AM
To: Dutta, Pranjal K (Pranjal); Lizhong Jin; [email-masked]; Thomas Nadeau; Giles Heron (giheron)
Cc: Ross Callon
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Hi Pranjal,

[Pranjal] This is a missing  piece in RFC 5036 which IMO should be addressed separately. Even if we don't pursue infinite hold time
as per the draft it is still possible that t-ldp adjacency may become invalid for prolonged period when hello hold timers are relaxed
(e.g 180 sec etc). by RFC 5036 there is no upper bound on hello hold time and large scale deployments (e.g ~ 10K T-LDP peers) tend
to use relaxed hold time.

Rgds.

Dear authors,

I've couple of comments:

Rgds,

-- Kamran

Hi all,

Summary of review:

b. is it useful?
Yes.

Regards
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 22:29:49 +0530

Pls refer my answers inline.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2012 9:37 AM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; Markus Jork; Giles Heron; Thomas Nadeau; [email-masked]; VIGOUREUX, MARTIN (MARTIN); [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

[Pranjal] Yes that is correct. It describes RECOMMENDED procedures for hello reduction. [/Pranjal]

[Pranjal] Yes, agreed. That's where the applicability of ldp-crypto-auth comes in. But still we can't provide resilience of spurious attacks from 
non-trusted sources that may destabilize the authenticated existing hello adjacencies. We can definitely insert a full fledged firewall inside a LDP LSR so that Utopia prevails but we may not like to do that in all types of implementations (systems) where cost vs. gain factor is low. The solution is targeted towards providing probabilistically better resilience, no matter whether the spoofed packets carry bad UDP payload or Good authenticated packet etc (take any case of spoofing). [/Pranjal] 

[Pranjal] I have responded on this to Lizhong's earlier question. IMO, we are probably questioning here more on RFC 5036. There is no limit on hello hold time as per RFC 5036. When there is a change in parameter, the change needs to be reflected to peers with "best effort". Some implementations do today by sending a set of hellos within shorted intervals (e.g 5) after a 
parameter change. But what if those 5 hellos are lost (means the hello channel is unreliable enough to loss of contiguous 5 packets or spurious attacks on receiver dropped those packets). If it so happens then perhaps it would result in loss of hello adjacency. I

[/Pranjal]

[Pranjal] Yes, we would address the uses cases where precautions are necessary to deploy the solution. [/Pranjal]

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Tue, 24 Jul 2012 17:10:54 +0000

Ref to your other email response:
"Yes, we would address the uses cases where precautions are necessary to deploy the solution"

I assume that you would also add LDPoTE use case amongst these.

Thx.

Date: Tue, 24 Jul 2012 22:08:50 +0530

Hi Kamran,
                        Please refer inline.

Thanks,
Pranjal

To: Dutta, Pranjal K (Pranjal); Lizhong Jin; [email-masked]<mailto:[email-masked]>; Thomas Nadeau; Giles Heron (giheron)

Hi Pranjal,

[Pranjal] This is a missing  piece in RFC 5036 which IMO should be addressed separately. Even if we don’t pursue infinite hold time
as per the draft it is still possible that t-ldp adjacency may become invalid for prolonged period when hello hold timers are relaxed
(e.g 180 sec etc). by RFC 5036 there is no upper bound on hello hold time and large scale deployments (e.g ~ 10K T-LDP peers) tend
to use relaxed hold time.

Rgds.

Dear authors,

I've couple of comments:

Rgds,

-- Kamran

Hi all,
I've reviewed this draft, and have two comments that need to be clarifed:
1. Target Hello tracks the liveness of helloadjacency, while LDP keepalive tracks the liveness of session. Do you mean it is not necessary to track the liveness of hello adjacency, or substitute itwith liveness tracking of session? Hello address maybe different with trasport address.
2. Target hellos are not only used for liveness track, but also parameter negotiation and updating. When negotiated to infinite, what time interval would be used to send the updated hello (e.g, hello with new Optional Parameters in potential draft-pdutta-mpls-ldp-adj-capability) message? UDP hello is not reliable, would be renegotiated to configured hello hold time first?

Summary of review:

b. is it useful?
Yes.

Regards
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 24 Jul 2012 22:43:31 +0530

Yes.

Sent: Tuesday, July 24, 2012 10:11 AM

Thx.

Hi Kamran,
                        Please refer inline.

Thanks,
Pranjal

Hi Pranjal,

Rgds.

Dear authors,

I've couple of comments:

Rgds,

-- Kamran

Hi all,

Summary of review:

b. is it useful?
Yes.

Regards
Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 25 Jul 2012 09:47:30 +0800

Hi Pranjal,
Thank you for the clarification. I am clear now, and the draft should add 
these technical cautions, so as to let the operator be very clear before 
deploying this feature.

Regards
Lizhong

2012/07/25 00:22:42:

> Hi Lizhong,
> 
> 
> [Lizhong] My concern is tracking of T-LDP hello source address by 
> BFD or LDP session (on condition that transport address is same as 
> hello address) could not substitue the liveness of the UDP 
> connection of hello adjacency. For example, when LDP session is 
> setup, and hello adjacency has negotiated to infinite time, 
> althought the hello address is IP reachable, but if UDP port '646' 
> is incorrectly closed or some other UDP problem accured, the hello 
> adjacency in fact is down, but you could not detect this with 
> caution that the UDP will not accure any potential problem. Maybe I 
> missed something.
> 
> Yes, you are correct. If there is a bug in S/w that closes port 646 
> accidentally and then with hello reduction it would take long time 
> to detect. But if a port 646 is closed accidently by a peer but 
> without gracefully shutting down LDP session then don’t we already 
> have a bigger problem? In that way we can contest 
> against many solutions that has a bottom line for resilience against
> bugs. This is a good point you raised and we would mention it 
> explicitly in the draft. Note
> that when LDP is deployed in large scale MPLS access, aggregation, 
> seamless MPLS etc the priority is resilience for adjacencies. There 
> are special
> techniques that an implementation can adopt (e.g H/w assisted) to 
> provide such resilience but there are cost functions associated with
> and we may not 
> Cc: Giles Heron; [email-masked]; VIGOUREUX, MARTIN (MARTIN); Markus Jork;
> [email-masked]; Ross Callon; [email-masked]; Thomas.
> [email-masked]; Thomas Nadeau
> [Lizhong] My concern is tracking of T-LDP hello source address by 
> BFD or LDP session (on condition that transport address is same as 
> hello address) could not substitue the liveness of the UDP 
> connection of hello adjacency. For example, when LDP session is 
> setup, and hello adjacency has negotiated to infinite time, 
> althought the hello address is IP reachable, but if UDP port '646' 
> is incorrectly closed or some other UDP problem accured, the hello 
> adjacency in fact is down, but you could not detect this with 
> caution that the UDP will not accure any potential problem. Maybe I 
> missed something. 
> 
> > 
> > 
> > > Reviews should be sent to the document authors, WG co-chairs 
andsecretary,