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

From: Minjie Dai <[email-masked]>
Date: Wed, 1 Apr 2015 21:10:21 +0000

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" <[email-masked]> 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" <[email-masked]> 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
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Nobo Akiya" <[email-masked]>
Date: Wed, 1 Apr 2015 22:18:46 -0700

Hi Minjie,

Thanks for your response.

Please see in-line with [NOBO].

> -----Original Message-----
> From: Minjie Dai [mailto:[email-masked]]
> 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
> 
> >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
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.

> >verification for the new instance, using the same method, but not
> >reusing the same session.

[NOBO] Thanks for considering my comments!

-Nobo

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

---

From: Minjie Dai <[email-masked]>
Date: Thu, 2 Apr 2015 18:08:12 +0000

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