Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B63130FCF for ; Mon, 8 Oct 2018 12:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwuriupkLiTr for ; Mon, 8 Oct 2018 12:31:04 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F70130FA5 for ; Mon, 8 Oct 2018 12:31:02 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id t70-v6so8249451pgd.12 for ; Mon, 08 Oct 2018 12:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uBuc0QIHPp806WNS2Nolegc+20Y2PcoJda3XhK9ZPBE=; b=BYSNQ7U0Pd1+xNwPVCcEM3Pa2k9u4UjmDwQpra7tbigci9cb3LHha6PQ7WDylI7/+o wHkhswcPVL2/8Go/CkGKlz0hfP6li6qEvM/JqMjoASaRV+FBjMc19J/5r6k6NuXqdEdD 8oH3xGIB755BJZE6eor07Z/B5Qkr2r7TV1A9iJrhcQw+KpRbc/GyzNFfJ785tICZNO3Z YBLu8QjUMyGaUJdiCeidcef0bgeJClKZ3PXZ7zsZ06yD9BxpmfYcJegaztKZgx+7q/E4 8Q8Go239SK4+CM/WpuWHQ3NTRPrqkIlapwUUrfpQWmveRKS4Ydr2Y33KhgB4PqvHTQ/b LQmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uBuc0QIHPp806WNS2Nolegc+20Y2PcoJda3XhK9ZPBE=; b=AMjuH6+zZof7vPTyhGXW1Tz+U212SAsXupIlzv3xB/CNdKHd2zjUSq97zmFbQ9zmnt 88FGcTEOGDGk7OLNYMKVMb99f+lhjS8M9/YbL+9EHWNjZc5EmGBPrhL/Yu0JjwGasPmH qEjUDECSg/3rGq8W35is0h43RnLoEjOTi3IvJAbvZ1bEsV8dvaMLnDu2sn4qJzZbEEJP akqe4aaeLzODzJawgHzLFBRhDlIWKL1D4npNSIaWURpKG6kzdUur+E091viM3RsL9Vmy mc/jeaHuWAa8Sy2MW7FN0m1l+LYdgGMHR4F6sBXQcf/pHpMmlMf7QDiQhY25GfjXp5TV tmzA== X-Gm-Message-State: ABuFfohZrA3uoKGjcb1K1B4NxOF82gLpt/QbTj+7OmwFeGLfqMc37j6k ErpKzMMd57MGPzz+il6arcCWaeyUEIFPImXfwac= X-Google-Smtp-Source: ACcGV62mS1IsVD+R5ApbQ4y+dskbVfGw8EjWDOFRyACoscfZl6qq+MVxZUDfdYnr9GXFdVeuofDucCkmIG23kcInwmo= X-Received: by 2002:a63:e442:: with SMTP id i2-v6mr5591098pgk.381.1539027061424; Mon, 08 Oct 2018 12:31:01 -0700 (PDT) MIME-Version: 1.0 References: <211770d4-8279-33e2-b6bf-289261b6f6ff@gmail.com> <5437736B-6E12-4595-A333-367AB7232692@gmail.com> <60C0E897-0D5D-4230-9094-4367524F91EE@gmail.com> In-Reply-To: From: Vishnu Pavan Beeram Date: Mon, 8 Oct 2018 15:30:48 -0400 Message-ID: To: Alexander Okonnikov Cc: IETF MPLS List , mhartley.ietf@gmail.com Content-Type: multipart/alternative; boundary="0000000000004bc7510577bca91b" Archived-At: Subject: Re: [mpls] Requesting WG LC for draft-ietf-mpls-rsvp-shared-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 19:31:08 -0000 --0000000000004bc7510577bca91b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alexander, Hi! There isn't any strong reason to strip link protection out of this document. In our (authors) opinion, this base draft is sufficiently baked for an implementation to adopt and deliver a deployable solution. Please note that there are network deployments out there that don=E2=80=99t have node-protec= tion turned on. Our preference would be to progress the base draft without any references to the node protection draft and let the node protection draft go through the WG process independently (take the natural course). The procedures in draft-chandra-mpls-rsvp-shared-labels-np are fully backwards compatible with the procedures discussed in the base draft. Regards, -Pavan (on behalf of the authors) On Mon, Oct 1, 2018 at 5:54 AM Alexander Okonnikov < alexander.okonnikov@gmail.com> wrote: > Hi Pavan, > > Maybe it would be better to take out FRR link-protection description from > this draft to draft-chandra-mpls-rsvp-shared-labels-np. Like we have RFC > 3209 and RFC 4090 that describe RSVP-TE LSP and FRR for RSVP-TE LSP, > respectively. > > Thank you. > > 27 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 17:47, Matt Hartley > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > > Pavan, > > OK. That's reasonable, but it might be worth adding a line to the draft t= o > say so. > > Cheers > > Matt > > On Thu, Sep 27, 2018 at 4:30 AM Vishnu Pavan Beeram > wrote: > >> Matt, Hi! >> >> >> The purpose of this document is to provide a mechanism to bring up MPLS >> RSVP-TE LSPs on a shared forwarding plane. There is a set of key RSVP-TE >> features/functionalities specified in the Introduction Section that woul= d continue >> to work with this forwarding plane (without needing any special >> extensions). The authors believe that a deployable solution can be >> implemented with this set of features/functionalities. >> >> >> If there are any other desirable features/functionalities (that are not >> specified as supported in this document) that can be supported on this >> forwarding plane by introducing a few protocol extensions, then those ar= e >> expected to be discussed separately >> (draft-chandra-mpls-rsvp-shared-labels-np is an example of that). >> >> >> Regards, >> -Pavan >> >> On Wed, Sep 26, 2018 at 10:56 AM Matt Hartley >> wrote: >> >>> Pavan, >>> >>> The problem with lists like this (in general) is that it's not clear >>> what the status is for anything that isn't on the list, and most lists = will >>> probably manage to omit *something*. I think there's three reasonable >>> options: >>> >>> 1. State unequivocally that everything works >>> 2. List the functionalities that definitely don't work, and make it >>> clear that everything else does >>> 3. List the functionalities that definitely work, and explicitly make n= o >>> guarantees about anything that isn't listed. >>> >>> It isn't really clear what you're trying to do here. >>> >>> Note that in this case option 1 isn't on the table because we've alread= y >>> established that nnhop FRR requires further extensions. >>> >>> Cheers >>> >>> Matt >>> >>> On Wed, Sep 26, 2018 at 10:17 AM Vishnu Pavan Beeram < >>> vishnupavan@gmail.com> wrote: >>> >>>> Alexander Hi! >>>> >>>> >>>> The intent of the following statement in Section 1 is certainly not to >>>> be evasive (slightly or otherwise). >>>> Functionalities such as bandwidth admission control, LSP >>>> priorities, preemption, auto-bandwidth and Fast Reroute >>>> continue to work with this forwarding plane. >>>> >>>> >>>> We (the authors) still don=E2=80=99t see any problem with the above st= atement. >>>> But we=E2=80=99ll go ahead and make a slight adjustment (see below) to= address your >>>> concern. >>>> Key functionalities such as bandwidth admission control, LSP >>>> priorities, preemption, auto-bandwidth and Fast Reroute via >>>> facility backup protection continue to work with this >>>> forwarding plane. >>>> >>>> >>>> Regards, >>>> -Pavan >>>> >>>> >>>> On Tue, Sep 25, 2018 at 11:34 AM Alexander Okonnikov < >>>> alexander.okonnikov@gmail.com> wrote: >>>> >>>>> Hi Panav, >>>>> >>>>> Ok, 1:1 is not to be supported by this approach. In general, 1:1 has >>>>> its own benefits - for example, it is more attractive versus N:1 in = ring >>>>> topologies. After all, it is FRR too, as N:1 one. My point was that >>>>> description in section 1 is slightly evasive regarding FRR and other >>>>> RSVP-TE properties (PMTUD). >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> 16 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 4:38, Vishnu Pavan = Beeram >>>>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >>>>> >>>>> Alexander, Hi! >>>>> >>>>> >>>>> Please see inline for responses (prefixed VPB). >>>>> >>>>> >>>>> Regards, >>>>> -Pavan >>>>> >>>>> On Thu, Sep 13, 2018 at 1:37 PM Alexander Okonnikov < >>>>> alexander.okonnikov@gmail.com> wrote: >>>>> >>>>>> Hi Panav, >>>>>> >>>>>> From section 7: >>>>>> >>>>>> >>>>>> "If the label type is a delegation label, then the stacking procedur= e >>>>>> stops at that delegation hop." >>>>>> It is OK for "Stack to Reach Delegation Hop" approach, but it doesn'= t >>>>>> work for "Stack to Reach Egress", isn't it? >>>>>> >>>>> >>>>> [VPB] The logic specified in Section 7 could be used by any node >>>>> constructing the label stack (this could be the ingress or a delegati= on >>>>> hop). The sentence immediately following the above quoted sentence in >>>>> Section 7 is important. It currently reads =E2=80=93 >>>>> Approaches in Section 5.1 >>>>> >>>>> SHOULD be used to determine how the delegation labels are pushed in t= he >>>>> label stack. >>>>> >>>>> >>>>> The intent here is to say that if you encounter a delegation label, >>>>> use the procedures outlined in Section 5.1 to determine how the deleg= ation >>>>> labels are pushed in the label stack. The following change to the tex= t >>>>> should address this comment: >>>>> >>>>> OLD: >>>>> >>>>> If the label type is a delegation label, then the stacking procedure = stops at that delegation hop. >>>>> Approaches in Section 5.1 SHOULD be used to determine how the de= legation labels are pushed in the label stack. >>>>> >>>>> >>>>> NEW: >>>>> If the label type is a delegation label, then the type of stacking >>>>> approach chosen by the ingress for this LSP (Section 5.1) MUST be use= d to >>>>> determine how the delegation labels are pushed in the label stack. >>>>> >>>>> >>>>> >>>>>> >>>>>> Also, regarding FRR support. Section 1 says: >>>>>> >>>>>> "Functionalities such as bandwidth admission control, LSP priorities= , >>>>>> preemption, >>>>>> auto-bandwidth and Fast Reroute continue to work with this forwardin= g >>>>>> plane." >>>>>> It seems that shared labels approach supports only facility bypass >>>>>> link-protection. It doesn't support one-to-one link- and node-protec= tion, >>>>>> per my understanding. Facility bypass node-protection is not support= ed as >>>>>> well (as mentioned in Section 8). Hence, FRR support is very limited= , and >>>>>> section 1 needs correction. >>>>>> >>>>> >>>>> [VPB] I don=E2=80=99t see anything wrong with the quoted text. Fast R= eroute >>>>> for MPLS-TE LSPs can be realized by either the 1-to-1 protection mech= anism >>>>> (detours) or the facility bypass mechanism. The authors don=E2=80=99t= intend to add >>>>> procedures for 1-to-1 link/node protection (who needs it?). The >>>>> facility bypass link-protection procedure is discussed in this draft.= The >>>>> facility bypass node-protection procedure is discussed in >>>>> https://tools.ietf.org/html/draft-chandra-mpls-rsvp-shared-labels-np-= 00 >>>>> (this was presented at the last IETF). >>>>> >>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> 13 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 20:28, Alexander O= konnikov < >>>>>> alexander.okonnikov@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0): >>>>>> >>>>>> Hi Panav, >>>>>> >>>>>> Questions regarding ETLD: >>>>>> >>>>>> The draft is not clear about signaling of ETLD attribute. It says >>>>>> that ETLD is conveyed as per-hop attribute. Is my understanding corr= ect >>>>>> that it is conveyed as RRO Hop attribute? Probably it could be clean= ed to >>>>>> avoid confusion whether ERO or RRO Hop attribute mechanism is used. >>>>>> >>>>>> Next, the draft says that: >>>>>> >>>>>> "... If a node is reached where the ETLD set from the previous hop i= s >>>>>> 1, then that >>>>>> node MUST select itself as the delegation hop. If a node is reached >>>>>> and it is >>>>>> determined that this hop cannot receive more than one transport >>>>>> label, then that node >>>>>> MUST select itself as the delegation hop. ..." >>>>>> >>>>>> What is purpose of the second sentence/rule? >>>>>> >>>>>> Next: >>>>>> >>>>>> "If there is a node or a sequence of nodes along the path of the LSP >>>>>> that do not >>>>>> support ETLD, then the immediate hop that supports ETLD MUST select >>>>>> itself as the >>>>>> delegation hop." >>>>>> >>>>>> If some node (consecutive nodes) doesn't support ETLD then it doesn'= t >>>>>> support TE labels. Hence, that node (regular RSVP-TE LSR) will do SW= AP and >>>>>> not POP. As a result non-decremented ETLD is OK and immediate hop th= at >>>>>> supports ETLD not necessary should become delegation hop? >>>>>> >>>>>> Also, from Section 9.7: >>>>>> >>>>>> "The ETLD field specifies the maximum number of transport labels tha= t >>>>>> this hop can potentially send to its downstream hop. It MUST be set= to a >>>>>> non-zero value." >>>>>> >>>>>> Strictly speaking it is not correct. ETLD reflects decrementing >>>>>> counter and not capability of some transit node. I.e. if we consider= LSP >>>>>> R1-R2-R3, R1 puts value 5 in ETLD,and R2 supports imposing of 2 labe= ls, it >>>>>> doesn't mean that R2 should rewrite ETLD with value 2. It just shoul= d >>>>>> decrement value 5. Correct? >>>>>> >>>>>> Also, per my understanding it is supposed that in fact ETLD value >>>>>> will not be just decremented, but it will be copied from previous RR= O Hop >>>>>> attributes subobject into being inserted RRO Hop attributes subobjec= t with >>>>>> decrementing. May be it would be better to signal ETLD value in LSP >>>>>> Attributes object (and each capable node decrements ETLD value there= ), >>>>>> while signaling support of ETLD itself in RRO Hop attributes subobje= ct? >>>>>> >>>>>> Thank you. >>>>>> >>>>>> 13 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 20:22, Alexander O= konnikov < >>>>>> alexander.okonnikov@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0): >>>>>> >>>>>> Hi Pavan, >>>>>> >>>>>> I'm sorry for delay with answer. >>>>>> >>>>>> If ingress uses regular Path MTU discovery mechanism, it could >>>>>> produce value of MTU lower than actual one. This is because ingress = doesn't >>>>>> know MTU per each hop. Let's consider case with four routers: R1 - R= 2 - R3 >>>>>> - R4. MTU for R1-R2 link is 2000, MTU for R2-R3 is 1600 and MTU for = R3-R4 >>>>>> is 2000. By virtue of regular Path MTU discovery mechanism R1 will d= erive >>>>>> from FLOWSPEC that path MTU is 1600. As soon as R1 doesn't know how = many >>>>>> labels in the stack will be on the lowest MTU hop, it can only set L= SP MTU >>>>>> to most conservative value (1600 - 4 - 4 =3D 1592, provided that R4 = has >>>>>> advertised implicit null label). In fact actual path MTU is 1596 (16= 00 - 4 >>>>>> on R2-R3 hop). Of course, it could be acceptable, but calculated LSP= MTU as >>>>>> more lower than actual as longer LSP path. For correct path MTU disc= overy >>>>>> ingress needs to know MTU per each hop. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> 6 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 18:27, Vishnu Pavan= Beeram >>>>>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >>>>>> >>>>>> Alexander, Hi! >>>>>> >>>>>> I apologize for the delayed response. >>>>>> >>>>>> This draft does not propose any changes to the standard RSVP MTU >>>>>> signaling procedures (Int Serv object specific signaling procedures)= . After >>>>>> the initial signaling sequence is complete, an ingress implementatio= n >>>>>> (RFC3209) would typically take the path MTU learnt via signaling, ru= n it >>>>>> through some local logic and then arrive at an MTU value that can be >>>>>> assigned to the LSP. This local logic typically involves deducting t= he >>>>>> number of bytes in the label stack used for the LSP from the path MT= U >>>>>> learnt via signaling. The ingress implementation supporting this dra= ft will >>>>>> rely on the Resv RRO to accurately determine the max-number of label= s >>>>>> pushed along the path of the LSP (note that with delegation, downstr= eam >>>>>> hops can impose label stacks) and account for it in the local logic = used to >>>>>> arrive at the MTU value assigned to the LSP. >>>>>> >>>>>> I hope this addresses your question.. >>>>>> >>>>>> Regards, >>>>>> -Pavan >>>>>> >>>>>> On Tue, Aug 7, 2018 at 12:22 PM Alexander Okonnikov < >>>>>> alexander.okonnikov@gmail.com> wrote: >>>>>> >>>>>>> Hi Pavan, >>>>>>> >>>>>>> >>>>>>> Regular RSVP-TE LSPs use standard RSVP path MTU discovery mechanism= . >>>>>>> That one cannot be used "as is" for approach described in the draft= , and >>>>>>> the draft doesn't address path MTU identification. Is it to be cons= idered? >>>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> 26.07.2018 06:07, Vishnu Pavan Beeram =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: >>>>>>> >>>>>>> Chairs, Hi! >>>>>>> >>>>>>> As mentioned (in our presentation) in last week's WG session, we >>>>>>> believe that the draft is sufficiently baked and ready to progress = to the >>>>>>> next stage. We would like to formally request this draft to be cons= idered >>>>>>> for WG LC. >>>>>>> >>>>>>> Regards, >>>>>>> - Pavan (on behalf of the authors) >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo= /mpls >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>> > --0000000000004bc7510577bca91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alexander, Hi!

