Subject: [tsvwg] RSVP-PCN draft: configuration

From: "Black, David" <[email-masked]>
Date: Mon, 11 Mar 2013 10:05:06 -0400

<WG co-chair hat OFF>

I noticed a couple of configuration issues in the response to Bob's comment:

> > * How PCN interior nodes ignore RSVP messages:
> > - by configuration?
> > - or by the PCN-ingress switching aggregate PATH messages to IP protocol
> > number RSVP-E2E-IGNORE (which isn't strictly the right name but would have
> > the right effect)?

> Georgios: We mentioned in the new version of the draft that the PCN interior
> nodes ignore aggregated and e2e RSVP messages by configuration. 

I think relying on configuration is ok here, as PCN interior nodes really should
not be doing anything with any RSVP messages whatsoever, and I'm not sure I like
the idea of changing the IP protocol number on ingress and changing it back on
egress.
 
> > * Error conditions, for instance when messages don't contain the expected
> > objects, e.g. [draft-lefaucheur-tsvwg-rsvp-ecn-01, page 6 bullet 1].
 
> Georgios: Please note that the PCN object is carried using the Aggregated RESV
> message, and not the e2e RESV message, meaning that the above issue is not relevant.

In contrast, I do think that there's an actual issue here in that text should
be added to specify what a PCN ingress or egress node does when a received
Aggregated RSVP message doesn't contain all of the RSVP objects that are
supposed to be there, or contains unexpected objects.

There also should be some text (which I may have missed) on what happens
when the PCN domain is misconfigured in a fashion that allows an Aggregated
RSVP message to escape the domain - IMHO, the desired behavior is that the
entire Aggregated RSVP message is ignored by a non-PCN node that processes
RSVP, and there needs to be some text on how that happens.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Mon, 11 Mar 2013 14:24:14 +0000

Hi David,

Thanks, please see in line!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Black, David
> Sent: maandag 11 maart 2013 15:05
> To: [email-masked]
> Subject: [tsvwg] RSVP-PCN draft: configuration
> 
> <WG co-chair hat OFF>
> 
> > > - or by the PCN-ingress switching aggregate PATH messages to IP
> > > protocol number RSVP-E2E-IGNORE (which isn't strictly the right name
> > > but would have the right effect)?
> 
> > Georgios: We mentioned in the new version of the draft that the PCN
> > interior nodes ignore aggregated and e2e RSVP messages by configuration.
> 
> not be doing anything with any RSVP messages whatsoever, and I'm not sure
> I like the idea of changing the IP protocol number on ingress and changing it
> back on egress.

Georgios: Okay, thanks!

> 
> > > * Error conditions, for instance when messages don't contain the
> > > expected objects, e.g. [draft-lefaucheur-tsvwg-rsvp-ecn-01, page 6 bullet
> 1].
> 
> > Georgios: Please note that the PCN object is carried using the
> > Aggregated RESV message, and not the e2e RESV message, meaning that
> the above issue is not relevant.
> 
> In contrast, I do think that there's an actual issue here in that text should be
> added to specify what a PCN ingress or egress node does when a received
> when the PCN domain is misconfigured in a fashion that allows an
> Aggregated RSVP message to escape the domain - IMHO, the desired
> behavior is that the entire Aggregated RSVP message is ignored by a non-
> PCN node that processes RSVP, and there needs to be some text on how
> that happens.

Georgios: Thanks, We will work these comment out in a next version of the draft!

Best regards,
Georgios