Re: [mpls] Rule that is not needed and rejection of [Technical Errata Reported] RFC5036 (4465)

[Guijuan Wang 3 <[e-mail]>]

Hi Loa,

Got it, thanks a lot for your sharing:)

Regards 
Guijuan Wang (Jean) 
---------------------------- 
IPOS Beijing, Software Engineer 
Tel: [phone] 
ECN: 887 17882 

-----Original Message-----
From: Loa Andersson [mailto:[e-mail]] 
Sent: Wednesday, September 23, 2015 5:09 PM
To: Guijuan Wang 3; RFC Errata System; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Rule that is not needed and rejection of [Technical Errata Reported] RFC5036 (4465)

Jean,

To create a RFC that do a update to an other RFC is a rather simple procedure.

The issue is mostly that we need someone to work on the document. This of course depends on how urgent we think it is.

/Loa

On 2015-09-21 17:50, Guijuan Wang 3 wrote:
> Hi Deborah,
>
> Glad to hear from you! Then I shall disregard this rule.
> BTW: do you know generally how long the cycle is for the new draft/RFC update for 5035? Thanks!
>
>
> Regards
> Guijuan Wang (Jean)
> ----------------------------
> IPOS Beijing, Software Engineer
> Tel: [phone]
> ECN: 887 17882
>
> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: Friday, September 18, 2015 5:28 PM
> To: Guijuan Wang 3; RFC Errata System; Loa Andersson; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Rule that is not needed and rejection of [Technical Errata 
> Reported] RFC5036 (4465)
>
> Jean,
>
> We have been looking at this quite extensively.
>
> The consensus is that section 3.5.7.1.3. describes a situation that we can't get into with standards compatible implementation. So you can disregard the rule in  section 3.5.7.1.3.
>
> We have also agreed that fixing this is not really urgent, and that the errata process is the wrong vehicle to fix it. We require an Internet Draft/RFC that updates RFC 5036.
>
> I will therefore ask Deborah to reject the errata, based on the grounds given above.
>
> Deborah,
>
> Can you execute on this? Let me know if you need more info.
>
> /Loa
> mpls wg co-chair
>
>
>
>
>
> On 2015-09-16 05:46, Guijuan Wang 3 wrote:
>> Dear All,
>>
>> For negotiating DoD/DU advertisement mode between LDP peers, there are 2 rules in the RFC. I don't know which one to choose. You are LDP experts, and I am wondering if you could share your ideas on it. Thanks a lot.
>>
>> See details in the mail below.
>>
>>
>> Regards
>> Guijuan Wang (Jean)
>>
>>
>> -----Original Message-----
>> From: RFC Errata System [mailto:[e-mail]]
>> Sent: Sunday, September 06, 2015 2:49 PM
>> To: [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]
>> Cc: Guijuan Wang 3; [e-mail]; [e-mail]
>> Subject: [Technical Errata Reported] RFC5036 (4465)
>>
>> The following errata report has been submitted for RFC5036, "LDP Specification".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=4465
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Label advertisement mode negotiation rule is different 
>> in two sections <[e-mail]>
>>
>> Section: 3.5.3
>>
>> Original Text
>> -------------
>> when the label advertisement mode is different between LSR peers, the resolving rule is defined twice in two chapters, both use "must" or "SHOULD NOT", but they are completely different.
>>
>> The first rule:
>> In section 3.5.3
>>      A, Label Advertisement Discipline
>>            (skip the first paragraph)
>>
>>            If one LSR proposes Downstream Unsolicited and the other
>>            proposes Downstream on Demand, the rules for resolving this
>>            difference is:
>>
>>            -  If the session is for a label-controlled ATM link or a
>>               label-controlled Frame Relay link, then Downstream on Demand
>>               MUST be used.
>>
>>            -  Otherwise, Downstream Unsolicited MUST be used.
>>
>>
>> The second rule:
>> In section 3.5.7.1.3.
>>
>>      In general, the upstream LSR is responsible for requesting label
>>      mappings when operating in Downstream on Demand mode.  However,
>>      unless some rules are followed, it is possible for neighboring LSRs
>>      with different advertisement modes to get into a livelock situation
>>      where everything is functioning properly, but no labels are
>>      distributed.  For example, consider two LSRs Ru and Rd where Ru is
>>      the upstream LSR and Rd is the downstream LSR for a particular FEC.
>>      In this example, Ru is using Downstream Unsolicited advertisement
>>      mode and Rd is using Downstream on Demand mode.  In this case, Rd may
>>      assume that Ru will request a label mapping when it wants one and Ru
>>      may assume that Rd will advertise a label if it wants Ru to use one.
>>      If Rd and Ru operate as suggested, no labels will be distributed from
>>      Rd to Ru.
>>
>>      This livelock situation can be avoided if the following rule is
>>      observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
>>      expected to send unsolicited mapping advertisements.  Therefore, if
>>      the downstream LSR is operating in Downstream on Demand mode, the
>>      upstream LSR is responsible for requesting label mappings as needed.
>>
>> Corrected Text
>> --------------
>> It's better to settle down which rule to use for this case.
>> Seems the first one is simpler for implementment.
>>
>> Or if you want to keep both rules,
>> better to enumerate both of those two rules in each section, and say the implement can choose any of them.
>>
>>
>> Notes
>> -----
>>
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5036 (draft-ietf-mpls-rfc3036bis-04)
>> --------------------------------------
>> Title               : LDP Specification
>> Publication Date    : October 2007
>> Author(s)           : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.
>> Category            : DRAFT STANDARD
>> Source              : Multiprotocol Label Switching
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>>