Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse

[Minjie Dai <[e-mail]>]

Resending due to original mail got bounced and not appearing in the mail
archive after a couple of days

On 3/30/15, 9:59 PM, "Minjie Dai" <[e-mail]> wrote:

>Hi Nobo,
>
>Thanks for taking time reviewing the draft.
>
>1. Regarding the case of complete path overlap, we do think with the
>correctly implemented software, the LSRs can avoid operations such as LFIB
>update and data path verification. Software implemented the new algorithm
>can bring in bugs, but this is no different from any other type of
>software change. Just as in existing MBB instance switch, there are more
>chances to create more failures due to more updates in the system compare
>to the proposal which avoid majority of the update and changes. In
>addition, this doesn¹t prevent continued monitoring of the LSP health as
>before, we are just stating, if implemented correctly everything would be
>kept the same between instances and there is no need for setting up a new
>session to do verification for the new instance. I went over the RFC5884
>and I am not entirely sure BFD mandate a new BFD session to be setup for
>the new instance. New instance of the LSP is part of the same session,
>just a different incarnation, end point etc are still the same. I don¹t
>see why BFD session can¹t be inherited for the complete overlap case. But
>I will check with other BFD experts to make sure I am not making incorrect
>assumption. It could be just an common practice that BFD is tied to
>specific instance of LSP, which can be changed without breaking BFD
>standard as part of this proposed optimization.
>
>2. For the partial overlap case, your understanding is correct. I will
>reword to make clear that there is a need for separate data plane
>verification for the new instance, using the same method, but not reusing
>the same session.
>
>
>Regards,
>
>Minjie
>
>On 3/28/15, 6:36 PM, "Nobo Akiya" <[e-mail]> wrote:
>
>>Hi Authors,
>>
>>I have couple of comments from OAM perspective.
>>(using email instead of mic since we were very short on time)
>>
>>Section 2
>>
>>   The
>>   best case scenario is complete overlap of the two paths end to end;
>>   in which case there is no need for any label changes and LFIB
>>   updates, both in the transit as well as in the ingress routers.  In
>>   this scenario there is also no need to perform data plane
>>   verification for the new tunnel instance.
>>
>>Being a paranoid OAM person, the statement "no need to perform data plane
>>verification" makes me a bit nervous. There's a big difference between
>>"there should be no data plane impact" to "there is no data plane
>>impact",
>>particularly because code changes required are to not change existing
>>data
>>plane via label sharing by multiple LSPs. That implies that any
>>bugs/timing-issues/etc in that specific code space can cause existing
>>data
>>plane to actually purged [accidently]. I would feel more comfortable if
>>the
>>document did not imply that everything about the new LSP is perfectly
>>happy
>>w/o any OAM to verify it.
>>
>>   For the case where the two
>>   paths overlaps only from a certain transit router (rather than from
>>   the ingress), label reuse starts at that router and continues all the
>>   way to the egress router.  In this case the existing data plane
>>   verification method can still be used to verify new tunnel instance
>>   as before.
>>
>>I'm fairly sure that you did not imply "existing data plane verification
>>_instance_ can still be used ...". But to doubly make sure ... if we take
>>BFD [RFC5884] as an existing data plane verification method, you cannot
>>reuse an existing BFD instance (i.e., BFD session for the old LSP cannot
>>be
>>used for the new LSP), since the BFD session on the egress is tied to the
>>FEC for the old LSP. If you attempt to do this w/o any further BFD
>>procedures, the BFD session at the egress for the old LSP will be removed
>>when the old LSP is removed from the egress.
>>
>>Thanks!
>>
>>-Nobo
>>
>>
>>
>>
>>_______________________________________________
>>mpls mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/mpls
>