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

"Nobo Akiya" <nobo.akiya.dev@gmail.com> Thu, 02 April 2015 05:18 UTC

From: Nobo Akiya <nobo.akiya.dev@gmail.com>
To: 'Minjie Dai' <mdai@juniper.net>
References: <006001d069c0$d9eadeb0$8dc09c10$@gmail.com> <D13F6FEA.D6CD%mdai@juniper.net> <D141AC85.D7DE%mdai@juniper.net>
In-Reply-To: <D141AC85.D7DE%mdai@juniper.net>
Date: Wed, 01 Apr 2015 22:18:46 -0700
Message-ID: <000c01d06d04$7f9c9790$7ed5c6b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJ/uESsAe8QwkPH/+hptB22ujvDxwFUJ2AIAtWfeqibuUhXAA==
Content-Language: en-ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/5HELTPl8sGuaM9R6B5ize3GL_CE>
Cc: 'mpls' <mpls@ietf.org>
Subject: Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse
Precedence: list

Hi Minjie,

Thanks for your response.

Please see in-line with [NOBO].

> -----Original Message-----
> From: Minjie Dai [mailto:mdai@juniper.net]
> 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" <mdai@juniper.net> 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" <nobo.akiya.dev@gmail.com> 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
> >>mpls@ietf.org
> >>https://www.ietf.org/mailman/listinfo/mpls
> >

[mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-… Nobo Akiya
Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-… Minjie Dai
Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-… Nobo Akiya
Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-… Minjie Dai