Subject: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 14 Jun 2016 23:05:10 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-teas-rsvp-te-srlg-collect-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In Section 5.1 when the SRLG collection request was contained in an
LSP_REQUIRED_ATTRIBUTES and the RRO would become too big, a node drops
the RRO from the Path message entirely. It is not clear what the next
node that receives this SRLG collection request without an RRO would need
to do as the spec only says that the RRO is inserted at the ingress. What
is the expected behavior here on the subsequent node?

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Jun 2016 13:14:04 +0100

Suresh,

I think that if an RRO causes an RSVP-TE message to get full then it is a pretty
grim situation.

However, 3209 says...

   If the newly added subobject causes the RRO to be too big to fit in a
   Path (or Resv) message, the RRO object SHALL be dropped from the
   message and message processing continues as normal. A PathErr (or
   ResvErr) message SHOULD be sent back to the sender (or receiver).  An
   error code of "Notify" and an error value of "RRO too large for MTU"
   is used.  If the receiver receives such a ResvErr, it SHOULD send a
   PathErr message with error code of "Notify" and an error value of
   "RRO notification".

Does that answer you?

Cheers,
Adrian

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Suresh Krishnan
> Sent: 15 June 2016 07:05
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [Teas] Suresh Krishnan's Discuss on
draft-ietf-teas-rsvp-te-srlg-collect-
> 06: (with DISCUSS)
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 15 Jun 2016 17:27:00 +0000

Hi Adrian,

>     PathErr message with error code of "Notify" and an error value of

Not exactly. I had followed the same reference to this text as well. My 
question was more about what happens to the message that gets forwarded (due 
to the message processing continuing as normal) on the next node that gets 
the message with the SRLG collection flag set but without the RRO. Does it 
add an RRO? Does it drop the message? ...

Thanks
Suresh

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Jun 2016 19:04:57 +0100

Theoretically, only the end-points add RROs. Once an RRO is stripped it will not
be added back in (in practice, some domain boundaries might add RROs back in).
The para after the quoted one says that further refreshes should entirely remove
the RRO, but what is more likely to happen is that an alarm will be raised and
the LSP will be torn down. The operator will then go and look to see why his
signaling message grew so unbelievably large and will either fix the topology
bug, turn off some features, or shout at the vendor.

A

> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: 15 June 2016 18:27
> To: [email-masked]; 'The IESG'
> Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-
> collect-06: (with DISCUSS)
> 
> Hi Adrian,
> 
> =

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 15 Jun 2016 20:05:44 +0000

Hi Adrian,

> bug, turn off some features, or shout at the vendor.

Makes sense. Since there is a detailed specification in the draft of what 
happens when the RRO gets too big it would have made sense to add something 
like your explanation for further processing on the next node. I am not going 
to insist on doing so and will move the text to a comment.

Thanks
Suresh