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

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Hi Kamran,
                        Please refer inline.

Thanks,
Pranjal

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

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 ] ?

[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.


>> 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)" <[e-mail]<mailto:[e-mail]>>
Date: Tue, 24 Jul 2012 21:40:31 +0530
To: "Syed Kamran Raza (skraza)" <[e-mail]<mailto:[e-mail]>>, Lizhong Jin <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Thomas Nadeau <[e-mail]<mailto:[e-mail]>>, "Giles Heron (giheron)" <[e-mail]<mailto:[e-mail]>>
Cc: Ross Callon <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

Pls. refer my answers inline.

________________________________
From: Kamran Raza (skraza) [mailto:[e-mail]]
Sent: Tuesday, July 24, 2012 8:52 AM
To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [e-mail]<mailto:[e-mail]>; 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:

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.

[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.

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.

[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

From: Lizhong Jin <[e-mail]<mailto:[e-mail]>>
Date: Mon, 23 Jul 2012 17:12:36 +0800
To: "Dutta, Pranjal K (Pranjal)" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Thomas Nadeau <[e-mail]<mailto:[e-mail]>>, Giles Heron <[e-mail]<mailto:[e-mail]>>
Cc: Ross Callon <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] 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.
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 <[e-mail]<mailto:[e-mail]>> wrote 2012/07/18 05:49:55:

> 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 thisdraft 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.
>   _______________________________________________ mpls mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/mpls