<= div>There isn't any strong reason to strip link protection out of this = document.

In our (authors) opinion, this base= draft is sufficiently baked for an implementation to adopt and deliver a d= eployable solution. Please note that there are network deployments out ther= e that don=E2=80=99t have node-protection turned on. Our preference would b= e to progress the base draft without any references to the node protection = draft and let the node protection draft go through the WG process independe= ntly (take the natural course). The procedures in draft-chandra-mpls-rsvp-s= hared-labels-np=C2=A0 are fully backwards compatible with the procedures di= scussed in the base draft.

Regards,
-Pavan (on behalf of the authors)


On Mon, Oct 1, 2018 at 5:54 AM Alex= ander Okonnikov <alexan= der.okonnikov@gmail.com> wrote:
Hi Pav= an,

Maybe it would be better to take out FRR link-protec= tion description from this draft to=C2=A0draf= t-chandra-mpls-rsvp-shared-labels-np. Like we have RFC 3209 and RFC 4090 th= at describe RSVP-TE LSP and FRR for RSVP-TE LSP, respectively.
=

Thank you.

= 27 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 17:47, Matt Hartley <<= a href=3D"mailto:mhartley.ietf@gmail.com" target=3D"_blank">mhartley.ietf@g= mail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
<= br class=3D"m_-297057523195160134Apple-interchange-newline">
Pavan,

