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

[Minjie Dai <[e-mail]>]

Thanks Nobo,

I took a second look of the BFD draft and also LSP ping draft 4379, for
RSVP LSP, LSP ID is part of the FEC, so you are correct to point out that
a new BFD session need to be established for new instance ,either before
or after LSP instance switch.

Regards,

Minjie

On 4/1/15, 10:18 PM, "Nobo Akiya" <[e-mail]> wrote:

>Hi Minjie,
>
>Thanks for your response.
>
>Please see in-line with [NOBO].
>
>> -----Original Message-----
>> From: Minjie Dai [mailto:[e-mail]]
>> Sent: April-01-15 2:10 PM
>> To: Nobo Akiya
>> Cc: 'mpls'
>> Subject: Re: [mpls] Mail regarding
>>draft-dai-mpls-rsvp-te-mbb-label-reuse
>> 
>> 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.
>
>[NOBO] This is probably something we won't be able to fully converge on.
>Optimistic person would likely say, yup no need to prove the new LSP
>health
>with this mechanism. Paranoid person would likely say what I say :)
>
>>> 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.
>
>[NOBO] The BFD session is tied to the FEC, and the FEC includes the
>LSP-ID.
>From what I understand, the old/new LSPs will have different LSP-ID? If
>so,
>then that's the gotcha.
>
>> >
>> >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.
>
>[NOBO] Thanks for considering my comments!
>
>-Nobo
>
>> >
>> >
>> >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
>> >
>
>