Wednesday, November 6, 2013< ^ >
Room Configuration
Room Occupants

[19:56:25] cyril.margaria joins the room
[20:23:55] Daniel King joins the room
[20:24:02] <Daniel King> Hi Cyril
[20:36:37] <cyril.margaria> Hi
[20:36:52] <cyril.margaria> How are you
[20:36:54] <cyril.margaria> ?
[20:37:22] <cyril.margaria> You are in the room?
[20:41:35] <cyril.margaria> I do not have yet the audio stream
[20:47:03] joins the room
[20:49:01] <cyril.margaria> Hi, again
[20:49:09] <cyril.margaria> Are you in the room?
[20:49:32] leaves the room
[20:49:32] Daniel King leaves the room
[20:58:09] Daniel King joins the room
[20:58:18] <Daniel King> Right... Back again.
[20:58:23] <Daniel King> Do you have audio yet?
[20:58:27] <cyril.margaria> Good,
[20:58:37] <cyril.margaria> I do not have the audio stream
[20:59:19] <cyril.margaria> you are in regency B, correct
[20:59:21] <cyril.margaria> ?
[21:00:01] <Daniel King> Yes
[21:00:05] <Daniel King> Just checking mic now.
[21:01:15] <cyril.margaria> I have the audio
[21:02:04] <Daniel King> Oh... Ok, I need to rush back to help desk and let me know.
[21:04:09] Daniel King leaves the room
[21:04:24] joins the room
[21:06:19] <cyril.margaria> thanks dan
[21:07:41] <cyril.margaria> Yes
[21:07:53] <> Will confirm.
[21:08:14] <cyril.margaria> Indeed, also feedback from the list is expected
[21:08:46] <> Yes, to be honest I could not get to mic before Julien moved on,
[21:08:49] <cyril.margaria> Its fine
[21:09:03] adrianfarrel joins the room
[21:16:09] <> Zafar -   2. PCEP Extensions to Compute Service-Aware LSPs <>
[21:18:36] <> Xian - 3.1. Stateful PCE Applicability <>
[21:20:19] vph joins the room
[21:21:20] <> Ina - 3.2. PCEP Extensions for Stateful PCE and PCE-Initiated LSPs <>
[21:26:36] <cyril.margaria> PCRep/PCReq extensions : there are use cases (policy, planning) for it,  stated on the mailing list, should this be added to the use case first?  to have this reincluded in the extension?
[21:28:46] <> Adrian, can you ask question as I type Dhruvs comment?
[21:28:47] <cyril.margaria> (this was a comment)
[21:30:02] <cyril.margaria> From the comment on the mailing list it seems there is some things to address
[21:30:26] <cyril.margaria> I think its a strong use case
[21:30:54] <adrianfarrel> Ooops. Must pay more attention to jabber room
[21:31:59] <cyril.margaria> Scope of the applicability document: is it a requirement document or applicability only?
[21:32:49] <cyril.margaria> I second Fatai comment
[21:33:17] <cyril.margaria> who is speaking?
[21:33:21] <cyril.margaria> ;-)
[21:33:35] <> Ah, ;-)
[21:34:37] <cyril.margaria> Common : yes
[21:37:06] <cyril.margaria> I would not object
[21:37:27] <cyril.margaria> I agree on the merged, I disagree on separate documents
[21:38:10] <> Ack. No sure it would be the deciding vote at the moment ;-)
[21:38:12] <cyril.margaria> I object on two set
[21:38:26] <> Objectors won.
[21:38:36] <> Objectors to a merged doc that is.
[21:38:37] <adrianfarrel> @cyril: can you say why object to two?
[21:39:07] <cyril.margaria> because it shoudl disapear when the BANDWIDTH can represent a lambda,
[21:39:27] <cyril.margaria> (CF GMPLS discussion)
[21:40:07] <adrianfarrel> well, I don't think the proposal is to branch the protocol, just to document the extensions in separate documents
[21:40:12] <cyril.margaria> Which is currently the only (maybe) difference
[21:40:47] <adrianfarrel> Yeah. I like the "maybe" :-)
[21:42:01] <cyril.margaria> Well, the GMPLS extension would be one object with the current encoding, and it might disapear.
[21:43:02] <cyril.margaria> The other GMPLS statefull extensions are not strickly related to statefull (layer discovery), and PLSP-ID changes.
[21:43:50] <> Xian - draft-zhang-pce-pcep-stateful-pce-gmpls-03 <>
[21:47:40] <cyril.margaria> question: The draft add support for unnumbered if id ERROR_SPEC, are unnumbered interfaces forbidden in MPLS-TE ?
[21:47:52] <adrianfarrel> @cyril: So I hear "not necessary to have two drafts" rather than "would be damaging"
[21:48:01] <cyril.margaria> are the extensions only related to stateful or can some of the  extensions be applicable to stateless (SC discover for example?) or also  applicable to non-GMPLS network (PLSP)
[21:48:05] <cyril.margaria> I red the document
[21:48:09] <adrianfarrel> No, unnumbered i/f are encouraged in MPLS-TE
[21:48:31] <cyril.margaria> No comments?
[21:48:36] <adrianfarrel> no comments
[21:49:08] <> Zafar - 3.4.a. PCEP Extensions for Remote-initiated GMPLS LSPs <>
[21:49:24] <cyril.margaria> @adrian: indeed, not necessary
[21:49:56] <adrianfarrel> Perfect. So you can live with two I-Ds even if you prefer just one. I think that is the consensus reached in the room
[21:50:21] <adrianfarrel> Sorry, Cyril, maybe our process is not working. If you have a question that is a question for the presenter, please tag with "PLEASE ASK"
[21:51:50] <cyril.margaria> ok
[21:54:46] <cyril.margaria> @adrian: BTW, did you see my mail regarding the ccamp generic ro attribute?
[21:57:05] Peer joins the room
[21:57:22] <Peer> Test, can you see my chat?
[21:57:54] <cyril.margaria> PLEASE ASK: should the use case be merged in the general applicability document?
[21:58:04] <cyril.margaria> Peer: yes
[21:58:18] <Peer> Thanks Cyril
[21:59:35] <cyril.margaria> We have a very nice jabber scribe, the question should be tagged with 'PLEASE ASK'
[21:59:45] <> Cyril, just to confirm. You want to know if the slide should be a use case?
[22:00:02] <> in the Appl doc?
[22:00:26] <cyril.margaria> @Dianel : the document describe use cases (section 2),
[22:00:26] <adrianfarrel> i am at mic
[22:01:25] <cyril.margaria> @adrian: thanks
[22:02:50] shane joins the room
[22:03:56] <adrianfarrel> @cyril; wrt email, I am "a little behind"
[22:04:20] <> Zafar - 3.4.b. PCEP Extensions for Remote-initiated GMPLS LSPs <>
[22:08:01] <cyril.margaria> @adrian: No Pb, I just wanted to distinguish between a timeout or a overloaded mailbox.
[22:08:16] <> Siva - 3.5. Conveying Path Setup Types in PCEP <>
[22:09:12] <cyril.margaria> PLEASE ASK: What is the use case associated with the signaling method. i.e why is it needed?
[22:10:02] <cyril.margaria> sorry, discard previous PLEASE ASK: What is the use case associated with this information. i.e why is it needed?
[22:12:57] <cyril.margaria> PLEASE ASK: there is another PCEP usage : NMS (with known deployments)
[22:15:51] <adrianfarrel> in q
[22:19:21] dredgie joins the room
[22:20:05] <> Santiago - 3.6. PCE Path Profiles <>
[22:20:19] <cyril.margaria> ok, but I missing alternative approches to specify a specific path representation
[22:22:17] <adrianfarrel> @cyril: I interpretted his answer to mean that the description of the path in a PCRep will be different for different uses. Hence there is a need for a flag to request the type of path description that is to be produced, and to indicate the type of path description that is present
[22:27:21] <> SR proposes two types of segments, nodal and adjacency, these are built using SPT (from IGP) or LSP (from TE). Both use the SR Segment Identifier (SID). I do not know if they can be mixed in the same PCEP message, but I know they cannot carry any other type of ERO type.
[22:28:19] <cyril.margaria> I think this a sensible use case, however this seems a bit strange that its not possible to have one path crossing several domain
[22:28:30] <> Either way, sounds like procedure needs to be clearer for each use case.
[22:29:59] <cyril.margaria> @daniel: I am a bit puzzled by the "they cannot carry any other type of ERO type", this seems a strong restriction
[22:30:15] <adrianfarrel> It seems to me like it is constructed specifically for segment routing, and at the moment we don't know how you "stitch" RSVP-TE to SR
[22:31:04] <> As in, all subobjects within an ERO would represent the SID.
[22:31:06] <adrianfarrel> @cyril: you are right. There is confusion because the ERO in PCEP is *not* an RSVP-TE ERO.
[22:31:27] <adrianfarrel> It is a PCEP ERO, so there is no need for a new object
[22:31:39] <adrianfarrel> And the existing ERO can carry label subobjects
[22:31:47] <adrianfarrel> So we're done for all that
[22:32:06] <adrianfarrel> All that is needed is some help to understand the use that will be made
[22:32:17] <cyril.margaria> you could also (see ccamp) put explicit region informatin
[22:32:35] <adrianfarrel> Because a PCEP ERO that will be used for RSVP-TE will have nodes and links (and labels) but an SR use will just have labels
[22:32:54] <cyril.margaria> @adrian: but it could be in the middle of the path, a segment in the path.
[22:33:01] <adrianfarrel> [Don't get me started on the explicit region stuff. I think it sucks:-) ]
[22:33:20] <> Moving on ;-)
[22:33:25] <> Quintin - 3.7. Use Cases for PCE as Central Controller <>
[22:34:14] <adrianfarrel> I *think* you might need to do something more clever in this case
[22:35:30] <cyril.margaria> for the explicit region: I would tend to think there is some use cases;-) and I would like to know why it sucks (but this can be done offline).
[22:37:43] <cyril.margaria> current document: Isn't this why we have the current statefull PCE?
[22:38:29] <adrianfarrel> I am having some trouble parsing what is new
[22:40:11] <cyril.margaria> me too
[22:41:58] <adrianfarrel> I *think* this boils down to "Centralised controllers can do stuff just like SDN. And PCE is part of that function. So let's call it PCECC"
[22:42:29] <adrianfarrel> To be fair, see slide 9. They do have code
[22:45:32] <cyril.margaria> and they will sponsor the cookies too ;-)
[22:45:52] <> Centralised distribution of cookies would be unfair.
[22:45:54] <> Young - 3.8. Appication-oriented Stateful PCE Architecture and Use Cases <>
[22:48:41] <cyril.margaria> :)
[22:49:32] vph leaves the room: offline
[23:00:33] <> Diego - 4.1. Secured Transport for PCEP <>
[23:02:59] <cyril.margaria> This is rather big presentation.
[23:03:43] <> I think the NSA may have broken TLS already.
[23:04:22] <> Suggest Quantum Key Distribution.
[23:12:21] <> Qin - 4.2. PCE Discovery Using DNS <>
[23:13:59] Peer leaves the room
[23:23:15] <> Dhruv - 4.3. PCEP Extensions for Receiving SRLG Information <>
[23:26:01] shane leaves the room
[23:27:36] <> Oscar - 5.1. TED Dissemination for Hierarchical PCE <>
[23:32:01] <> Meeting over.
[23:32:23] <cyril.margaria> good night (if you are in europa) ;-)
[23:32:31] adrianfarrel leaves the room
[23:32:33] <> Thanks for syaing up!
[23:32:39] <> urm, "staying".
[23:32:46] <cyril.margaria> ccamp will be more difficult
[23:32:47] <> See you Simon!
[23:33:11] <> Yes Cyril, in multiple dimensions ;-)
[23:33:16] leaves the room
[23:33:17] <cyril.margaria> But I wil switch from beer to coffee
[23:33:21] cyril.margaria leaves the room
[23:38:22] Peer joins the room
[23:38:54] Peer leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!