OK. That's reasonable, bu= t it might be worth adding a line to the draft to say so.

Cheers

Matt

On Thu, Sep 27, 2018 at 4:30 AM Vishnu Pa= van Beeram <v= ishnupavan@gmail.com> wrote:
Matt, Hi!

= =C2=A0

The purpose of this document is to provide a mechanism to bring up MPLS RSVP-TE= LSPs on a shared forwarding plane. There is a set of key RSVP-TE features/= functionalities specified in the Introduction Section that would continue to w= ork with this forwarding plane (without needing any special extensions). The authors believe that a deploy= able solution can be implemented with this set of features/functionalities.

= =C2=A0

If there are any other desirable features/functionalities (that are not specified as supported in this document) that can be supported on this forwarding plane = by introducing a few protocol extensions, then those are expected to be dis= cussed separately (draft-chandra-mpls-rsvp-shared-labels-np is an example of that).

=C2=A0<= /span>

Regards,
On Wed, Sep 26, 2018 = at 10:56 AM Matt Hartley <mhartley.ietf@gmail.com> wrote:
Pavan,

Th= e problem with lists like this (in general) is that it's not clear what= the status is for anything that isn't on the list, and most lists will= probably manage to omit *something*. I think there's three reasonable = options:

1. State unequivocally that everything wo= rks
2. List the functionalities that definitely don't work, a= nd make it clear that everything else does
3. List the functi= onalities that definitely work, and explicitly make no guarantees about any= thing that isn't listed.

