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 74988130EDD for ; Wed, 26 Sep 2018 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 xiLSuP3rvNS1 for ; Wed, 26 Sep 2018 07:20:31 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 05C5C124BE5 for ; Wed, 26 Sep 2018 07:20:31 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id q8-v6so2573485wmq.4 for ; Wed, 26 Sep 2018 07:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9tuf7eH4Dt/dGEC3wWx+xXfpO/m2q6rXIgY22l/BvHw=; b=aRZnLYW3l4rZOvpgUq8P9F6PMc7FDi47BeAouOzNhrIMncMYP+/p/C4+i5A0TaNWbD JKjJgfVqRb8J/bLfXYH+FCdHke4jMLrNVWOKEmDmdsx/bRC0ujkvo3PePVHoBefHuk/e scotbJcUsbgB453PKYJaA+zgoJW9DxVKO9HlgRdElsxLPxPKpLxY2wedx32kJmqiIHZW g1zR6xFKrhbqPGfhAsKG4rKc5dD94Cr4W9p82UMwlQYBNiuPdVTqPwRsswC0IWGv/Ed9 +dcXLE29dcF1WxBFHDcU40ep0dZTv0xb10dTrBlrxS+CdhIXy9BNe7jsEnpHuIz4di/o hxPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9tuf7eH4Dt/dGEC3wWx+xXfpO/m2q6rXIgY22l/BvHw=; b=AGU5wRR7WE3uVClILgaK3mw0g+79yshKQISHmEMh2Kpyj5ur1BdwIXbKJ8sv77cmzF d0yeqWiAxqsr878kDbLg0wfKp7IKb1bwj0LhoxkiwZQRu0MU0eTZQLAFP4GtLy6/yb5Y 2wTqzVRBCQjsE7vJtTgJuWEcRJrhygHDAxX+mLdzcwh6/0TuYMsCRkS9N1Qkkiud/Hsr Ut4QT53K6kHVtZ210dSYwejDfYFzKzDV3DEfbeya1B2vFM3ymIQwXx5zQbz6rIOvmNLv gJN9gO1VZYExLO3tF4flZxvc8EXuOg2PFNKibeaBguIGWM8QTFyyi6XUI8y0cJ+ip8G0 D9Aw== X-Gm-Message-State: ABuFfohcvms5evMQGuYvq48zAQUiUK0UsdJrjxaW69Mm/zr8PYslA+Tk YVkpEcliou1ZAhDj5tWx5ms= X-Google-Smtp-Source: ACcGV63w8SyHgyIHJA+bSN8S6T1FvoC5qd3SPgnUhJ8qlVJAryCkZuHPqZhjbTZVExf4EGmfVWVJ0A== X-Received: by 2002:a1c:ce0b:: with SMTP id e11-v6mr4544048wmg.47.1537971629206; Wed, 26 Sep 2018 07:20:29 -0700 (PDT) Received: from [10.161.106.174] ([212.65.85.100]) by smtp.gmail.com with ESMTPSA id h8-v6sm6103115wre.15.2018.09.26.07.20.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 07:20:27 -0700 (PDT) From: Alexander Okonnikov Message-Id: <1FE61579-7B64-4ADD-9FA1-97CECE9C2DD7@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A99A5281-9DBC-4531-8E7E-D1D797996EF8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 26 Sep 2018 17:20:26 +0300 In-Reply-To: Cc: IETF MPLS List To: Vishnu Pavan Beeram References: <211770d4-8279-33e2-b6bf-289261b6f6ff@gmail.com> <5437736B-6E12-4595-A333-367AB7232692@gmail.com> <60C0E897-0D5D-4230-9094-4367524F91EE@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) 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: Wed, 26 Sep 2018 14:20:40 -0000 --Apple-Mail=_A99A5281-9DBC-4531-8E7E-D1D797996EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Pavan, For me the new description seems to be more accurate. Thank you. > 26 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 17:17, Vishnu Pavan = Beeram =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0): >=20 > Alexander Hi! > =20 > 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. > =20 > We (the authors) 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. > 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. > =20 > Regards, > -Pavan >=20 >=20 > On Tue, Sep 25, 2018 at 11:34 AM Alexander Okonnikov = > = wrote: > Hi Panav, >=20 > 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). >=20 > Thank you. >=20 >=20 >> 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): >>=20 >> Alexander, Hi! >> =20 >> Please see inline for responses (prefixed VPB). >> =20 >> Regards, >> -Pavan >>=20 >> On Thu, Sep 13, 2018 at 1:37 PM Alexander Okonnikov = > = wrote: >> Hi Panav, >>=20 >> =46rom section 7: >>=20 >>=20 >> "If the label type is a delegation label, then the stacking = procedure stops at that delegation hop." >> =09 >> It is OK for "Stack to Reach Delegation Hop" approach, but it doesn't = work for "Stack to Reach Egress", isn't it? >>=20 >> [VPB] The logic specified in Section 7 could be used by any node = constructing the label stack (this could be the ingress or a delegation = 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 the label stack. >> =20 >> 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 are pushed in the label stack. The following change to = the text should address this comment: >>=20 >> OLD: >> If the label type is a delegation label, then the stacking procedure = stops at that delegation hop. =20 >> Approaches in Section 5.1 = SHOULD be used to determine how the delegation labels are pushed = in the label stack. >> =20 >> 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 used = to determine how the delegation labels are pushed in the label stack. >> =20 >>=20 >> Also, regarding FRR support. Section 1 says: >>=20 >> "Functionalities such as bandwidth admission control, LSP = priorities, preemption,=20 >> auto-bandwidth and Fast Reroute continue to work with this = forwarding plane." >> =09 >> It seems that shared labels approach supports only 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 = is very limited, and section 1 needs correction. >>=20 >> [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 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). >> =20 >>=20 >> Thank you. >>=20 >>> 13 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 20:28, Alexander = Okonnikov > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0): >>>=20 >>> Hi Panav, >>>=20 >>> Questions regarding ETLD: >>>=20 >>> The draft is not clear about signaling of ETLD attribute. It says = that ETLD is conveyed as per-hop attribute. Is my understanding correct = that it is conveyed as RRO Hop attribute? Probably it could be cleaned = to avoid confusion whether ERO or RRO Hop attribute mechanism is used. >>>=20 >>> Next, the draft says that: >>>=20 >>> "... If a node is reached where the ETLD set from the previous = hop is 1, then that >>> node MUST select itself as the delegation hop. If a node is = reached and it is=20 >>> determined that this hop cannot receive more than one transport = label, then that node=20 >>> MUST select itself as the delegation hop. ..." >>>=20 >>> What is purpose of the second sentence/rule? >>>=20 >>> Next: >>>=20 >>> "If there is a node or a sequence of nodes along the path of the = LSP that do not=20 >>> support ETLD, then the immediate hop that supports ETLD MUST = select itself as the=20 >>> delegation hop." >>>=20 >>> 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 SWAP and not POP. As a result non-decremented ETLD is OK and = immediate hop that supports ETLD not necessary should become delegation = hop? >>>=20 >>> Also, from Section 9.7: >>>=20 >>> "The ETLD field specifies the maximum number of transport labels = that this hop can potentially send to its downstream hop. It MUST be = set to a non-zero value." >>>=20 >>> 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 labels, = it doesn't mean that R2 should rewrite ETLD with value 2. It just should = decrement value 5. Correct? >>>=20 >>> Also, per my understanding 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 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 subobject? >>>=20 >>> Thank you. >>>=20 >>>> 13 =D1=81=D0=B5=D0=BD=D1=82. 2018 =D0=B3., =D0=B2 20:22, Alexander = Okonnikov > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0): >>>>=20 >>>> Hi Pavan, >>>>=20 >>>> I'm sorry for delay with answer. >>>>=20 >>>> 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 = - R2 - 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 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, provided that R4 has advertised implicit null label). In fact = actual path MTU is 1596 (1600 - 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 discovery ingress needs to know MTU per = each hop. >>>>=20 >>>> Thank you. >>>>=20 >>>>> 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): >>>>>=20 >>>>> Alexander, Hi! >>>>> =20 >>>>> I apologize for the delayed response. >>>>> =20 >>>>> 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 = 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 = supporting this draft will rely on the Resv RRO to accurately determine = the max-number 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 logic used to arrive at the MTU value assigned to = the LSP. >>>>> =20 >>>>> I hope this addresses your question. >>>>> =20 >>>>> Regards, >>>>> -Pavan >>>>>=20 >>>>> On Tue, Aug 7, 2018 at 12:22 PM Alexander Okonnikov = > = wrote: >>>>> Hi Pavan, >>>>>=20 >>>>>=20 >>>>> 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 considered? >>>>>=20 >>>>> Thank you. >>>>>=20 >>>>> 26.07.2018 06:07, Vishnu Pavan Beeram =D0=BF=D0=B8=D1=88=D0=B5=D1=82= : >>>>>> Chairs, Hi! >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Regards, >>>>>> - Pavan (on behalf of the authors) >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls = >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls = >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_A99A5281-9DBC-4531-8E7E-D1D797996EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Pavan,

For me the = new description seems to be more accurate.

Thank you.

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

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 statement. 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 <vishnupavan@gmail.com> = =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,

=46rom section 7:


"If the label type is a = delegation label, then the stacking procedure 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 delegation 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 the 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 delegation = labels are 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 stacking procedure stops at that delegation hop.  
Approaches in Section 5.1 SHOULD be used to determine how the =
delegation 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 used 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 forwarding plane."
It seems = that shared labels approach supports only 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 = is 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 = 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-labe= ls-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 Okonnikov <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 correct that it is conveyed as RRO Hop attribute? = Probably it could be cleaned 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 is 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 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 maximum number of transport labels that 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 labels, it doesn't mean that R2 should rewrite ETLD with value 2. = It just should 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 RRO Hop attributes subobject into being = inserted RRO Hop attributes subobject 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 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, 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 - R2 - 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 = 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, provided = that R4 has advertised implicit null label). In fact actual path MTU is = 1596 (1600 - 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 discovery 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 <vishnupavan@gmail.com> = =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 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 supporting this draft = will rely on the Resv RRO to accurately determine the max-number 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 = 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:
=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 described 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




= --Apple-Mail=_A99A5281-9DBC-4531-8E7E-D1D797996EF8--