Subject: Re: [mpls] Requesting WG LC for draft-ietf-mpls-rsvp-shared-labels

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 6 Sep 2018 11:27:17 -0400

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 <
[email-masked]> 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 considered?
>
>
> Thank you.
>
> 26.07.2018 06:07, Vishnu Pavan Beeram пишет:
>
> 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 [email-masked]://www.ietf.org/mailman/listinfo/mpls
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 13 Sep 2018 20:22:08 +0300

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 = 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 сент. 2018 г., в 18:27, Vishnu Pavan Beeram <[email-masked]> написал(а):
> 
> Alexander, Hi!
>  
> 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.
>  
> On Tue, Aug 7, 2018 at 12:22 PM Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> 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 considered?
> 
> Thank you.
> 
>> 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,
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 13 Sep 2018 20:28:26 +0300

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 сент. 2018 г., в 20:22, Alexander Okonnikov <[email-masked]> написал(а):
> 
> Hi Pavan,
> 
>> 6 сент. 2018 г., в 18:27, Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> Alexander, Hi!
>>

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 13 Sep 2018 20:37:49 +0300

Hi Panav,

From 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?

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.

Thank you.

> 13 сент. 2018 г., в 20:28, Alexander Okonnikov <[email-masked]> написал(а):
> 
> Hi Panav,
> 
>> 13 сент. 2018 г., в 20:22, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> Hi Pavan,
>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 15 Sep 2018 20:03:05 -0400

Alexander, Hi!

Much Thanks for the review comments. Please keep them coming.

Please see inline for responses (prefixed VPB).

Regards,

-Pavan

On Thu, Sep 13, 2018 at 1:28 PM Alexander Okonnikov <
[email-masked]> wrote:

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

[VPB] The ETLD specific protocol extensions are discussed in Section 9.7.
This section clearly states that the ETLD TLV is carried in the
HOP_ATTRIBUTES subobject of an RRO object in the Path message. That said,
the following tweak to the text in Section 5.3.1 should address your
comment:

OLD:

The ETLD is signaled as a per-hop attribute in the Path message [RFC7570
<https://tools.ietf.org/html/rfc7570>].

NEW:

The ETLD is signaled as a per-hop recorded attribute in the Path message [
RFC7570 <https://tools.ietf.org/html/rfc7570>].

> What is purpose of the second sentence/rule?

[VPB] Selecting oneself as a delegation hop ensures that the incoming
packet will not carry more than one transport label. The second sentence
above was added to let the transit node have the ability to influence the
delegation decision if it ran into some local policy/limitation that
prevented it from receiving more than one transport label. As an
alternative, the transit node may decide to choose a regular swap label in
such scenarios and let some downstream node be 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?
>
>
[VPB] If an intermediate transit node doesn’t support ETLD, it will not
record ETLD for that hop. The immediate hop that supports ETLD will realize
that the previous hop doesn’t support ETLD (no recording available for the
previous hop) and designates itself as a 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?
>
>
[VPB] I agree that the above sentence can read better. The intent was to
say – “the maximum number of transport labels that the hop can send in
relation to its position in the path”. The following tweak to the sentence
should address your concern:

OLD:

The ETLD field specifies the maximum number of transport labels that this
hop can potentially send to its downstream hop.

NEW:

The ETLD field specifies the effective number of transport labels that this
hop (in relation to its position in the path) can potentially send to its
downstream hop.

> 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?
>
>
[VPB] The authors did consider the alternative protocol extensions that you
have specified above. We decided to use the current encoding in the draft
because there was no good reason to get 2 code-points for ETLD when the
same objective could be achieved with one code-point.

> Thank you.
>
> 13 сент. 2018 г., в 20:22, Alexander Okonnikov <
> [email-masked]> написал(а):
>
> Hi Pavan,
>
> 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 = 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.
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 15 Sep 2018 21:38:28 -0400

Alexander, Hi!

Regards,

-Pavan

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

Approaches in Section 5.1
<https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#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
<https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#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.

> 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’t 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’t 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 сент. 2018 г., в 20:28, Alexander Okonnikov <

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 16 Sep 2018 19:25:41 -0400

Alexander, Hi!

I missed responding to this earlier. Please see inline for responses
(prefixed VPB).

Regards,

-Pavan

> ingress needs to know MTU per each hop.

[VPB] Your understanding is correct. The logic to determine the MTU value
assigned to the LSP at the ingress may arrive at a relatively conservative
value when it uses the path MTU learnt via signaling and deduces the number
of bytes in the label stack used for the LSP. And yes, the ingress would
arrive at a more accurate value if it knows the MTU used at each hop of the
LSP (to discount the labels accordingly). The mechanisms for learning the
per-hop MTU of the LSP are outside the scope of this draft.

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 25 Sep 2018 18:34:32 +0300

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 сент. 2018 г., в 4:38, Vishnu Pavan Beeram <[email-masked]> написал(а):
> 
> Alexander, Hi!
>  
> On Thu, Sep 13, 2018 at 1:37 PM Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Panav,
> 
> From section 7:
> 
> 
> [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 –
> Approaches in Section 5.1 <https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#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 <https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#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.
>   
> 
> [VPB] I don’t 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’t 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 <https://tools.ietf.org/html/draft-chandra-mpls-rsvp-shared-labels-np-00> (this was presented at the last IETF).
>   
> 
> Thank you.
> 
>> 13 сент. 2018 г., в 20:28, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> Hi Panav,
>>

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 25 Sep 2018 18:43:15 +0300

Hi Pavan,

One question regarding ETLD. The draft says (section 5.3.1):

   When an LSP that requests automatic delegation also requests facility
   backup protection [RFC4090 <https://tools.ietf.org/html/rfc4090>], the ingress or the delegation hop MUST
   account for the bypass tunnel's label when populating the ETLD.  So,
   the ETLD that gets populated on these nodes is one less than what
   gets populated for a corresponding unprotected LSP.

I.e. is it assumed that bypass tunnel itself will be regular RSVP-TE LSP? Otherwise, if bypass LSP is signalled using shared labels approach, ETLD should be decreased for amount of label stack depth, imposed by this PLR (ingress or delegation hop) for bypass tunnel.

Thank you.

> 16 сент. 2018 г., в 3:03, Vishnu Pavan Beeram <[email-masked]> написал(а):
> 
> Alexander, Hi!
>  
> On Thu, Sep 13, 2018 at 1:28 PM Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Panav,
> 
> [VPB] The ETLD specific protocol extensions are discussed in Section 9.7. This section clearly states that the ETLD TLV is carried in the HOP_ATTRIBUTES subobject of an RRO object in the Path message. That said, the following tweak to the text in Section 5.3.1 should address your comment:
>  
> OLD:
> The ETLD is signaled as a per-hop attribute in the Path message [RFC7570 <https://tools.ietf.org/html/rfc7570>].
>  
> NEW:
> The ETLD is signaled as a per-hop recorded attribute in the Path message [RFC7570 <https://tools.ietf.org/html/rfc7570>].
>  
>   
> 
> [VPB] Selecting oneself as a delegation hop ensures that the incoming packet will not carry more than one transport label. The second sentence above was added to let the transit node have the ability to influence the delegation decision if it ran into some local policy/limitation that prevented it from receiving more than one transport label. As an alternative, the transit node may decide to choose a regular swap label in such scenarios and let some downstream node be the delegation hop.
>   
> 
> Next:
> 
> [VPB] If an intermediate transit node doesn’t support ETLD, it will not record ETLD for that hop. The immediate hop that supports ETLD will realize that the previous hop doesn’t support ETLD (no recording available for the previous hop) and designates itself as a delegation hop.
>  
> Also, from Section 9.7:
> 
> [VPB] I agree that the above sentence can read better. The intent was to say – “the maximum number of transport labels that the hop can send in relation to its position in the path”. The following tweak to the sentence should address your concern:
>  
> OLD:
> The ETLD field specifies the maximum number of transport labels that this hop can potentially send to its downstream hop.
>  
> NEW:
> The ETLD field specifies the effective number of transport labels that this hop (in relation to its position in the path) can potentially send to its downstream hop.
>  
>   
> [VPB] The authors did consider the alternative protocol extensions that you have specified above. We decided to use the current encoding in the draft because there was no good reason to get 2 code-points for ETLD when the same objective could be achieved with one code-point.
>  
> Thank you.
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 26 Sep 2018 10:17:01 -0400

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’t see any problem with the above statement. But
we’ll 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 <
[email-masked]> 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.
>
>
>> It is OK for "Stack to Reach Delegation Hop" approach, but it doesn't
>> work for "Stack to Reach Egress", isn't it?
>>
>
> 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 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.
>
>
>
>>
>> "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."
>>
>> 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
>> 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.
>>
>>> 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.
>>>

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 26 Sep 2018 17:20:26 +0300

Hi Pavan,

For me the new description seems to be more accurate.

Thank you.

> 26 сент. 2018 г., в 17:17, Vishnu Pavan Beeram <[email-masked]> написал(а):
> 
> Alexander Hi!
>  
> The intent of the following statement in Section 1 is certainly not to be evasive (slightly or otherwise).
> We (the authors) still don’t see any problem with the above statement. But we’ll go ahead and make a slight adjustment (see below) to address your concern.
> On Tue, Sep 25, 2018 at 11:34 AM Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Panav,
> 
>> 16 сент. 2018 г., в 4:38, Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> Alexander, Hi!
>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 26 Sep 2018 10:20:27 -0400

Alex, Hi!

Yes, the bypass tunnel (as indicated by the reference) referred to here is
a regular RFC4090 bypass tunnel.

Regards,
-Pavan

On Tue, Sep 25, 2018 at 11:43 AM Alexander Okonnikov <
[email-masked]> wrote:

> I.e. is it assumed that bypass tunnel itself will be regular RSVP-TE LSP?
> Otherwise, if bypass LSP is signalled using shared labels approach, ETLD
> should be decreased for amount of label stack depth, imposed by this PLR
> (ingress or delegation hop) for bypass tunnel.
>
> Thank you.
>
> The ETLD field specifies the effective number of transport labels that
> this hop (in relation to its position in the path) can potentially send to
> its downstream hop.
>
>
>
>
> [VPB] The authors did consider the alternative protocol extensions that
> you have specified above. We decided to use the current encoding in the
> draft because there was no good reason to get 2 code-points for ETLD when
> the same objective could be achieved with one code-point.
>
>
>> Thank you.
>>

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 26 Sep 2018 17:44:00 +0300

Hi Pavan,

The fact that facility bypass LSP is being established according to RFC 4090 doesn't necessary mean that it itself cannot be shared segment RSVP-TE LSP. One can assume that the same approach is used for bypass tunnels too (to take benefits of shared segment approach). And it could be, unless automatic delegation is used for some protected LSP.

Thank you.

> 26 сент. 2018 г., в 17:20, Vishnu Pavan Beeram <[email-masked]> написал(а):
> 
> Alex, Hi!
> 
> Yes, the bypass tunnel (as indicated by the reference) referred to here is a regular RFC4090 bypass tunnel.
> 
> Regards,
> -Pavan
> 
> On Tue, Sep 25, 2018 at 11:43 AM Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Pavan,
> 
>> 16 сент. 2018 г., в 3:03, Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> Alexander, Hi!
>>

---

From: Matt Hartley <[email-masked]>
Date: Wed, 26 Sep 2018 10:56:43 -0400

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 no
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 already
established that nnhop FRR requires further extensions.

Cheers

Matt

On Wed, Sep 26, 2018 at 10:17 AM Vishnu Pavan Beeram <[email-masked]>
wrote:

>> 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
>>> I hope this addresses your question..
>>>
>>> Regards,
>>> -Pavan
>>>
>>>> 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,

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 27 Sep 2018 03:44:03 -0400

Alexander, Hi!

As you have observed, the draft doesn’t preclude the use of shared labels
for bypass tunnels (when there is such a desire to do so). The intent of
the text in Section 5.3.1 (that you have highlighted) is to simply say that
the ETLD processing at the ingress/delegation-hop MUST account for the
bypass tunnel’s label(s). The following update to the text should address
your concern:

   backup protection [RFC4090 <https://tools.ietf.org/html/rfc4090>], the
ingress or the delegation hop MUST

   account for the bypass tunnel's label(s) when populating the ETLD.
Hence,

   when a regular bypass tunnel is used to protect the facility, the ETLD

   that gets populated on these nodes is one less than what gets populated

   for a corresponding unprotected LSP.

Regards,

-Pavan

On Wed, Sep 26, 2018 at 10:44 AM Alexander Okonnikov <
[email-masked]> wrote:

> Hi Pavan,
>
> The fact that facility bypass LSP is being established according to RFC
> 4090 doesn't necessary mean that it itself cannot be shared segment RSVP-TE
> LSP. One can assume that the same approach is used for bypass tunnels too
> (to take benefits of shared segment approach). And it could be, unless
> automatic delegation is used for some protected LSP.
>
> Thank you.
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 27 Sep 2018 04:30:42 -0400

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
would 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 are
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 <[email-masked]>
wrote:

> On Wed, Sep 26, 2018 at 10:17 AM Vishnu Pavan Beeram <
> [email-masked]> wrote:
>
>> Alexander Hi!
>>
>>
>>
>> We (the authors) still don’t see any problem with the above statement.
>> But we’ll go ahead and make a slight adjustment (see below) to address your
>> concern.
>>

---

From: Matt Hartley <[email-masked]>
Date: Thu, 27 Sep 2018 10:47:39 -0400

Pavan,

OK. That's reasonable, but 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 Pavan Beeram <[email-masked]>
wrote:

> features/functionalities specified in the Introduction Section that would continue
>>>> 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
>>>>> 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?
>>>>>