It isn't really c= lear what you're trying to do here.

Note that = in this case option 1 isn't on the table because we've already esta= blished that nnhop FRR requires further extensions.

Cheers

Matt

On Wed, Sep 26, 2018 at 10:17 AM Vishnu Pavan= Beeram <vish= nupavan@gmail.com> wrote:
Alexander Hi!

= =C2=A0

The intent of the following statement in Section 1 is certainly not to be evasi= ve (slightly or otherwise).
=C2=A0=C2=A0 Functionalities such as bandwidth admission control, LSP
=C2=A0=C2=A0 prioriti= es, preemption, auto-bandwidth and Fast Reroute
=C2=A0=C2=A0 continue= to work with this forwarding plane.

=C2=A0

We (the au= thors) still don=E2=80=99t see any problem with the above statement. But we=E2=80=99ll go ahead and make a= slight adjustment (see below) to address your concern.
= =C2=A0=C2=A0 Key functionalities such as bandwidth admission control, LSP
=C2=A0=C2=A0 priorities, preemption, auto-bandwidth and Fast Reroute via
=C2=A0=C2=A0 faci= lity backup protection continue to work with this
=C2=A0=C2=A0 forwarding = plane.

=C2= =A0

Regards,
-Pavan


On Tue, Sep 25, 2018 at= 11:34 AM Alexander Okonnikov <alexander.okonnikov@gmail.com> wrote:
<= /div>
Hi Panav,

