Minutes for MPLS at IETF-95
minutes-95-mpls-1

1. Agenda bashing, WG status reports
17:40:0017:50:0010
Chairs

2 draft-ietf-teas-yang-te-topo
17:50:0018:00:0010
Xufeng Liu

3 draft-ietf-teas-yang-rsvp
draft-ietf-teas-yang-te
18:00:0018:15:0015
Tarek Saad

4 draft-saad-mpls-static-yang
18:15:0018:15:000
Tarek Saad

5 draft-raza-mpls-ldp-mldp-yang
18:15:0018:30:0015
Rajiv Asati

6 draft-pkd-pce-pcep-yang
18:30:0018:40:0010
Dhruv Dhody

7 draft-zhang-ccamp-transport-ctrlnorth-yang
18:40:0018:50:0010
Xian Zhang

8 draft-zheng-mpls-lsp-ping-yang-cfg
18:50:0019:00:0010
Guangying Zheng

1 Agenda bashing, WG status reports10:00:0010:20:0020Chairs

Meeting starting.
Note well applies.

A summary of WG status and activities.

2 ietf-mpls-rfc4379bis10:40:0010:50:0010Carlos + Kireeti

Carlos presenting.

[discussion]

Kireeti Kompejja: question for the chairs - how are yyou targetting this
document? Is it PS, is it DS? Loa: this is not a draft standard. My intention
was to clean the document up, but when we discussed this further, we agreed
that we would try to make it an internet standard. Kireeti: we should be
careful on what we import that might have a different level of implementation
maturity. We do not want to import something and then pull it out. Carlos: the
principle that we used while this update is exactly that - what should we
remove, and not what to overimport. Kireeti: many of the documents that we are
importing have IANA registries. Do you plan to update those too? Loa: I would
prefer to have everything in one place. But if it creates ambiguity, then we
should leave it as it is. Kireeti: we are trying to reduce the confusion, not
to create. Shahram Davari: you mentioned no interoperability issues - is that
really the case? Carlos: we did not hear anything, if anyone knows anything
please report. Loa: there is naother coordination direction that needs to be
taken - LSP ping for multisegment PWs, need to align with what Sami is doing in
PALS. Also it aplies to YANG models for LSP ping. Would encourage the authors
to cooperate. Carlos: we will continue to edit the document incorporating the
changes. And coordinating with other activities.

3draft-ietf-mpls-tp-shared-ring-protection10:50:0011:00:0010Liang Geng

Liang presenting.

[discussion]

Robert Raszuk: this work overlaps with TE LFA work in SPRING. Why do we have
parallel solutions as TE LFA works for rings. Liang: I am not aware when and by
whom that problem was addressed? I will check and will bring it to the list.
George Swallow: TE LFA does nothing about bandwidth reservations. Loa: we
really need to bring technical changes to the document if those documents are
WG documents to the mailing list, it is not only between the authors, you need
to be really transparent when updating the documents.

4draft-ijln-mpls-rfc5036bis11:00:0011:15:0015Nic Leyman

Nic prsenting.

[discussion]

Loa: last two bullets on IANA - discussed with IANA, they suggest to put a new
section and in that section put a subsection of what is there verbatim in 5036,
and then add another subsection to add anythign new. Loa: Also appendix is easy
to do, just not intuitive - have discussed this with RFC editor. Loa: two
important questions for me are what to do with FR and ATM. RF seems to be
mostly gone. ATM we have got one voice that we should be carefull. That is
something that we would like to get feedback on. Carlos Pignataro/Cisco: I
think taking out FR is about time. If there is a pushback, put those two
sections into a separate draft.

5draft-shen-mpls-egress-protection-framework11:15:0011:25:0010Jeffrey (Zhaohui)
Zhang

Jeffrey presenting.

[discussion]

Greg Mirsky/Ericsson: we had a good discussion about egress protection, and it
is important to define what we call as ingress failure. We cannot reliably
differentiate link and node failure. Jeffrey: this framework is for the egress
node failure by manotiring the egress node liveness. This likely is not that
complex problem, and we can continue on the mailing list. Raveendra Torvi via
meetecho: [disconnected] Lucy Young/Huawei: there is already a solution work in
TEAS for this problem. Why do we need another work here? Jeffrey: yes, there is
work in TEAS. That is a particular solution that is specific to RSVP-TE. This
framework tries to address all tunnel protocols and services in a generic way.
Tjere has been many discussions with TEAS to align the work. There is another
way to do this protection in RSVP-TE case without protocol extensions.
Huaimo?/Huawei: you mentioned that you can provide egress protection without
any protocol extensions. That is not true. Loa: I would like to step back a
bit. Yes there are drafts in TEAS. This is a more high level document. This is
along the lines of requirements - we wish to di it in some way, if it is not
possible, then we do not do it. The TEAS document and this one are not
contentious. Greg Mirsky/Ericsson: It is good to take a higher level look to
the problem. Maybe two documents are needed - one will formulate the
requirements, another propose the solution, Greg: I will repeat my question -
what type of failure is considered? Does it include the concatenated link, or
the one between .... Adrian: proxy for Yimin on jabber: TEAS draft is RSVP
specific. Adrian: proxy for Yimin on jabber: this draft intends to provide an
overvieww of the problem as well as a solution framework.

6draft-rosen-mpls-rfc3107bis11:25:0011:40:0015Ross Callon

Ross presenting.

[discussion]

