Re: [RTG-DIR] RtgDir Review: draft-ietf-mpls-ri-rsvp-frr-05

[<[e-mail]>]

Hi Chandra,

OK, after refreshing the context, I think I get it and why I got confused.

What puzzles me then is the 1st sentence of section 4.6.2.2, and
especially the "upstream direction" phrase, which happens to be wrong
with respect to the section title and content. I suggest two
clarification tweaks:
- drop the confusing phrase (e.g., just say "The procedures are as
follows."), as the section title already does the right job;
- add a parenthesis at the end of the 2nd bullet, e.g. "(Thus, the Nhop
is informed and can use compatible values when sending a Resv.)"

Another typo spotted from the diff: in the terminology section,
Next-Next-hop points to the PPhop acronym.

Thanks for your time,

Julien


On 21/06/2019 11:14, Chandrasekar Ramachandran wrote:
> Hi Julien,
>
>
> Juniper Business Use Only
>
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Friday, June 21, 2019 2:25 PM
>>
>> Hi Chandra,
>>
>> Your response seems to summarize section 4.6.2.1. about the "downstream
>> direction", which is fine. My comment below is about section 4.6.2.2.
>> which describes the "upstream direction": how could an RSVP-TE message
>> sent to a Phop be a Path instead of a Resv? Am I missing something?
> [Chandra] Let me illustrate with an example LSP as shown below.
>
>     A  -> B -> C -> D
>
> If ingress A does not support the extensions defined in the draft and requests node protection for the LSP, then long refresh will not be enforced on the LSP segment A -> B -> C. In other words, Path messages from A to B, Path messages from B to C, Resv messages from B to A, and Resv messages from C to B, will not use long refresh interval. This behavior ensures that neither primary Path from B to C nor backup LSP Path from A to C during local repair would use long refresh. Hence, node C may opt to time out LSP state normally in case of B-C link failure without requiring any explicit state cleanup messages from node A or node B.
>
> In general, if there is a non-compliant node along the path of an LSP and if the ingress node has requested node protection, then backward compatibility procedures will come into force on two hops upstream & two hops downstream of that non-compliant node.
>
> Thanks,
> Chandra.
>
>> Cheers,
>>
>> Julien
>>
>>
>> On 20/06/2019 17:08, Chandrasekar Ramachandran wrote:
>>> Hi Julien,
>>> Please refer inline.
>>>
>>>
>>> Juniper Internal
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] <[e-mail]>
>>>> Sent: Thursday, June 20, 2019 7:38 PM
>>>>
>>>> Hi Chandra,
>>>>
>>>> Thanks for the update. I've just taken a look at the diff: it looks
>>>> fine, with an improved MUST/SHOULD ratio. I haven't checked all nits,
>>>> but it seems you missed a key one in section 4.6.2.2., leaving a Path
>>>> message when talking about upstream (see below).
>>> [Chandra] The text "carried in the Path to" is intended because the
>> expected outcome is not to apply long refresh in the two hop
>> neighborhood. That is, if the Phop node (say node X) does not support the
>> extensions, then two nodes downstream of node X must use backward
>> compatible refresh interval. This will enable the NP-MP of node X to time
>> out the path state normally when the refresh timeout expires.
>>> Thanks,
>>> Chandra.
>>>
>>>> Cheers,
>>>>
>>>> Julien
>>>>
>>>>
>>>> On 20/06/2019 15:42, Chandrasekar Ramachandran wrote:
>>>>> [...]
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] <[e-mail]>
>>>>>> Sent: Thursday, April 11, 2019 10:03 PM
>>>>>>
>>>>>> - s/in TIME_VALUES object carried in PATH to default value/in the
>>>>>> TIME_VALUES object carried in the *Resv* message to a default
>>>>>> value/
>>>>
>> ______________________________________________________________
>>>> ___________________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>>>> que les pieces jointes. Les messages electroniques etant susceptibles
>>>> d'alteration, Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not
>>>> be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender
>>>> and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have
>>>> been modified, changed or falsified.
>>>> Thank you.
>>
>> ______________________________________________________________
>> ___________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
>> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
>> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration, Orange decline
>> toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law; they should not be distributed,
>> used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete
>> this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been
>> modified, changed or falsified.
>> Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.