Ok, 1:1 is not to be= supported by this approach. In general, 1:1 has its own benefits =C2=A0- f= or example, it is more attractive versus N:1 in ring topologies. After all,= it is FRR too, as N:1 one. My point was that description in section 1 is s= lightly evasive regarding FRR and other RSVP-TE properties (PMTUD).

Thank you.


16 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 4:38, Vishnu Pava= n Beeram <vis= hnupavan@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0= =B0):

Alexander, Hi!

= =C2=A0

Please see inline for responses (prefixed VPB).

=C2=A0

Regards,
-Pavan

On Thu, Sep 13, 2018 at 1:3= 7 PM Alexander Okonnikov <alexander.okonnikov@gmail.com> wrote:
=
Hi Panav,

From section 7:


= "If the label type is a delegation label, then the stacking pro= cedure stops at that delegation hop."
It is OK for "Stack to Reach Delega= tion Hop" approach, but it doesn't work for "Stack to Reach E= gress", isn't it?

[VPB] The logic specified in Section 7 could be used by any node constructing the lab= el stack (this could be the ingress or a delegation hop). The sentence immedia= tely following the above quoted sentence in Section 7 is important. It currently= reads =E2=80=93
Approaches in Section 5.1<= /span> SHOULD be used to determine how the delegation labels are pushed in the label stack.
<= p class=3D"MsoNormal" style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-= family:"Calibri",sans-serif">=C2=A0