Lucy Young: In the IDR we have a new draft on FS for MPLS. That may also apply
to this work. I see that this is possibly related here. Ross: we should take
this offline and get Eric involved. Loa: Lucy should bring this to IDR WG and
copy MPLS WG. Jorge Rabadan/Nokia: you mentioned this applies to VPN prefixes?
Ross: 3107bis does not change or specify anything on VPN. Maybe say a similar
approach is used for VPNs. Jorge: there should be some text to cover that. John
Scudder: you mentioned on NLRI formatting that the format is not optimal. My
comment is not to change that, just document the existing practices. If you do
that it changes quite a lot, and this needs to be discussed in IDR, and for all
address families. Keyur Patel/Cisco: I think the base document talks about the
carruing multiple labels, and identifying the bottom is by the end of stack
bit, but doies BGP need to know that? We should consider the ecoding that is
faster on the wire. Ross: This all needs to be discussed on both lists George
Swallow: if we change the parsing, itr needs to be in IDR. Jeff Tantsura: there
are many discrepancies in implementations, we need to clarify the case of
multiple rouites with same NH. We need to formalize it in strong language.
Kireeti Kompella: two points: 1) if you plan to change this and capabilities is
enough to differentiate, then let's do it in a right way. If you have a
capability, you do not need to worry about breaking things. 2) If you have same
prefix with different labels, that is a BGP thing, it should not be discussed
here. Acee Lindem/Cisco: Have read the document and support it. With
capabilities we can do what we want as that is a new behaviour - for multiple
labels. Acee: For lucy;s comment - this is for documenting what is deploiyed,
not the new functionality. Loa: who has read the document. Loa: those who have
read the document, do you think that it is ready to become the wg document?
George Swallow: if we add in the capability, we need to explicitely address
that, What is in the draft will be hard to change later. This needs to be
solved before adoption. George: that should be a hat off comment.

7draft-ietf-mpls-bfd-directed11:40:0011:50:0010Deborah

Deborah presenting.

[discussion]

No questions or comments.

8draft-mtaillon-mpls-summary-frr-rsvpte11:50:0012:00:0010Tarek Saad

Tarek presenting.

[discussion]

Lou Berger: you define a new mechanism for communication between transit LSRs,
and that becomes a new way of doing a form of segment signalling. We have done
that before in the context of segment recovery. Likely we did a wrong thing
then and we should have defined a generic way of communication between
midpoints, and when a new use case cames along, we should just reuse that. From
the architecture standpoint, this seems to be abog deal. We need to think
wehter we need to do a generic midpoint signalling. Tarek: ... Lou Berger: I am
not saying that you move to segment protection. I suggest that you define a new
midpoint signalling mechanism, and do it in a generic way. I am happy to think
about it this week. Yes, this is something new, and you likely do not want to
hear about it. Tarek: It is a mechanism to associate LSPs together. We find
that this suits the requirement.

9draft-kompella-mpls-rmr12:00:0010:50:0010Kireeti Kompella

Kireeti presenting.

[discussion]

Greg Mirsky/Ericsson: Regarding the format of flags - is SO a bitfield, or
values? Kireeti: those all are bit fields for small values. Yes, it is a bit
field. The OAM mechanism that you pick will be indicated as a bitmask for
capabilities, and as a number for links. Greg: having MBZ bits is good, as we
might have new OAM mechanisms. Greg: when you are signalling the resulting
protocol, we will need more bits to represent more supportted protocols.
Kireeti: do you sugegst expanding the bitfields now?

10draft-turaga-mpls-test-labels12:10:0012:20:0010Partha turaga

Partha presenting.

[discussion]

Greg Mirsky/Ericsson: Async BGP does not allow TLVs, but if that is of
interest, we could consider applicability of BGP  echo. Greg: there is also LSP
self ping that could be aplicable here. Greg: I think the scope of this work
should be formulated better - there are enough protocols that could do this.
Partha: we are not adding more protocols. Greg: As I read your draft you are
asking for a special purpose label value allocation. I do not see a need for
that. Kireeti Kompella: what would happen if you send this on a broadcast
network (say, a switch?) Partha: I have not considered that yet. Kireeti: It
might be interesting from the saturation of the link piint of view that the
responder sends two packets. Receiver could add one more packet to really
saturate the link. George Swallow: my concern is that there are platforms built
that siport global label space, and what you describe here will require
hardware that is not capable of punting to the RP in order to support this.
Would suggest using different labels for different interfaces. Partha: Not
certain whether I can answer that. If we have per interface labels we need a
mechanism to exchange them. George: Yes. Partha: that likely will result in a
label distribution protocol functionality? George: that could be done in
discovery phase. Partha: I also considered the mechanisms with ipv4 ... Shahram
Davari: why cannot you use MPLS loss measurement instead? Partha: are they
sending probes on those links? Shahram yes. Partha: I need low time intervals.
Are you suggesing to use MPLS loss measurement instead? Shahram: MPLS loss
measurement works by counting the loss counters. Loa: we are at the point where
we need to take this to the list. Adrian proxying for Stewart Bryant via
jabber: why not to do this with a large stack of labels? Special label is a
hardware function. Agree with what George said. Partha: is there is a
specialized label protocol? Adrian: Stewart is not talking about label
distribution, he is talking about label stack.

11draft-chandra-mpls-ri-rsvp-frr12:20:0012:30:0010Vishnu Pavan Beeram

Pavan presenting.

[discussion]

No questions and comments.

----------------------

Adrian proxying jabber room: Did you close the meeting 15 minutes early and
have cut the mike lines multiple times? Do you want to invite those people to
speak now? Loa: no, the meeting is closed.