=
The intent here is to say that if you encounter a delegation label, use the procedures outlined in Section 5.1 to determine how the delegation labels a= re pushed in the label stack. The following change to the text should address this comment:

OLD:
If the label type is a delegation label, then the stac=
king procedure stops at that delegation hop.=C2=A0 
Approac=
hes in Section =
5.1 SHOULD be used to determine how the delegation labels are pu=
shed in the label stack.

=C2=A0

NEW:
If the label type is a delegation label, then the type of stacking approach chosen by the ingress for this LS= P (Section 5.1) MUST be used to determine how the delegation labels are pushed in the = label stack.

=C2=A0

Also, regardi= ng FRR support. Section 1 says:

"Functionalities such as bandwidth admissi= on control, LSP priorities, preemption,=C2=A0
auto-bandwidth and Fast Reroute continue to work= with this forwarding plane."
It seems that shared labels approach supports on= ly facility bypass link-protection. It doesn't support one-to-one link-= and node-protection, per my understanding. Facility bypass node-protection= is not supported as well (as mentioned in Section 8). Hence, FRR support i= s very limited, and section 1 needs correction.

[VPB] I don=E2=80=99t see anything wrong with the quoted text. Fast Reroute for MPLS-TE LSPs can = be realized by either the 1-to-1 protection mechanism (detours) or the facility bypass = mechanism. The authors don=E2=80=99t intend to add procedures for 1-to-1 link/node pro= tection (who needs it?). =C2=A0The facility bypass link-protection procedure is discussed in this draft. The facility bypass node-protection procedure is discussed in https://tools.ietf.org/html/draft-= chandra-mpls-rsvp-shared-labels-np-00 (this was presented at the last IETF).
=C2=A0

Thank you.

13 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0= =B3., =D0=B2 20:28, Alexander Okonnikov <alexander.okonnikov@gmail.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Hi Pana= v,

Questions regarding ETLD:

The draft is not clear about signaling of ETLD attribute. It says that E= TLD is conveyed as per-hop attribute. Is my understanding correct that it i= s conveyed as RRO Hop attribute? Probably it could be cleaned to avoid conf= usion whether ERO or RRO Hop attribute mechanism is used.

Next, the draft says that:

"... If a node is reached where the ETL= D set from the previous hop is 1, then that
node MUST select itself as the delegation hop.=C2= =A0 If a node is reached and it is=C2=A0
determined that this hop cannot receive more than one= transport label, then that node=C2=A0
MUST select itself as the delegation hop. ..."

What is purpose of the second sentence/rule?

Next:

"If there is a node or a sequence of nodes along th= e path of the LSP that do not=C2=A0
support ETLD, then the immediate hop that supports ETLD MU= ST select itself as the=C2=A0
delegation hop."

If some node (con= secutive nodes) doesn't support ETLD then it doesn't support TE lab= els. Hence, that node (regular RSVP-TE LSR) will do SWAP and not POP. As a = result non-decremented ETLD is OK and immediate hop that supports ETLD not = necessary should become delegation hop?

Also, from= Section 9.7:

"The ETLD field specifies the m= aximum number of transport labels that this hop can potentially send to its= downstream hop.=C2=A0 It MUST be set to a non-zero value."
=
Strictly speaking it is not correct. ETLD reflects decrement= ing counter and not capability of some transit node. I.e. if we consider LS= P R1-R2-R3, R1 puts value 5 in ETLD,and R2 supports imposing of 2 labels, i= t doesn't mean that R2 should rewrite ETLD with value 2. It just should= decrement value 5. Correct?

Also, per my understa= nding it is supposed that in fact ETLD value will not be just decremented, = but it will be copied from previous RRO Hop attributes subobject into being= inserted RRO Hop attributes subobject with decrementing. May be it would b= e better to signal ETLD value in LSP Attributes object (and each capable no= de decrements ETLD value there), while signaling support of ETLD itself in = RRO Hop attributes subobject?

Thank you.

13 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0= =B3., =D0=B2 20:22, Alexander Okonnikov <alexander.okonnikov@gmail.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Hi= Pavan,

I'm sorry for delay with answer.
=

If ingress uses regular Path MTU discovery mechanism, i= t could produce value of MTU lower than actual one. This is because ingress= doesn't know MTU per each hop. Let's consider case with four route= rs: R1 - R2 - R3 - R4. MTU for R1-R2 link is 2000, MTU for R2-R3 is 1600 an= d MTU for R3-R4 is 2000. By virtue of regular Path MTU discovery mechanism = R1 will derive from FLOWSPEC that path MTU is 1600. As soon as R1 doesn'= ;t know how many labels in the stack will be on the lowest MTU hop, it can = only set LSP MTU to most conservative value (1600 - 4 - 4 =3D 1592, provide= d that R4 has advertised implicit null label). In fact actual path MTU is 1= 596 (1600 - 4 on R2-R3 hop). Of course, it could be acceptable, but calcula= ted LSP MTU as more lower than actual as longer LSP path. For correct path = MTU discovery ingress needs to know MTU per each hop.

<= div>Thank you.

6 =D1=81=D0=B5= =D0=BD=D1=82. 2018 =D0=B3., =D0=B2 18:27, Vishnu Pavan Beeram <vishnupavan@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Alexander, Hi!
=C2=A0
I= apologize for the delayed response.
=C2=A0
This draft does not propo= se any changes to the standard RSVP MTU signaling procedures (Int Serv obje= ct specific signaling procedures). After the initial signaling sequence is = complete, an ingress implementation (RFC3209) would typically take the path= MTU learnt via signaling, run it through some local logic and then arrive = at an MTU value that can be assigned to the LSP. This local logic typically= involves deducting the number of bytes in the label stack used for the LSP= from the path MTU learnt via signaling. The ingress implementation support= ing this draft will rely on the Resv RRO to accurately determine the max-nu= mber of labels pushed along the path of the LSP (note that with delegation,= downstream hops can impose label stacks) and account for it in the local l= ogic used to arrive at the MTU value assigned to the LSP.
=C2=A0
I ho= pe this addresses your question..
=C2=A0
Regards,
-Pavan
=

=20 =20 =20

Hi Pavan,


Regular RSVP-TE LSPs use standard RSVP path MTU discovery mechanism. That one cannot be used "as is" for approach des= cribed in the draft, and the draft doesn't address path MTU identification. Is it to be considered?


Thank you.


26.07.2018 06:07, Vishnu Pavan Beeram =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
=20
Chairs, Hi!

As mentioned (in our presentation) in last week's WG session, we believe that the draft is sufficiently baked and ready to progress to the next stage. We would like to formally request this draft to be considered for WG LC.

Regards,
- Pavan (on behalf of the authors)


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls




_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--0000000000004bc7510577bca91b--